From owner-Big-Internet@munnari.OZ.AU Mon Aug 1 05:08:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02171; Mon, 1 Aug 1994 05:08:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05131; Mon, 1 Aug 1994 05:08:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05113; Mon, 1 Aug 1994 04:50:19 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01763; Mon, 1 Aug 1994 04:50:15 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-12.dialip.mich.net (pm002-12.dialip.mich.net [35.1.48.93]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA15014 for ; Sun, 31 Jul 1994 14:50:06 -0400 Date: Sun, 31 Jul 94 17:41:11 GMT From: "William Allen Simpson" Message-Id: <2936.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Whither 8 bytes? > From: Paul Robinson > On Thu, 28 Jul 1994, Noel Chiappa wrote: > > I suggest we disband this list, since the topic it was set up to handle, the > > growth of the Internet, has been effectively answered with the choice of > > SIPP-16 as IPng. > > Which is going to be a waste and a ridiculous overshoot, an excess of > humongous proportions. > Paul, many many many of us agree with you. But, a decision was made. Since you weren't in Toronto, your voice was not heard. I did my best. It was depressing to learn that we have become so politically rather than technically oriented that we now choose to make decisions which make everyone equally unhappy, rather than decisions which make one faction happy. There will be a few other opportunities to challenge that decision, during the last call, and based on real implementation experience. I believe that this list will continue, as the charter list for IPng issues, until the IPng Directorate disbands. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Aug 1 07:40:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00214; Mon, 1 Aug 1994 07:40:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA05273; Mon, 1 Aug 1994 07:33:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA05255; Mon, 1 Aug 1994 07:11:42 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05737; Mon, 1 Aug 1994 07:11:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13303; Sun, 31 Jul 94 17:10:48 -0400 Date: Sun, 31 Jul 94 17:10:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9407312110.AA13303@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bill.simpson@um.cc.umich.edu Subject: Re: Whither 8 bytes? Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" It was depressing to learn that we have become so politically rather than technically oriented that we now choose to make decisions which make everyone equally unhappy, rather than decisions which make one faction happy. What magic process do you suggest that will tell us which technical faction is correct? There will be a few other opportunities to challenge that decision, during the last call, and based on real implementation experience. I find it extremely unlikely that that particular decision (for fixed-size 16-byte addresses) will be changed. I believe that this list will continue, as the charter list for IPng issues, until the IPng Directorate disbands. I'd have thought that all the IPng, err, IPv6 related issues would be handled on the appropriate list; sipp, or whatever. I just don't see the point of this list anymore. Perhaps there's some use for a list for people who think we do need a fundamentally different architecture, but this list is clearly not it. Noel From owner-Big-Internet@munnari.OZ.AU Mon Aug 1 08:13:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01384; Mon, 1 Aug 1994 08:13:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA05331; Mon, 1 Aug 1994 08:13:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA05312; Mon, 1 Aug 1994 08:02:02 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01014; Mon, 1 Aug 1994 08:01:59 +1000 (from sob@hsdndev.harvard.edu) Date: Sun, 31 Jul 94 18:01:47 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9407312201.AA21892@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU, bill.simpson@um.cc.umich.edu, jnc@ginger.lcs.mit.edu Subject: Re: Whither 8 bytes? > I'd have thought that all the IPng, err, IPv6 related issues would be handled > on the appropriate list; sipp, or whatever. A new mailing list is being set up, an announcement will be made soon. Scott From owner-Big-Internet@munnari.OZ.AU Mon Aug 1 09:53:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05937; Mon, 1 Aug 1994 09:53:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA05428; Mon, 1 Aug 1994 09:53:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA05423; Mon, 1 Aug 1994 09:52:35 +1000 Precedence: list Received: from osi-east.es.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05878; Mon, 1 Aug 1994 09:52:29 +1000 (from aiken@es.net) Message-Id: <9407312352.5878@munnari.oz.au> Received: from sas.nersc.gov by osi-east.es.net via ESnet SMTP service id <16898-0@osi-east.es.net>; Sun, 31 Jul 1994 16:52:09 +0000 Received: from [128.55.128.99] (slip-aiken.nersc.gov) by sas.nersc.gov with SMTP (1.37.109.11/16.3) id AA229008710; Sun, 31 Jul 1994 16:51:50 -0700 X-Sender: aiken@sas.nersc.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 31 Jul 1994 19:51:44 -0500 To: big-internet@munnari.OZ.AU From: aiken@es.net (Robert J. Aiken) Subject: Re: IPng recommendation Cc: ietf@cnri.reston.va.us, pvm@isi.edu >Dear IETFers: > >The IPng Area Directors made their recommendation last week during the >Monday morning plenary session at the Toronto IETF meeting. Here >is a brief summary announcement, for those who weren't present in >person or by MBONE. > >The recommendation specifies a new IPng protocol which simplifies the basic >packet format, generalizes a number of the basic processing mechanisms, and >provides a powerful extension facility to allow further evolution of the >protocol's capabilities in a transparent manner. The new IPng design >provides for a 16-byte address, which, along with address format design >and address plan development, will provide the Internet with needed >addressing flexibility and scale. Support for ubiquitous multimedia and >mobility is offered by the new design as well. For my, and I'm sure others who could not make it to the last IETF mtg, benefit - How was the recommendation arrived at and what was the criteria? IN advance - thank you for your effort and patience on this matter. bob aiken Bob Aiken U S Department of Energy/LLNL ER-30, GTN Washington, DC, USA 20585 +1-301-903-9960 Fax = +1-301-903-7774 aiken@es.net Nec Temere Nec Timide "neither rashly nor timidly" From owner-Big-Internet@munnari.OZ.AU Mon Aug 1 10:13:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06702; Mon, 1 Aug 1994 10:13:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05471; Mon, 1 Aug 1994 10:13:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05466; Mon, 1 Aug 1994 10:12:42 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06671; Mon, 1 Aug 1994 10:12:31 +1000 (from sob@hsdndev.harvard.edu) Date: Sun, 31 Jul 94 20:12:16 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9408010012.AA26390@hsdndev.harvard.edu> To: aiken@es.net, big-internet@munnari.OZ.AU Subject: Re: IPng recommendation Cc: ietf@cnri.reston.va.us, pvm@isi.edu Bob, > How was the recommendation arrived at and what was the criteria? If you can I'd suggest taking a look at the presentation that we did in Toronto. As mentioned in the posting, text and PostScript versions are on hsdndev.harvard.edu in pub/ipng/presentations. The short answer is that the criteria are detailed in the internet-draft draft-kastenholz-ipng-criteria-02.txt. Scott From owner-Big-Internet@munnari.OZ.AU Mon Aug 1 14:14:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15219; Mon, 1 Aug 1994 14:14:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA05687; Mon, 1 Aug 1994 14:13:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA05682; Mon, 1 Aug 1994 14:12:45 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00794; Mon, 1 Aug 1994 07:53:24 +1000 (from sob@hsdndev.harvard.edu) Received: from [128.103.202.40] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00305 Mon, 1 Aug 1994 07:34:37 +1000 (from sob@hsdndev.harvard.edu) Date: Sun, 31 Jul 94 17:31:45 -0400 Message-Id: <9407312131.AA20556@hsdndev.harvard.edu> Reply-To: big-internet@munnari.OZ.AU From: The@cs.mu.OZ.AU, IPng@cs.mu.OZ.AU, Area@cs.mu.OZ.AU, Directors@hsdndev.harvard.edu Subject: IPng recommendation Sender: sob@harvard.edu Status: R Apparently-To: big-internet@munnari.OZ.AU Dear IETFers: The IPng Area Directors made their recommendation last week during the Monday morning plenary session at the Toronto IETF meeting. Here is a brief summary announcement, for those who weren't present in person or by MBONE. The recommendation specifies a new IPng protocol which simplifies the basic packet format, generalizes a number of the basic processing mechanisms, and provides a powerful extension facility to allow further evolution of the protocol's capabilities in a transparent manner. The new IPng design provides for a 16-byte address, which, along with address format design and address plan development, will provide the Internet with needed addressing flexibility and scale. Support for ubiquitous multimedia and mobility is offered by the new design as well. The IPng design also explicitly addresses two significant operational concerns, network autoconfiguration and network security. The security and autoconfiguration features are integral to the design of IPng and reflect a strong, new focus within the IETF on expanding network security and improving the ease-of-ownership for IP-based networks. IPng autoconfiguration provides for both server-less plug-and-play popularized by Apple Macintosh networking as well as centrally-administered server-based autoconfiguration typified by Novell's IPX and the IETF Dynamic Host Configuration Protocol used with IPv4. The network security functions of IPng provide for authentication and privacy at the IPng datagram delivery level, thereby offering protection to all protocols riding above IPng. In the existing Internet, security is largely viewed as an application concern and is not addressed in a truly unified manner. While IPng does not immediately dictate a comprehensive security architecture for the entire global Internet, the features in IPng provide the mechanisms for implementing local and regional security models. Deploying a global Internet security architecture must await resolution of larger policy issues beyond the scope of providing sufficient technology within IPng. The path forward will follow the existing IETF standards process. A new IPng working group will be created chaired by Ross Callon of Wellfleet and Steve Deering of Xerox PARC, with Bob Hinden of SUN Microsystems serving as document editor. Additional working groups targeting the autoconfiguration and transition requirements will also be formed. Dave Clark of MIT has agreed to review the proposal details and to help coordinate the multi-prong effort. The working groups will complete and finalize the protocol specification documents and submit them for Proposed Standard status. The baseline protocol documents for the working groups include: S. Deering - Simple Internet Protocol Plus (SIPP) Spec. (16-byte address version) P. Francis et. al. - SIPP Addressing Architecture Y. Rekhter & T. Li - An Architecture for SIPP-16 Address Allocation R. Gilligan - Simple SIPP Transition (SST) Overview R. Atkinson - SIPP Security Architecture R. Atkinson - SIPP Authentication Header P. Ford et. al. - SDRP Routing Header Format for SIPP-16 The target schedule for this work is: August 1994 - First test implementations derived from existing SIPP-8 development Date TBD - Mid-month MBONE meeting to walk through IPng design September 1994 - Protocol documents available as Internet Drafts for review December 1994 - Protocol documents submitted as proposed standards July 1995 - First beta versions of release-quality software December 1995 - Initial scaling tests and field trials complete December 1995 - First production software releases While this is clearly an aggressive schedule, the talents of the world-wide IETF community are now sharply focused on one IPng protocol design, its implementation and rapid deployment. To this end, significant multi- national governmental, institutional, and commercial support has already been pledged to help ensure that work required for deployment moves forward as quickly as possible. Text and PostScript copies of the Toronto presentation are available from hsdndev.harvard.edu in pub/ipng/presentations. The full recommendation will be published as an Internet-Draft soon. Scott & Allison sob@harvard.edu mankin@itd.nrl.navy.mil (PS. Our thanks to Mike O'Dell for taking the time to put together this announcement while we started to catch up on our sleep.) From owner-Big-Internet@munnari.OZ.AU Tue Aug 2 01:34:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08194; Tue, 2 Aug 1994 01:34:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA06371; Tue, 2 Aug 1994 01:33:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06353; Tue, 2 Aug 1994 01:18:27 +1000 Precedence: list Received: from madrid.eng.isas.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07702; Tue, 2 Aug 1994 01:18:18 +1000 (from jm@eng.isas.ac.jp) Received: from localhost by madrid.eng.isas.ac.jp (5.67b/J-1.6) id AA22919; Tue, 2 Aug 1994 00:18:01 +0900 Message-Id: <199408011518.AA22919@madrid.eng.isas.ac.jp> To: Big-Internet@munnari.OZ.AU Cc: Jun Matsukata Subject: subscribe Date: Tue, 02 Aug 1994 00:18:00 +0900 From: Jun Matsukata =?ISO-2022-JP?B?GyRCPj5KfSEhPWMbKEI=?= Please add me to the Big-Internet mailing list. Jun Matsukata jm@eng.isas.ac.jp From owner-Big-Internet@munnari.OZ.AU Tue Aug 2 11:51:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22078; Tue, 2 Aug 1994 08:34:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA06737; Tue, 2 Aug 1994 08:34:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06721; Tue, 2 Aug 1994 08:16:23 +1000 Precedence: list Received: from uswat.advtech.uswest.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20471; Tue, 2 Aug 1994 07:43:39 +1000 (from jrc@atqm.advtech.uswest.com) Received: from atqm.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA11672 (5.67b/IDA-1.5 for ); Mon, 1 Aug 1994 15:43:35 -0600 Message-Id: <199408012143.AA11672@uswat.advtech.uswest.com> Date: 1 Aug 1994 15:46:13 U From: "John Chang" Subject: Re: FWD>>IPng recommendatio To: nahluwal@atqm.advtech.uswest.com, big-internet@munnari.OZ.AU, kfc@atqm.advtech.uswest.com, eclark@atqm.advtech.uswest.com, rje@atqm.advtech.uswest.com, sbe@atqm.advtech.uswest.com, cfuller@atqm.advtech.uswest.com, dhashman@atqm.advtech.uswest.com, hhuggen@atqm.advtech.uswest.com, mkrawcz@atqm.advtech.uswest.com, rleight@atqm.advtech.uswest.com, jnm@atqm.advtech.uswest.com, georgem@atqm.advtech.uswest.com, onewnan@atqm.advtech.uswest.com, knp@atqm.advtech.uswest.com, kpierce@atqm.advtech.uswest.com, jpoitevi@atqm.advtech.uswest.com, mstowe@atqm.advtech.uswest.com, sturm@atqm.advtech.uswest.com Reply to: RE>>FWD>>IPng recommendation Yes, I'll have a trip report on the subect in the next few days. -------------------------------------- Date: 8/1/94 13:15 To: John Chang From: Ron Egan yes, indeed......john chang is the cag/sme for additional info. -------------------------------------- Date: 8/1/94 12:59 PM To: Ron Egan From: John Poitevin FYI, this is something important to follow. Rick -------------------------------------- Date: 8/1/94 7:52 AM From: big-internet@munnari.oz.au [Sorry if you receive duplicates -- this is being re-sent to the IETF-Announce list so it will reach more people.] Dear IETFers: The IPng Area Directors made their recommendation last week during the Monday morning plenary session at the Toronto IETF meeting. Here is a brief summary announcement, for those who weren't present in person or by MBONE. The recommendation specifies a new IPng protocol which simplifies the basic packet format, generalizes a number of the basic processing mechanisms, and provides a powerful extension facility to allow further evolution of the protocol's capabilities in a transparent manner. The new IPng design provides for a 16-byte address, which, along with address format design and address plan development, will provide the Internet with needed addressing flexibility and scale. Support for ubiquitous multimedia and mobility is offered by the new design as well. The IPng design also explicitly addresses two significant operational concerns, network autoconfiguration and network security. The security and autoconfiguration features are integral to the design of IPng and reflect a strong, new focus within the IETF on expanding network security and improving the ease-of-ownership for IP-based networks. IPng autoconfiguration provides for both server-less plug-and-play popularized by Apple Macintosh networking as well as centrally-administered server-based autoconfiguration typified by Novell's IPX and the IETF Dynamic Host Configuration Protocol used with IPv4. The network security functions of IPng provide for authentication and privacy at the IPng datagram delivery level, thereby offering protection to all protocols riding above IPng. In the existing Internet, security is largely viewed as an application concern and is not addressed in a truly unified manner. While IPng does not immediately dictate a comprehensive security architecture for the entire global Internet, the features in IPng provide the mechanisms for implementing local and regional security models. Deploying a global Internet security architecture must await resolution of larger policy issues beyond the scope of providing sufficient technology within IPng. The path forward will follow the existing IETF standards process. A new IPng working group will be created chaired by Ross Callon of Wellfleet and Steve Deering of Xerox PARC, with Bob Hinden of SUN Microsystems serving as document editor. Additional working groups targeting the autoconfiguration and transition requirements will also be formed. Dave Clark of MIT has agreed to review the proposal details and to help coordinate the multi-prong effort. The working groups will complete and finalize the protocol specification documents and submit them for Proposed Standard status. The baseline protocol documents for the working groups include: S. Deering - Simple Internet Protocol Plus (SIPP) Spec. (16-byte address version) P. Francis et. al. - SIPP Addressing Architecture Y. Rekhter & T. Li - An Architecture for SIPP-16 Address Allocation R. Gilligan - Simple SIPP Transition (SST) Overview R. Atkinson - SIPP Security Architecture R. Atkinson - SIPP Authentication Header P. Ford et. al. - SDRP Routing Header Format for SIPP-16 The target schedule for this work is: August 1994 - First test implementations derived from existing SIPP-8 development Date TBD - Mid-month MBONE meeting to walk through IPng design September 1994 - Protocol documents available as Internet Drafts for review December 1994 - Protocol documents submitted as proposed standards July 1995 - First beta versions of release-quality software December 1995 - Initial scaling tests and field trials complete December 1995 - First production software releases While this is clearly an aggressive schedule, the talents of the world-wide IETF community are now sharply focused on one IPng protocol design, its implementation and rapid deployment. To this end, significant multi- national governmental, institutional, and commercial support has already been pledged to help ensure that work required for deployment moves forward as quickly as possible. Text and PostScript copies of the Toronto presentation are available from hsdndev.harvard.edu in pub/ipng/presentations. The full recommendation will be published as an Internet-Draft soon. Scott & Allison sob@harvard.edu mankin@itd.nrl.navy.mil (PS. Our thanks to Mike O'Dell for taking the time to put together this announcement while we started to catch up on our sleep.) ------------------ RFC822 Header Follows ------------------ Received: by atqm.advtech.uswest.com with SMTP;1 Aug 1994 07:52:31 U Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by uswat.advtech.uswest.com with SMTP id AA23893 (5.67b/IDA-1.5 for ); Mon, 1 Aug 1994 07:46:09 -0600 Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02604; 1 Aug 94 9:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02456; 1 Aug 94 9:23 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05734; 1 Aug 94 9:23 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02450; 1 Aug 94 9:23 EDT Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: "The IPng Area Directors"@hsdndev.harvard.edu To: IETF-Announce: ; Reply-To: big-internet@munnari.oz.au Subject: IPng recommendation Date: Mon, 01 Aug 94 09:23:18 -0400 X-Orig-Sender: jstewart@CNRI.Reston.VA.US Message-Id: <9408010923.aa02450@IETF.CNRI.Reston.VA.US> From owner-Big-Internet@munnari.OZ.AU Wed Aug 3 11:14:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19125; Wed, 3 Aug 1994 11:14:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08187; Wed, 3 Aug 1994 11:14:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08182; Wed, 3 Aug 1994 11:10:31 +1000 Precedence: list Received: from pluto.dss.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15600; Wed, 3 Aug 1994 09:43:45 +1000 (from martillo@pluto.dss.com) Received: by pluto.dss.com (4.1/SMI-4.0) id AA20981; Tue, 2 Aug 94 19:39:42 EDT Date: Tue, 2 Aug 94 19:39:42 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9408022339.AA20981@pluto.dss.com> To: big-internet@munnari.OZ.AU Cc: ietf@CNRI.Reston.VA.US, martillo@pluto.dss.com Subject: Re: IPng recommendation After noticing some of the discussion of IPng criteria, I ftp'd over the criteria. Exactly how to interpret this document is unclear. ISO, CCITT, ANSI and IEEE documents can have problems, but the authors usually are attempting to be serious and precise. This document seems to attempt humor with cutesy section titles, but calculations of a need to support 10**15 end-hosts (about 250,000 per human) make the document rather risible. >INTERNET DRAFT >Technical Criteria for Choosing >IP:The Next Generation (IPng) >draft-kastenholz-ipng-criteria-02.txt >25 May 1994 >Frank Kastenholz >FTP Software, Inc >2 High Street >North Andover, Mass 01845-2620 USA >kasten@ftp.com >Craig Partridge >BBN Systems and Technologies >craig@aland.bbn.com >1. Introduction >This memo presents a set of criteria that the authors' believe >should be used to help evaluate protocols being proposed for >adoption as the next generation of IP. >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. >This does NOT say that the Internet is a One-Protocol >Internet. The Internet is today, and shall remain in the >future, a Multi-Protocol Internet. Multi-Protocol operations >are required to allow for continued testing, experimentation, >and development and because service providers' customers >clearly want to be able to run protocols such as CLNP, DECNET, >and Novell over their Internet connections. This point is reasonable because as a manufacturing regime the IETF should not produce standards 1) which cause problems in a multiprotocol environment, 2) which favor IP to the detriment of multiprotocol interworking or 3) which in other ways discourage cost-effective, productive use of multiprotocol internetworks. >5.3. Performance >CRITERION >A state of the art, commercial grade router must be able >to process and forward IPng traffic at speeds capable of >fully utilizing common, commercially available, high- >speed media at the time. Furthermore, at a minimum, a >host must be able to achieve data transfer rates with >IPng comparable to the rates achieved with IPv4, using >similar levels of host resources. Since poor router performance can affect a whole internet rather than simply an individual host, the criterion should have concentrated attention on router performance. After all, it is conceiveable that an individual host with a single interface can achieve full bandwidth utilization but the performance of a router with many interfaces might suffer tremendously from misdesign of a next generation IP. The converse case seems unlikely where a router with many interfaces might achieve full bandwidth utilization while an individual host with a single interface might perform miserably. >DISCUSSION >Network media speeds are constantly increasing. It is >essential that the Internet's switching elements >(routers) be able to keep up with the media speeds. >We limit this requirement to commercially available >routers and media. If some network site can obtain a >particular media technology "off the shelf", then it >should also be able to obtain the needed routing >technology "off the shelf." One can always go into some >laboratory or research center and find newer, faster, >technologies for network media and for routing. We do >believe, however, that IPng should be routable at a speed >sufficient to fully utilize the fastest available media, >though that might require specially built, custom, >devices. This comment suggests that the new address structure should enable the quickest possible route look-up. The quickest possible route look-up means that a network number should conveniently correspond to a natural register size on common communications computers and that accesses to slower processor external memory should be minimized. Such needs and 16 byte addresses are hard to reconcile with current router technology. >We expect that more and more services will be available >over the Internet. It is not unreasonable, therefore, to >expect that the ratio of "local" traffic (i.e. the >traffic that stays on one's local network) to "export" >traffic (i.e. traffic destined to or sourced from a >network other than one's own local network) will change, >and the percent of export traffic will increase. This observation is not obviously true. As file servers, database servers, multimedia servers and other network resources become cheaper, such resources are likely to become increasingly available locally. While export traffic apparently increases absolutely, the ratio of export traffic to local traffic actually decreases. Anticipating such results in 1987-1988, Tony Bono and I designed the Constellation Series packet switches to be configureable as shake-and-bake IMPs, wire-speed LAN switches, fully powered-bridges and multiprotocol routers or any mixed combination thereof in order to serve all possible network needs. IPng must be conducive of such designs in order to meet user needs flexibly and cost-effectively. A concentration on export traffic in the design of IPng would be misguided. >We note that the host performance requirement should not >be taken to imply that IPng need only be as good as IPv4. >If an IPng candidate can achieve better performance with >equivalent resources (or equivalent transfer rates with >fewer resources) vis-a-vis IPv4 then so much the better. >We also observe that many researchers believe that a >proper IPng router should be capable of routing IPng >traffic over links at speeds that are capable of fully >utilizing an ATM switch on the link. ATM is yet another fad technology whose fad may be approaching its end. I have recently read that several companies which had started ATM development efforts had abandoned these efforts as pointless. A better targer might be wire-speed routing in the context of a LAN switch using fast Ethernet or CDDI. BTW, after groveling through numerous packet switching implementations and network drivers, almost invariably I have found that bottlenecks and low performance have been due not to protocol design but poor software implementations or (often even more importantly) due to the host OS architecture. The protocol design has generally been an extremely minor component of network/packet-switching performance. >Processing of the IPng header, and subsequent headers >(such as the transport header), can be made more >efficient by aligning fields on their natural boundaries >and making header lengths integral multiples of typical >word lengths (32, 64, and 128 bits have been suggested) >in order to preserve alignment in following headers. >We point out that optimizing the header's fields and >lengths only to today's processors may not be sufficient >for the long term. Processor word and cache-line >lengths, and memory widths are constantly increasing. This comment suggests that IPng should not be designed to optimal performance on today's processors because it is better to design for optimal performance on tomorrow's processors. Thus if IPng is a dead dog with fleas on today's processors, that level of performance is okay because in 10 years it might be a screamer. Of course, a system which is a dead dog with fleas is hardly going to acrue any installed base. If such be the case, maybe we should not take this document seriously at all. > In >doing header optimizations, the designer should predict >word-widths one or two CPU generations into the future >and optimize accordingly. If IPv4 and TCP had been >optimized for processors common when they were designed, >they would be very efficient for 6502s and Z-80s. Actually IPv4 and TCP were designed for processors common at the time in the environments where the designers worked. Such processors included 36 bit Honeywell, 24 bit BBN and other reasonably powered machines with reasonably large real or virtual address spaces. Such machines were rather more powerful than 6502s and Z-80s. IPv4 and TCP transitted well to today's microprocessor systems not because of scaleability inherent in the original design, which targeted the machines available to the developers at that time, but because microprocessor systems became reasonably powerful with reasonably large real and virtual address spaces comparable to the machines on which early IP and TCP development took place. >5.4. Robust Service >CRITERION >The network service and its associated routing and >control protocols must be robust. Would anyone want a network service and routing protocols which broke all the time? >DISCUSSION >Murphy's Law applies to networking. And of course as a corollary the Peter Principle applies to those organizations which endeavor to develop networking standards. >Some predictions have been made that, as the Internet >grows and as more and more technically less-sophisticated >sites get connected, there will be more failures in the >network. These failures may be a combination of simple >size; if the size of the network goes up by a factor of n >then the total number of failures in the network can be >expected to increase by some function of n. Also, as the >network's users become less sophisticated, it can be >assumed that they will make more, innocent and well >meaning, mistakes, either in configuration or use of >their systems. This comment is just the typical obnoxious snobbishness of communications software engineers. If anything, the level of sophistication will probably increase with an increase in the number of sites which connect to the internet. Nowadays, someone who knows a little is a guru and technical wizard who feels obligated to produce reams of IETF draft documents. When lots of people have set up and run multiprotocol internetworks, a little knowledge will hardly impress anybody. >Time Frame >Protection against Byzantine failure modes is not needed >immediately. A proposed architecture for it should be >done immediately. Is enough known today about the Byzantine failure modes of the not yet realized IPng to create such a architecture immediately? > Prototype development should be >completed in 12-18 months, with final deployment as >needed. One would think there might be a need for a reasonable testing plan and test period after such prototype development. >5.5. Transition >CRITERION >The protocol must have a straightforward transition plan >from the current IPv4. >DISCUSSION >A smooth, orderly, transition from IPv4 to IPng is >needed. If we can't transition to the new protocol, then >no matter how wonderful it is, we'll never get to it. >We believe that it is not possible to have a "flag-day" >form of transition in which all hosts and routers must >change over at once. The size, complexity, and >distributed administration of the Internet make such a >cutover impossible. >The transition plan should address the issue of cost >distribution. That is, it should identify what tasks are >required of the service providers, of the end users, of >the backbones and so on. This comment is rather scary. The IETF collectively has no obvious expertise in public finance, accounting or political economics. The one area where the IETF has tried to distribute costs is network management, and in this case the IETF has managed to make small installations subsidize the development of SNMP on behalf of a few large network providers even though the small installations have no real need of such a thing. >Time Frame >A transition plan is required immediately. Whenever DECNET was transitioned from one Phase to the next, DEC provided a transition plan and strategy, studying how DECNET and other similar networking suites in similar situations were transitioned in the past might provide insights how to transition IP efficiently and with minimal dislocation and cost. >5.8. Configuration, Administration, and Operation This section is confusing. >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 require that a node be able to dynamically obtain all >of its operational, IP-level parameters at boot time via >a dynamic configuration mechanism. Being able to obtain network level parameters at boot time and full plug-and-play are quite different concepts. If the boot server has to be configured, that requirement makes the device which needs the boot server something other than plug and play. In addition, a host may not be able to find out its routers until long after boot time. In fact, if a new router is added to a network with new network numbers, all the hosts might have to forget their old networks and learn new networks and addresses. The boot parameters issue is almost completely orthogonal to plug-and-play auto-configurability. >Also, a strength of IPv4 has been its ability to be used >on isolated subnets. IPng hosts must be able to work on >networks without routers present. Who designs a networking suite which requires routers on a single communications subet? >5.12. Multicast >CRITERION >The protocol must support both unicast and multicast >packet transmission. Part of the multicast capability is >a requirement to be able to send to "all IP hosts on a >given subnetwork". Dynamic and automatic routing of >multicasts is also required. >DISCUSSION >IPv4 has made heavy use of the ability to multicast >requests to all IPv4 hosts on a subnet, especially for >autoconfiguration. This ability must be retained in >IPng. >Unfortunately, IPv4 currently uses the local media >broadcast address to multicast to all IP hosts. This >behavior is anti-social in mixed-protocol networks and >should be fixed in IPng. There's no good reason for IPng >to send to all hosts on a subnet when it only wishes to >send to all IPng hosts. The protocol must make >allowances for media that do not support true >multicasting. The above comment is idiotic. Exactly how a network layer multicast is resolved to a MAC layer address for some arbitrary medium is not obviously part of the network layer design. In any case, if a medium only supported a single broadcast and physical addresses, network multicasts would have to use the broadcast. Furthermore, as Appletalk has abundantly shown a protocol that uses multicast exclusively can certainly be antisocial in the sense of burning up a lot of bandwidth. >5.17. Private Networks >CRITERION >IPng must allow users to build private internetworks on >top of the basic Internet Infrastructure. Both private >IP-based internetworks and private non-IP-based (e.g., >CLNP or Appletalk) internetworks must be supported. >DISCUSSION >We note that, today in the IPv4 Internet, tunneling is >widely used to provide these capabilities. Because of the inefficiencies associated with routing via tunnels and because of the difficulties associated with debugging tunneled networks, tunneling is an extremely problematic approach to use or to encourage. Because multiprotocol routers are so common today, tunneling non-IP suites through IP is just silly except in cases of router misdesign in which case a new router should probably be obtained. In providing IPv4 end-host to IPng end-host connectivity, the DECNET phase III to phase IV approach which interconverts phase III and phase IV packets where possible and when needed probably makes more sense. >5.18. Things We Chose Not to Require >Fragmentation >The technology exists for path MTU discovery. >Presumably, IPng will continue to provide this >technology. Therefore, we believe that IPng >Fragmentation and Reassembly, as provided in IPv4, is not >necessary. We note that fragmentation has been shown to >be detrimental to network performance and strongly >recommend that it be avoided. In some circumstances fragmentation and reassembly can cost something (but not always -- the Constellation X.25 fragmentation and reassembly routines are costless), but fragmentation provides a fairly straightforward means to deal with a serious internetworking problem. I am not sure how MTU discovery overcomes the need for fragmentation unless MTU discovery is performed before each packet is sent and strict source routing is employed. OSPF and IGRP load share on equal cost paths (IGRP will actually share proportionately on non-equal cost paths). Unless all equal cost (or near equal cost) paths have the same MTU, not fragmenting could easily 1) lead to non-obvious transitory network failures, 2) force all networks to resort to the use of least common denominator packet sizes or 3) compel continuous redetermination of MTU to a specific destination host. Load sharing over equal cost paths is probably unnecessary for the occurrence of such problems. These problems might occur in a sufficiently large network with complex topology where path changes happened fairly frequently. >IP Header Checksum >There has been discussion indicating that the IP Checksum >does not provide enough error protection to warrant its >performance impact. The argument states that there is >almost always a stronger datalink level CRC, and that >end-to-end protection is provided by the TCP checksum. >Therefore we believe that an IPng checksum is not >required per-se. The IP header checksum is not intended to provide end-to-end data integrity but rather provides local address integrity. Few routers provide EDAC. Stuck bits in the wrong place after receive datalink CRC is calculated could easily cause some poor neighboring router to be inundated with misdirected packets whose lack of data integrity might not be detected until much later or even never (if the new address corresponds to no actual address). This problem could be particularly serious in the cases of applications which rarely or infrequently require acknowledgement of transmitted data packets. Doing away with IP header checksum is probably bad. I think I understand the motivation. Because many routers are inefficiently coded, many routers (but not the Constellation series) steal back some cycles by ignoring IP header checksum. The developers of such routers would like the IETF to legitimize the unsavory behavior of these routers. >6. Routing >Routing is a very critical part of the Internet. In fact, the >Internet Engineering Task Force has a separate Area which is >chartered to deal only with routing issues. This Area is >separate from the more general Internet Area. >We see that routing is also a critical component of IPng. >There are several criteria, such as Scaling, Addressing, and >Network Services, which are intimately entwined with routing. Shouldn't routing performance be included among these critical components? Of course if we worried about performance, would we not have some questions about performance on lower speed WAN connections as well as the ability to support the latest and greatest high speed media? For instance, everyone is so concerned about the effect of headers on WAN performance, but the currently proposed IPng has a single network address field which is 16 bytes and which is therefore only 4 bytes less than the whole standard IPv4 header. >In order to stress the critical nature and importance of >routing, we have chosen to devote a separate chapter to >specifically enumerating some of the requirements and issues >that IPng routing must address. All of these issues, we >believe, fall out of the general criteria presented in the >previous chapter. >6.5. Stability >With the addition of additional data into the routing system >(i.e. routes are based not only on connectivity, as in IPv4, >but also on policies, service grades, and so on), the >stability of the routes may suffer. We offer as evidence the >early Arpanet which experimented with load-based routing. >Routes would remain in flux, changing from one saturated link, >to another, unused, link. >This must not be allowed to happen. If anything, routes >should be even more stable under IPng's routing architecture >than under the current architecture. Does this mean load sharing between equal cost and near equal cost routes (IGRP) is to be dropped from the architecture? In summary, there are lots of problems with this IPng criteria document. Did people really seriously use it to deliberate on the various proposals for the new IP? Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com From owner-Big-Internet@munnari.OZ.AU Wed Aug 3 12:54:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23076; Wed, 3 Aug 1994 12:54:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08310; Wed, 3 Aug 1994 12:54:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08276; Wed, 3 Aug 1994 12:48:05 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21223; Wed, 3 Aug 1994 12:11:14 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id TAA21430; Tue, 2 Aug 1994 19:10:58 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Aug 1994 19:11:04 -0700 To: Joachim Martillo From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPng recommendation Cc: big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US, martillo@pluto.dss.com Joachim, I, for one, would like to thank you for your timely contribution to the IPng discussions. d/ ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA) From owner-Big-Internet@munnari.OZ.AU Wed Aug 3 18:34:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06107; Wed, 3 Aug 1994 18:34:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA08679; Wed, 3 Aug 1994 18:34:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA08674; Wed, 3 Aug 1994 18:32:14 +1000 Precedence: list Received: from mail.physics.ox.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06050; Wed, 3 Aug 1994 18:32:04 +1000 (from j.macallister1@physics.oxford.ac.uk) Received: from av1.physics.ox.ac.uk by mail.physics.ox.ac.uk with SMTP (5.65c+/IDA-1.4.4-UK-t for ) id AA03203; Wed, 3 Aug 1994 09:30:16 +0100 Date: Wed, 3 Aug 1994 9:33:37 +0100 (BST) From: John Macallister To: martillo@pluto.dss.com Cc: big-internet@munnari.OZ.AU, MACALLSTR@v1.ph.ox.ac.uk Message-Id: <940803093337.28800242@v1.ph.ox.ac.uk> Subject: Re: IPng recommendation This is the sort of input which would have been useful BEFORE the meeting as it's clearly come from someone who has done some real work in software design for the real World. John From owner-Big-Internet@munnari.OZ.AU Wed Aug 3 18:54:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06757; Wed, 3 Aug 1994 18:54:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA08714; Wed, 3 Aug 1994 18:54:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA08709; Wed, 3 Aug 1994 18:53:25 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06731; Wed, 3 Aug 1994 18:53:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23809; Wed, 3 Aug 94 04:53:05 -0400 Date: Wed, 3 Aug 94 04:53:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9408030853.AA23809@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, j.macallister1@physics.oxford.ac.uk Subject: Re: IPng recommendation Cc: jnc@ginger.lcs.mit.edu From: John Macallister the sort of input ... it's clearly come from someone who has done some real work in software design for the real World. Well, I'm sure there are those would say that Martillo inhabits his own little private world... :-) Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 3 18:55:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06806; Wed, 3 Aug 1994 18:55:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA08742; Wed, 3 Aug 1994 18:55:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA08706; Wed, 3 Aug 1994 18:41:30 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04310; Wed, 3 Aug 1994 17:43:48 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 3 Aug 1994 08:43:16 +0100 To: Joachim Martillo Cc: big-internet@munnari.OZ.AU Subject: Re: IPng recommendation In-Reply-To: Your message of "Tue, 02 Aug 94 19:39:42 EDT." <9408022339.AA20981@pluto.dss.com> Date: Wed, 03 Aug 94 08:43:15 +0100 Message-Id: <595.775899795@cs.ucl.ac.uk> From: Jon Crowcroft >In summary, there are lots of problems with this IPng criteria >document. Did people really seriously use it to deliberate on >the various proposals for the new IP? yes, vigourously in public..... _all_ of the points you make were discussed at great length i think reading the archive of this list (big-internet, not IETF, which i have removed from this reply) would reveal this and as to whether the IETF is capable of making econmic judgements: on what basis is anyone else? we are only making engineers judgements as to engienering costs; i doubt an accountant could understand the question. cheers jon From owner-Big-Internet@munnari.OZ.AU Thu Aug 4 05:08:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21371; Thu, 4 Aug 1994 02:15:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA09225; Thu, 4 Aug 1994 02:14:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA09209; Thu, 4 Aug 1994 02:07:50 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17701; Thu, 4 Aug 1994 00:18:29 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 3 Aug 1994 10:18:26 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 3 Aug 1994 10:18:26 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02333; Wed, 3 Aug 94 10:15:56 EDT Date: Wed, 3 Aug 94 10:15:56 EDT Message-Id: <9408031415.AA02333@mailserv-D.ftp.com> To: martillo@pluto.dss.com Subject: Re: IPng recommendation From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US Content-Length: 13031 Joachim, First of all, comments would have been preferred during the debate. Certainly before the IPng choice. Comments now are roughly akin to locking the barn door after the horse has run off, though since there is still IPNG development work to be done, I am sure that the IPng developers will carefully consider your points. Second, one of the 'principles' which Craig and I started using in refining the criteria was what has been called 'In your face' requirements. If the criteria were set at a relatively 'safe' or 'low' level, then that is all we might get. You mention, for example, 10**15 end nodes. If we had set, for example, 10**10 end nodes, then that is possibly all we would get. By setting a higher level, we may still get only 10**10, but we might also get more. Furthermore, by saying 10**15, the developers (and the rest of the community) may think more about what a truly ubiquious global internetwork might need and what it could do. > After noticing some of the discussion of IPng criteria, I ftp'd over > the criteria. Exactly how to interpret this document is unclear. This document, in its final form, was considered as a framework (not the only one) about which discussions of the various IPNG candidates could be held by the IPng directorate. You might, in effect, consider the section headings to be an 'agenda' of items to be evaluated in the various proposals. > >5.3. Performance > > >Furthermore, at a minimum, a > >host must be able to achieve data transfer rates with > >IPng comparable to the rates achieved with IPv4, using > >similar levels of host resources. > > Since poor router performance can affect a whole internet rather than > simply an individual host, the criterion should have concentrated > attention on router performance. It originally did. However, it was also pointed out that if IPng made host performance 'very bad' then, even if the routers were blindingly fast, IPng would be a loser. Furthermore, IPng really should not be perceived as a step backwards wrt IPv4. If IPng made hosts significantly slower then it would be just such a step. Now, this might all seem trivial, obvious, irrelevant, and motherhood. But, on the other hand, host performance was a major factor in the discussion about addressing on the big-i list. If host performance wasn't critical then that discussion may well have had a different outcome. > >We limit this requirement to commercially available > >routers and media. If some network site can obtain a > >particular media technology "off the shelf", then it > >should also be able to obtain the needed routing > >technology "off the shelf." One can always go into some > >laboratory or research center and find newer, faster, > >technologies for network media and for routing. We do > >believe, however, that IPng should be routable at a speed > >sufficient to fully utilize the fastest available media, > >though that might require specially built, custom, > >devices. > > This comment suggests that the new address structure should enable the > quickest possible route look-up. The quickest possible route look-up > means that a network number should conveniently correspond to a > natural register size on common communications computers and that > accesses to slower processor external memory should be minimized. > Such needs and 16 byte addresses are hard to reconcile with current > router technology. First, we attempted to stay as far away from dictating implementation as we could. Your comment implies that we should have said, for example, that addresses must have a 4-byte (or whatever number) network number field. This would be dangerously close to specifying the implementation, and not pointing out the problems that were to be solved. (By pointing out the problem, we in theory allowed for a qide variety of solutions.) Second, some people are envisioning that a majority of traffic in the future internet will be forwarded not based on topological information carried around in the packet, but rather on a smaller, more easily handled, 'flow-id' which would have the properties you talk about. I note that SIPP has such a flowid. > >We expect that more and more services will be available > >over the Internet. It is not unreasonable, therefore, to > >expect that the ratio of "local" traffic (i.e. the > >traffic that stays on one's local network) to "export" > >traffic (i.e. traffic destined to or sourced from a > >network other than one's own local network) will change, > >and the percent of export traffic will increase. > > This observation is not obviously true... A > concentration on export traffic in the design of IPng would be > misguided. Possibly. It also raises the possibility of new models of use for a commercial service Internet. Consider things like a home computer, or doing cable TV via the Internet. In these cases, ALL network traffic would be exported. Our hope is that the criteria document spurred some people to think about the future and what it might bring. > >We also observe that many researchers believe that a > >proper IPng router should be capable of routing IPng > >traffic over links at speeds that are capable of fully > >utilizing an ATM switch on the link. > > ATM is yet another fad technology whose fad may be approaching its > end...A better targer might be wire-speed routing in the context of a LAN > switch using fast Ethernet or CDDI. The base criterion does not mention any specific technology. We felt that we could not accurately predict what technology would be the 'right' technology in 5 or 10 years. After all, wrt your observation on ATM, only 1 or 2 years ago, many people were predicting that ATM would take over the world. We make the criterion apply to 'common commercial technology' which allows it to be flexible and to change over time for the next 10-20 years. > >Some predictions have been made that, as the Internet > >grows and as more and more technically less-sophisticated > >sites get connected, there will be more failures in the > >network. These failures may be a combination of simple > >size; if the size of the network goes up by a factor of n > >then the total number of failures in the network can be > >expected to increase by some function of n. Also, as the > >network's users become less sophisticated, it can be > >assumed that they will make more, innocent and well > >meaning, mistakes, either in configuration or use of > >their systems. > > This comment is just the typical obnoxious snobbishness of > communications software engineers. If anything, the level of > sophistication will probably increase with an increase in the number > of sites which connect to the internet....When lots of people have > set up and > run multiprotocol internetworks, a little knowledge will hardly > impress anybody. Perhaps. However, history may be against you. I recall an IETF in recent history (less than 2 years ago) where the terminal room was set up by a major organization. They couldn't understand _why_ we wanted domain name service available for the terminals and laptops. Also, we are envisioning a future where the entities who connect to the Internet will not be like they are today. They will be sites that are non-technical (in the networking sense) and probably will not have the system operations staff that current sites have. Imagine a dentist's office connecting to the network. This is also the reason why we are stressing a 'plug-and-play' configuration ability. The less that has to be configured, the less chance of making such errors. > >5.5. Transition > >The transition plan should address the issue of cost > >distribution. That is, it should identify what tasks are > >required of the service providers, of the end users, of > >the backbones and so on. > > This comment is rather scary. The IETF collectively has no obvious > expertise in public finance, accounting or political economics. The first step in figuring out the 'public finance, accounting or political economics' issues it to determine exactly what has to be done. That's all we are saying. > >5.12. Multicast > > >CRITERION > >The protocol must support both unicast and multicast > >packet transmission. Part of the multicast capability is > >a requirement to be able to send to "all IP hosts on a > >given subnetwork". Dynamic and automatic routing of > >multicasts is also required. > > >DISCUSSION > >IPv4 has made heavy use of the ability to multicast > >requests to all IPv4 hosts on a subnet, especially for > >autoconfiguration. This ability must be retained in > >IPng. > > >Unfortunately, IPv4 currently uses the local media > >broadcast address to multicast to all IP hosts. This > >behavior is anti-social in mixed-protocol networks and > >should be fixed in IPng. There's no good reason for IPng > >to send to all hosts on a subnet when it only wishes to > >send to all IPng hosts. The protocol must make > >allowances for media that do not support true > >multicasting. > > The above comment is idiotic. Exactly how a network layer multicast > is resolved to a MAC layer address for some arbitrary medium is not > obviously part of the network layer design. It says 'When mac-layer multicasting is available, use it in preference to broadcasts.' > Furthermore, as Appletalk > has abundantly shown a protocol that uses multicast exclusively can > certainly be antisocial in the sense of burning up a lot of bandwidth. This criterion does not say that one should use multicasts instead of unicasts. There are certain types of applications (eg multi-person conferencing, finding servers) where using unicasts is not the best way to go. If the existance of these applications is a given, then we have a choice of using MAC-level multicasts or broadcasts (where mcasts are available). We believe that multicasts are preferred in these situations. > >5.17. Private Networks > >DISCUSSION > >We note that, today in the IPv4 Internet, tunneling is > >widely used to provide these capabilities. > > Because multiprotocol routers are so common today, > tunneling non-IP suites through IP is just silly except in cases of > router misdesign in which case a new router should probably be > obtained. Maybe one is not tunneling non-IP traffic. Perhaps one is building a private IP network on top of the IP Internet to, for example, cooperatively develop and test new routing protocols. > >6. Routing > > >Routing is a very critical part of the Internet. In fact, the > >Internet Engineering Task Force has a separate Area which is > >chartered to deal only with routing issues. This Area is > >separate from the more general Internet Area. > > >We see that routing is also a critical component of IPng. > >There are several criteria, such as Scaling, Addressing, and > >Network Services, which are intimately entwined with routing. > > Shouldn't routing performance be included among these critical > components? What exactly is routing performance? There are at least three separate functions that are commonly subsumed under the term 'routing' and the performance could apply to any of the three. We believe that we have performance of Forwarding packets well covered. The other functions, information distribution (i.e. the routing protocols) and route calculation are harder to specify. Should we say that the 'Routing Protocols should be efficient' and 'Route calculation should be fast'? This seems too nebulous. > >6.5. Stability > >This must not be allowed to happen. If anything, routes > >should be even more stable under IPng's routing architecture > >than under the current architecture. > > Does this mean load sharing between equal cost and near equal cost > routes (IGRP) is to be dropped from the architecture? I don't see switching packets between the several paths of a multi-path route as route-flapping. I consider the paths of a a multi-path route as a single 'route' for the purposes of this discussion. The main reason that route flapping is considered 'bad' is that route setup in the future may take into account things other than mere reachability (see the work on integrated services). For a multi-path route to fit into this model, all paths would have to have the required service levels so swapping between any of the paths is really not an issue. The issue arises when the routing subsystems select a new path based on reachability but the necessary service levels are not available. The other problem with route flapping is that one may never get a route. The 'primary' route goes down. The routing subsystem starts to reconfigure to use an 'alternate' route and then the 'primary' comes back up. The routing subsystem then re-reconfigures to use the primary and it goes down again. Repeat. In doing multipath, this isn't really an issue since both paths are already 'active'. -- Frank Kastenholz From owner-Big-Internet@munnari.OZ.AU Thu Aug 4 09:48:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04877; Thu, 4 Aug 1994 08:55:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09564; Thu, 4 Aug 1994 08:54:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09559; Thu, 4 Aug 1994 08:48:40 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03516; Thu, 4 Aug 1994 08:21:17 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (mxchange.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00737; Wed, 3 Aug 94 15:20:41 PDT Received: from jurassic.Eng.Sun.COM by Eng.Sun.COM (8.6.9/SMI-4.1) id PAA27786; Wed, 3 Aug 1994 15:20:45 -0700 Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA21079; Wed, 3 Aug 1994 15:20:43 -0700 Date: Wed, 3 Aug 1994 15:20:43 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9408032220.AA21079@jurassic.Eng.Sun.COM> To: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM, catnip@world.std.com, tuba@lanl.gov Subject: IPng Working Group Mailing List A new mailing list has been created for the IP Next Generation working group. None of the existing ipng working group mailing lists were copied into this one. If you want to be on this list, you will need to subscribe. The ipng list is an open, automatically maintained mailing list. Complete list management instructions are attached. To subscribe send a message which contains in the message body: subscribe ipng to the address majordomo@sunroof.eng.sun.com This will subscribe the address from which you sent the request to the mailing list. Bob p.s. This list was announced at last week's IETF meeting as "ip-ng". If you subscribed via that name you do not have to re-subscribe. If you really like the old name, we set up an aliases which points to the new name. ===================================================================== IPng LIST MANAGEMENT INSTRUCTIONS ===================================================================== SUBSCRIBING =========== To subscribe to the ipng list, send the following in the body (not the subject line) of an email message to "Majordomo@sunroof.eng.sun.com": subscribe ipng This will subscribe the account from which you send the message to the ipng list. If you wish to subscribe another address instead (such as a local redistribution list), you can use a command of the form: subscribe ipng other-address@your_site.your_net If you expect to be sending contributions to the list from multiple addresses, please notify ipng-owner@sunroof.eng.sun.com of *all* addresses you expect to post from. Only postings from known subscribers are re-distributed to the list without human intervention. (This is to prevent mail loops.) UNSUBSCRIBING ============= To un-subscribe from ipng, send the following in the body (not the subject line) of an email message to "Majordomo@sunroof.eng.sun.com": unsubscribe ipng This will unsubscribe the account from which you send the message. If you are subscribed with some other address, you'll have to send a command of the following form instead: unsubscribe ipng other-address@your_site.your_net If you don't know what address you are subscribed with, you can send the following command to see who else is on the list (assuming that information isn't designated "private" by the owner of the list):o who ipng If you want to search non-private lists at this server, you can do that by sending a command like: which string This will return a list of all entries on all lists that contain "string". HELP ==== To find out more about the automated server and the commands it understands, send the following command to "Majordomo@sunroof.eng.sun.com": help If you feel you need to reach a human, send email to ipng-approval@sunroof.eng.sun.com POSTING ======= To post a message to the list, send it to ipng@sunroof.eng.sun.com. DO NOT SEND ADMINISTRATIVE QUERIES ABOUT THE LIST TO ipng ========================================================= All routine queries should be sent to majordomo@sunroof.eng.sun.com. This includes adding, removing, or changing any subscriber(s) e-mail address. If you need human intervention, send to ipng-approval@sunroof.eng.sun.com. From owner-Big-Internet@munnari.OZ.AU Fri Aug 5 04:41:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15488; Fri, 5 Aug 1994 03:56:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA10669; Fri, 5 Aug 1994 03:55:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA10664; Fri, 5 Aug 1994 03:51:18 +1000 Precedence: list Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15347; Fri, 5 Aug 1994 03:51:15 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA04358; Thu, 4 Aug 1994 10:51:13 -0700 Date: Thu, 4 Aug 1994 10:51:13 -0700 From: Dave Katz Message-Id: <199408041751.KAA04358@feta.cisco.com> To: craig@aland.bbn.com Cc: martillo@pluto.dss.com, big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US In-Reply-To: Craig Partridge's message of Thu, 04 Aug 94 10:17:06 -0700 <199408041717.KAA03791@aland.bbn.com> Subject: IPng recommendation I know it's off the subject (and water under the bridge), but this statement is not true and has never been. C'mon, Craig, you should know better. > Who designs a networking suite which requires routers on a single > communications subet? OSI used to and may still. From owner-Big-Internet@munnari.OZ.AU Fri Aug 5 05:15:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17791; Fri, 5 Aug 1994 05:15:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA10812; Fri, 5 Aug 1994 05:15:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA10792; Fri, 5 Aug 1994 04:59:05 +1000 Precedence: list Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14251; Fri, 5 Aug 1994 03:18:20 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15364 for big-internet@munnari.oz.au; Thu, 4 Aug 94 13:17:52 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA03791; Thu, 4 Aug 1994 10:17:08 -0700 Message-Id: <199408041717.KAA03791@aland.bbn.com> To: Joachim Martillo Cc: big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us Subject: Re: IPng recommendation In-Reply-To: Your message of Tue, 02 Aug 94 19:39:42 -0400. <9408022339.AA20981@pluto.dss.com> From: Craig Partridge Date: Thu, 04 Aug 94 10:17:06 -0700 Sender: craig@aland.bbn.com Hi: Let me see if I can reply to some of your concerns about the IPng criteria document. (I'll skip spots where you agreed with it and some spots where I wasn't sure of what the key point was). First off, the concern on 10**15 end-hosts. We're quite clear about why we said that. We derived it straight from other work which we felt wasn't quite demanding enough in terms of the number of devices in the home. The fact that it comes out to 250,000 addresses per human only reflects some of the Internet's difficulties with efficient address allocation. Second, about performance. I'm not quite sure what your concern is but it appears to be that we weren't firm enough about router performance. To which, sigh, I plead that we can't please everyone. Originally the performance section was pretty explicit that we believe that with a properly designed IPng, certain explicit levels of router performance could be achieved. But folks pointed out that having an experimental router that could achieve a certain speed would meet the requirement but not achieve our goal and that a better approach was, given that we know higher speed media (OC-48c for instance) is coming, we simply say that commercial routers ought to be able to achieve those speeds with IPng. > This comment suggests that the new address structure should enable the > quickest possible route look-up. The quickest possible route look-up > means that a network number should conveniently correspond to a > natural register size on common communications computers and that > accesses to slower processor external memory should be minimized. > Such needs and 16 byte addresses are hard to reconcile with current > router technology. Um, no, I'm afraid I don't agree with this analysis. I think a better answer is to say that the header size should be a small number of cache lines in size (the unit of access is no longer a register size). With 128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two cache lines. Furthermore, most RISC systems have so many registers that putting the entire header into registers isn't hard -- and the address lookup in 90% of the cases is just a hash followed by a couple of compares. > >over the Internet. It is not unreasonable, therefore, to > >expect that the ratio of "local" traffic (i.e. the > >traffic that stays on one's local network) to "export" > >traffic (i.e. traffic destined to or sourced from a > >network other than one's own local network) will change, > >and the percent of export traffic will increase. > > This observation is not obviously true. No, but one has to guess. Our conclusion was that if one assumed most traffic was local, the requirements on the next generation IP were less stringent. (In particular, there's less router traffic). So we chose the more stringent approach. > >We also observe that many researchers believe that a > >proper IPng router should be capable of routing IPng > >traffic over links at speeds that are capable of fully > >utilizing an ATM switch on the link. > > ATM is yet another fad technology whose fad may be approaching its > end. I have recently read that several companies which had started > ATM development efforts had abandoned these efforts as pointless. A > better targer might be wire-speed routing in the context of a LAN > switch using fast Ethernet or CDDI. Fast Ethernet and CDDI are too slow. We wanted to talk about 10 Gb/s speeds and beyond. So far, ATM is the only protocol spec'd for those speeds. > BTW, after groveling through numerous packet switching implementations > and network drivers, almost invariably I have found that bottlenecks > and low performance have been due not to protocol design but poor > software implementations or (often even more importantly) due to the > host OS architecture. The protocol design has generally been an > extremely minor component of network/packet-switching performance. Yep. But there are folks working on making very very fast implementations and they are getting burned by protocol design issues. Regarding designing for the future. I think you may be right that we're ahistorical (shocking! -- I'm a former medievalist), but I still think that designing for the high end of today's technology is the right approach. The future is only 18 months away (next rev of CPUs). > >Some predictions have been made that, as the Internet > >grows and as more and more technically less-sophisticated > >sites get connected, there will be more failures in the > >network. These failures may be a combination of simple > >size; if the size of the network goes up by a factor of n > >then the total number of failures in the network can be > >expected to increase by some function of n. Also, as the > >network's users become less sophisticated, it can be > >assumed that they will make more, innocent and well > >meaning, mistakes, either in configuration or use of > >their systems. > > This comment is just the typical obnoxious snobbishness of > communications software engineers. If anything, the level of > sophistication will probably increase with an increase in the number > of sites which connect to the internet. Nowadays, someone who knows a > little is a guru and technical wizard who feels obligated to produce > reams of IETF draft documents. When lots of people have set up and > run multiprotocol internetworks, a little knowledge will hardly > impress anybody. Actually, we're not trying to be snobbish. There has been a general shortage of expertise in networking. And we have to expect our sites to be less knowledgable in the future. So either the network breaks, or we make our system more robust. > >5.5. Transition > > >The transition plan should address the issue of cost > >distribution. That is, it should identify what tasks are > >required of the service providers, of the end users, of > >the backbones and so on. > > This comment is rather scary. The IETF collectively has no obvious > expertise in public finance, accounting or political economics. > > The one area where the IETF has tried to distribute costs is network > management, and in this case the IETF has managed to make small > installations subsidize the development of SNMP on behalf of a few > large network providers even though the small installations have no > real need of such a thing. I dunno. We've got a lot of folks who've led successful startups etc. Or putting this another way, if the idea is that folks who are in the IETF cannot at least try to address issues of finance, accounting or economics, why should we believe they are qualified to run businesses? At some level, one just has to look at some of these problems -- so we will. > >5.8. Configuration, Administration, and Operation > > >Also, a strength of IPv4 has been its ability to be used > >on isolated subnets. IPng hosts must be able to work on > >networks without routers present. > > Who designs a networking suite which requires routers on a single > communications subet? OSI used to and may still. > >5.12. Multicast > >Unfortunately, IPv4 currently uses the local media > >broadcast address to multicast to all IP hosts. This > >behavior is anti-social in mixed-protocol networks and > >should be fixed in IPng. There's no good reason for IPng > >to send to all hosts on a subnet when it only wishes to > >send to all IPng hosts. The protocol must make > >allowances for media that do not support true > >multicasting. > > The above comment is idiotic. Exactly how a network layer multicast > is resolved to a MAC layer address for some arbitrary medium is not > obviously part of the network layer design. Sure it is. > >5.18. Things We Chose Not to Require > > I am not sure how MTU discovery overcomes the need for fragmentation > unless MTU discovery is performed before each packet is sent and > strict source routing is employed. Read the MTU discovery spec. You don't need strict source routing or discovery before each packet. > >IP Header Checksum > >There has been discussion indicating that the IP Checksum > >does not provide enough error protection to warrant its > >performance impact. The argument states that there is > >almost always a stronger datalink level CRC, and that > >end-to-end protection is provided by the TCP checksum. > >Therefore we believe that an IPng checksum is not > >required per-se. > > The IP header checksum is not intended to provide end-to-end data > integrity but rather provides local address integrity. Few routers > provide EDAC. Stuck bits in the wrong place after receive datalink > CRC is calculated could easily cause some poor neighboring router to > be inundated with misdirected packets whose lack of data integrity > might not be detected until much later or even never (if the new > address corresponds to no actual address). This problem could be > particularly serious in the cases of applications which rarely or > infrequently require acknowledgement of transmitted data packets. Read the paragraph again. It says that local address integrity is sufficiently protected by the link CRC and that end-to-end integrity of the IP datagram is ensured by the end-to-end TCP checksums. Simple engineering. Craig From owner-Big-Internet@munnari.OZ.AU Fri Aug 5 07:41:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17182; Fri, 5 Aug 1994 04:55:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA10750; Fri, 5 Aug 1994 04:55:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA10740; Fri, 5 Aug 1994 04:40:49 +1000 Precedence: list Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15497; Fri, 5 Aug 1994 03:56:59 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA23623 for big-internet@munnari.oz.au; Thu, 4 Aug 94 13:56:47 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA03894; Thu, 4 Aug 1994 10:56:14 -0700 Message-Id: <199408041756.KAA03894@aland.bbn.com> To: Dave Katz Cc: martillo@pluto.dss.com, big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US Subject: Re: IPng recommendation In-Reply-To: Your message of Thu, 04 Aug 94 10:51:13 -0700. <199408041751.KAA04358@feta.cisco.com> From: Craig Partridge Date: Thu, 04 Aug 94 10:56:12 -0700 Sender: craig@aland.bbn.com Dave: You mean I've been burned by bad info again? My understanding was that if one wanted to do certain types of dynamic address assignment under OSI one had to have a router present because dynamic assignment required ES-IS and ES-IS required a router to be present. Is this incorrect? Craig From owner-Big-Internet@munnari.OZ.AU Fri Aug 5 07:42:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17213; Fri, 5 Aug 1994 04:56:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA10776; Fri, 5 Aug 1994 04:56:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA10743; Fri, 5 Aug 1994 04:42:00 +1000 Precedence: list Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15895; Fri, 5 Aug 1994 04:13:00 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA05791; Thu, 4 Aug 1994 11:12:43 -0700 Date: Thu, 4 Aug 1994 11:12:43 -0700 From: Dave Katz Message-Id: <199408041812.LAA05791@feta.cisco.com> To: craig@aland.bbn.com Cc: martillo@pluto.dss.com, big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US In-Reply-To: Craig Partridge's message of Thu, 04 Aug 94 10:56:12 -0700 <199408041756.KAA03894@aland.bbn.com> Subject: IPng recommendation Sorry, I thought you were caught by the "can't forward to another box on the wire without a router" red herring. Address autoconfiguration has been defined at the ISO level only as a server-based process. However, there is nothing to explicitly bar other approaches. At least one ES vendor has implemented a scheme that falls back to being completely serverless on isolated LANs (trivial, since there's a "local scope" address format defined). This obviously can be done without being in violation of any spec (since from the outside you can't tell that it wasn't just statically defined). There is also an internet draft (draft-ietf-tuba-addr-assign-00.txt) that attempts to formalize the spectrum of possibilities into a single mechanism. So, yes, I think you've been burned by bad info again, in that there is no requirement per se to have a router present. From: Craig Partridge Date: Thu, 04 Aug 94 10:56:12 -0700 Sender: craig@aland.bbn.com Dave: You mean I've been burned by bad info again? My understanding was that if one wanted to do certain types of dynamic address assignment under OSI one had to have a router present because dynamic assignment required ES-IS and ES-IS required a router to be present. Is this incorrect? Craig From owner-Big-Internet@munnari.OZ.AU Sat Aug 6 02:56:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01509; Sat, 6 Aug 1994 02:56:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12054; Sat, 6 Aug 1994 02:55:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12027; Sat, 6 Aug 1994 02:37:40 +1000 Precedence: list Received: from uu10.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00779; Sat, 6 Aug 1994 02:37:34 +1000 (from fibermux!ccrelay.fibermux.com!cmaciocco@uu10.psi.com) Received: from fibermux.UUCP by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA17726 for ; Fri, 5 Aug 94 12:36:28 -0400 Received: from ccrelay.fibermux.com by fibermux.com (4.1/SMI-4.1) id AA03560; Fri, 5 Aug 94 08:55:55 PDT Received: from ccMail by ccrelay.fibermux.com id AA776102236 Fri, 05 Aug 94 08:57:16 PST Date: Fri, 05 Aug 94 08:57:16 PST From: cmaciocco@ccrelay.fibermux.com Encoding: 602 Text Message-Id: <9407057761.AA776102236@ccrelay.fibermux.com> To: big-internet@munnari.OZ.AU Subject: IP addressing Hi, I have a practical question, and this might not be the most appropriate list, but I hope you can point me in the right direction. I have a registered class C address and need to put more hosts than the address space provides me. Is there any way to do this without having to get another class C address and a router between them ? Is there a specific list which talks about this kind of problems ? Please reply directly, as I'm not on Big-I. Christian Maciocco cmaciocco@fibermux.com (818) 725-2884 From owner-Big-Internet@munnari.OZ.AU Sat Aug 6 04:16:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03996; Sat, 6 Aug 1994 04:16:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12155; Sat, 6 Aug 1994 04:15:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12121; Sat, 6 Aug 1994 03:56:25 +1000 Precedence: list Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03309; Sat, 6 Aug 1994 03:56:22 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA21632; Fri, 5 Aug 94 10:53:37 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA09077; Fri, 5 Aug 1994 13:56:02 -0400 Message-Id: <9408051756.AA09077@skidrow.lkg.dec.com> To: cmaciocco@ccrelay.fibermux.com Cc: big-internet@munnari.OZ.AU Subject: Re: IP addressing In-Reply-To: Your message of "Fri, 05 Aug 94 08:57:16 PST." <9407057761.AA776102236@ccrelay.fibermux.com> Date: Fri, 05 Aug 94 13:56:02 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp How about tcp-ip@nic.ddn.mil. Donald From: cmaciocco@ccrelay.fibermux.com Precedence: list Encoding: 602 Text To: big-internet@munnari.oz.au > > Hi, > I have a practical question, and this might not be the most > appropriate list, but I hope you can point me in the right direction. > > I have a registered class C address and need to put more hosts than > the address space provides me. Is there any way to do this without > having to get another class C address and a router between them ? > > Is there a specific list which talks about this kind of problems ? > > Please reply directly, as I'm not on Big-I. > > Christian Maciocco > cmaciocco@fibermux.com > (818) 725-2884 From owner-Big-Internet@munnari.OZ.AU Fri Aug 12 04:24:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25043; Fri, 12 Aug 1994 04:20:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA19679; Fri, 12 Aug 1994 04:17:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA19658; Fri, 12 Aug 1994 04:07:15 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24512; Fri, 12 Aug 1994 04:07:11 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU Subject: Draft minutes - Toronto EID BOF Reply-To: kre@munnari.OZ.AU Date: Fri, 12 Aug 1994 04:07:09 +1000 Message-Id: <842.776628429@munnari.OZ.AU> From: Robert Elz Draft minutes for the EID BOF at the Toronto IETF follow. If anyone has any ammendments/corrections/... please send them (to me, not the list) asap - I'm supposed to submit them within about 24 hours or so. nb: the purpose of this request is to get the record of the BOF accurate, not to debate, consider, or whatever the points below. That is, if you believe that the minutes do not accurately represent what happened at the meeting, then please tell me - if you believe that what is here is wrong, stupid, not half right, etc, then please tell the list, or someone else - though you may want to wait until the minutes are finalised. - - - - End Point Identifier (eid) BOF Minutes - Toronto, July 25, 1994 A BOF was held at the Toronto (30th) IETF to consider the concept of Endpoint Identifiers. The meeting was nominally chaired by Robert Elz. Frank Solensky took notes for these minutes, for which I thank him, also Dave Clark for supplying his notes of the meeting. Before the BOF a proposed agenda was sent to the Big-Internet list, this also formed the starting point of the meeting. The agenda was: 0. Administrative tedium (5 minutes) 1. EIDs - definition (20) 2. Terminology - what name should these things have (10) 3. Uses - certain, likely, and possible (20) 4. Structure, (15) - including or excluding manufacturer provided tags (eg: MAC addresses) - structure for directory lookups 5. Allocation (incl autoconfiguration) (10) 6. Is a WG required (5) 7. Draft Charter if so (15) 8. Are EIDs useful? Do we need them? (20) (If time hasn't run over on other issues) This agenda fell by the wayside quite quickly after the administrivia was dealt with. The meeting opened with Noel Chiappa, as the inventor of the concept, giving his definition of an EID, which amounted to the name of an endpoint - being something that can form one end of a connection, which might be a host, but need not be. The term "fate sharing region" applies. Discussion on exactly what this meant followed, without making any significant progress. It was suggested that a better approach might be to construct a list of the uses to which the attendees believed that EIDs might be put, with the aim that from this list the essence of what is required might be distilled. The list constructed contained: 1. Realign existing end to end context and transport connections 2. Maintain connections during failover or instability 3. Identify a "security context", even when no connection present 4. "Index" into database 5. Transition abstraction 6. Provider-independant identifier of host interface 7. Re-acquire path (underlying connection) after service disruption 8. Use, eg within a MIB, for referring to an end-point 9. Labelling a connection (independant of movement) 10. Cluster aliasing 11. Better software fastpath 12. Avoid semantic overload 13. Accounting 14. Transport (and above) completely independant of net layer 15. Selectors shorter (and still globally unique) It should be pointed out that this list does not represent the opinions of any particular individual, nor of the meeting itself, but was merely compiled from suggestions from the floor. Discussion of these points, as they were added, continued for some time. Many points in the list were felt to be merely special cases of other points, others were felt to simply be inappropriate. As this discussion was also getting nowhere particularly useful, a third approach was tried. This comprised building a list of the distinguishing attributes that may apply to EIDs, and asking particular people to indicate which of the attributes applied to their model of EIDs. The attributes were 1. Are EIDs short (generally perceived as no longer than about 64 bits) ? 2. Are EIDs binary (as opposed to printable text) ? 3. Are EIDs globally unique ? 4. Do EIDs exist at the network level ? 5. Do EIDs exist in the transport layer ? 6. Are EIDs used to identify transport connections ? 7. Are EIDs used as a key into any kind of database ? 8. Do EIDs have any internal (administrative) structure ? It was assumed that EIDs have no topological or geographical meaning. 9. Are EIDs present in every packet ? Without attribution, the models suggested were ... model 1 2 3 4 5 6 7 8 9 A ? ? Y Y? N Y N N? ? B ? Y Y Y? N Y Y Y ? C N N Y N ? Y Y Y N D Y Y Y N Y Y Y Y Y? E Y Y Y Y Y Y Y Y Y F Y Y Y Y N Y Y Y? Y G Y Y N Y N Y N N ? H1 Y Y Y N Y ? Y Y N H2 N Y Y N Y ? N N N J Y Y Y? N Y Y Y Y Y K Y Y Y Y N Y Y Y Y For comparison, treating IPv4 addresses as EIDs, and noting that they have topological significance, the modem for IPv4 was constructed as .. IPv4 Y Y Y Y N Y Y Y Y In the above, "Y" indicates a "yes" answer to the corresponding question, "N" indicates "no", "?" one of "don't know" or "uncertain", or "either way would work", or "sometimes", or similar. "Y?" indicates "probably yes", or "something like that", "N?" probably no. Respondent H believed that two different forms of EIDs were required, with different attributes, the two sets listed as H1 and H2. This list was constructed comparatively quickly, as no discussion of the models was entertained. Instead their proponents, or some of them, will write a short submission supporting their view of what an EID should be like, and why, and submit it to the Big-Internet mailing list for public review. Some of those may become Internet Drafts. It was decided that a new mailing list was not warranted immediately, and that Big-Internet@munnari.OZ.AU will continue to be used, however a specific list may be established at some later time. The submissions on this topic to the list will be considered, and from those, if it seems necessary and useful, a charter for a working group will be created and submitted. It was noted however that IPv6 (or IP6, or IPng as desired) is currently planned to be to proposed standard stage by the time of the next IETF, if EIDs are to play any part in IPv6 the work needs to be done well before then. My thanks to Frank Solensky and Dave Clark for the notes, and to Dave Crocker and John Curran for assisting the BOF get the results it was able to get. Requests to join the Big-Internet list should be sent to Big-Internet-Request@munnari.OZ.AU, attendees at the BOF have not been added to any list due only to having attended. Robert Elz From owner-Big-Internet@munnari.OZ.AU Mon Aug 15 14:56:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16238; Mon, 15 Aug 1994 12:42:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA23750; Mon, 15 Aug 1994 12:38:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23745; Mon, 15 Aug 1994 12:29:38 +1000 Precedence: list Received: from sequoia.itd.uts.EDU.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15909; Mon, 15 Aug 1994 12:29:33 +1000 (from akumria@banksia.itd.uts.edu.au) Received: from banksia. banksia.itd.uts.edu.au by sequoia.itd.uts.EDU.AU with SMTP id AA00918 (5.65c/IDA-1.4.4 for ); Mon, 15 Aug 1994 12:29:28 +1000 Received: by banksia. banksia.itd.uts.edu.au (4.1/SMI-4.1[gji]) id AA07902; Mon, 15 Aug 94 12:31:35 EST Date: Mon, 15 Aug 1994 12:31:33 +1000 (EST) From: Anand Kumria Subject: subscribe ipng To: big-internet@munnari.OZ.AU Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe ipng -----------------------+-------------------------------------------------------- /\ | akumria@socs.uts.edu.au / \ | akumria@banksia.itd.uts.edu.au *preferred* / \ | / \ | "I don't mind UNIX at all really. I like the cryptic / Kumria \ | nature of it all - i.e. it gives me something to ---/----------\--- | do on the toilet, apart from the obvious (not the / \ | devious!) .. UNIX manuals can be quite stimulating!" / \ | -- Bradley Kelly From owner-Big-Internet@munnari.OZ.AU Tue Aug 16 11:35:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23310; Tue, 16 Aug 1994 08:19:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA24792; Tue, 16 Aug 1994 08:18:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA24776; Tue, 16 Aug 1994 08:05:50 +1000 Precedence: list Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19800; Tue, 16 Aug 1994 06:17:54 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06782 for big-internet@munnari.oz.au; Mon, 15 Aug 94 16:17:39 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id NAA02462; Mon, 15 Aug 1994 13:16:56 -0700 Message-Id: <199408152016.NAA02462@aland.bbn.com> To: Joachim Martillo Cc: kasten@ftp.com, big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us Subject: Re: IPng recommendation In-Reply-To: Your message of Mon, 15 Aug 94 15:45:00 -0400. <9408151945.AA02548@pluto.dss.com> From: Craig Partridge Date: Mon, 15 Aug 94 13:16:55 -0700 Sender: craig@aland.bbn.com Joachim: OK -- I'll do one last round here. Then IPng requirements should have required that this difficulty be addressed. We could have also specified that it would be nice to have hardware that delivered 1 Gbps bandwidth and cost $100 per adapter. Cray, SGI, and some other vendors could clearly use this capability now and it would make the Mosaic load on the network lower. But specifying it doesn't make it happen. One specs what appears feasible. >> This comment suggests that the new address structure should enable th e >> quickest possible route look-up. The quickest possible route look-up >> means that a network number should conveniently correspond to a >> natural register size on common communications computers and that >> accesses to slower processor external memory should be minimized. >> Such needs and 16 byte addresses are hard to reconcile with current >> router technology. >Um, no, I'm afraid I don't agree with this analysis. I think a better >answer is to say that the header size should be a small number of cache >lines in size (the unit of access is no longer a register size). With >128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two >cache lines. Furthermore, most RISC systems have so many registers that >putting the entire header into registers isn't hard -- and the address >lookup in 90% of the cases is just a hash followed by a couple of compares . Caches can help with the route table, and a lot of registers can help with address comparisons. But caches do not help in groveling through the header of a received packet, and header information must still be exchanged between registers and slow processor external memory. The longer the header is, the more time will be expended in this transfer for a given hardware implementation. You're changing the argument here. The original statement said there was a need to optimize route lookup and I said that the statement was ill-formed and now you're making a pure header sizes mean slow argument (and saying well routing doesn't matter after all). >Yep. But there are folks working on making very very fast implementations >and they are getting burned by protocol design issues. I would have to analyze the implementations. An argument that a protocol must be designed in a specific way because some researcher in some unique environment had some sort of problem is not is not an argument but simply an unjustified assertion. Go look at Van Jacobson's fast IP forwarding code (sent to the end2end-interest list about 3 years ago as I recall). You need to learn more about hardware. It is simply cheaper to design packet switch memories and hardware I/O FIFOs without error detection or without error detection and correction. OK -- summarizing your argument, after the link CRC is computing there's a chance the router will trash the 20 byte IP header while moving it over data lines from the interface to the forwarding engine and that this risk is so great we need a checksum in each packet. Right? Sounds silly to me. I know of boxes that infrequently trash packets, but they usually sufficiently trash them (and do so randomly enough) that the checksum isn't worthwhile. Craig From owner-Big-Internet@munnari.OZ.AU Tue Aug 16 12:35:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23703; Tue, 16 Aug 1994 08:38:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA24824; Tue, 16 Aug 1994 08:38:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA24800; Tue, 16 Aug 1994 08:19:35 +1000 Precedence: list Received: from pluto.dss.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18926; Tue, 16 Aug 1994 05:49:23 +1000 (from martillo@pluto.dss.com) Received: by pluto.dss.com (4.1/SMI-4.0) id AA02548; Mon, 15 Aug 94 15:45:02 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9408151945.AA02548@pluto.dss.com> Subject: Re: IPng recommendation To: kasten@ftp.com Date: Mon, 15 Aug 1994 15:45:00 -0400 (EDT) Cc: martillo@pluto.dss.com, big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US In-Reply-To: <9408031415.AA02333@mailserv-D.ftp.com> from "Frank Kastenholz" at Aug 3, 94 10:15:56 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 32502 >Date: Wed, 3 Aug 94 10:15:56 EDT >Subject: Re: IPng recommendation >From: kasten@ftp.com (Frank Kastenholz) >Cc: big-internet@munnari.oz.au, ietf@CNRI.Reston.VA.US >Joachim, >First of all, comments would have been preferred during the debate. >Certainly before the IPng choice. Comments now are roughly akin to >locking the barn door after the horse has run off, though since there >is still IPNG development work to be done, I am sure that the IPng >developers will carefully consider your points. For some reason, people who regularly take part in developing IETF standards have a major misconception about standards development in the context of manufacturing regimes. I recently made this point as follows on the SNMP mailing list. International regimes, national regimes and manufacturing regimes produce standards. The ISO is an international regime. The Deutsche Bundespost is a national regime. IBM with respect to SNA or Microsoft with respect to Windows are examples of manufacturing regimes. Another example of a manufacturing regime is the voluntary regime among screw manufacturers governing helicity, pitch and groove width of screws. The IETF is a manufacturing regime like the screw regime. The goal of the IETF should be to produce a set of standards so that purchasers of TCP/IP based products can feel assured that TCP/IP devices can effectively operate and interoperate in the environment of a multiprotocol internet. The raison d'etre of such a manufacturing regime is products not standards. Developers of IETF standards must understand that product developers and product customers pass ultimate judgment on IETF standards. The real criticism begins once the IETF produces an official RFC (which in fact does stand fo Request for Comments). Ultimately the market will judge some IETF standards stupid just as the market and Ken Olson ultimately judged token bus stupid. If IETF contributors are going to freak every time people outside the standards process have problems with an IETF standard, ultimately the IETF may prove to have no value. >Second, one of the 'principles' which Craig and I started using in >refining the criteria was what has been called 'In your face' >requirements. If the criteria were set at a relatively 'safe' or >'low' level, then that is all we might get. You mention, for example, >10**15 end nodes. If we had set, for example, 10**10 end nodes, then >that is possibly all we would get. By setting a higher level, we may >still get only 10**10, but we might also get more. Furthermore, by >saying 10**15, the developers (and the rest of the community) may >think more about what a truly ubiquious global internetwork might >need and what it could do. The use of a so-called "in your face argument" implies an inability to present a rational argument in favor of some position to a reasonable target audience persuasively. Certainly, using an "in your face argument" is unprofessional and suggests some major deficiencies in either the presenter or the position presented. In this case, the real problem seems to be the end-address allocation. Rather than making a requirement of order(250,000) addresses per human a better requirement might have been that IPng provide a reasonable end-address allocation scheme. > > After noticing some of the discussion of IPng criteria, I ftp'd over > > the criteria. Exactly how to interpret this document is unclear. >This document, in its final form, was considered as a framework (not >the only one) about which discussions of the various IPNG candidates >could be held by the IPng directorate. You might, in effect, consider >the section headings to be an 'agenda' of items to be evaluated in >the various proposals. Perhaps, if Kastenholz would learn how to write a serious technical document, treating this document as an agenda would have been possible. Unfortunately, as one can see from the table of contents following, not only do the section headers contribute to a major lack of seriousness and professionalism, but there is also little clue in the section headers of the document in question to hint at the nature of the document. Table of Contents Status of this Memo .................................... 1 1 Introduction .......................................... 2 2 Goals ................................................. 3 3 Note on Terminology ................................... 5 4 General Principles .................................... 6 4.1 Architectural Simplicity ............................ 6 4.2 One Protocol to Bind Them All ....................... 6 4.3 Live Long ........................................... 6 4.4 Live Long AND Prosper ............................... 7 4.5 Co-operative Anarchy ................................ 7 5 Criteria .............................................. 9 5.1 Scale ............................................... 9 5.2 Topological Flexibility ............................. 11 5.3 Performance ......................................... 12 5.4 Robust Service ...................................... 14 5.5 Transition .......................................... 15 5.6 Media Independence .................................. 17 5.7 Unreliable Datagram Service ......................... 19 5.8 Configuration, Administration, and Operation ........ 20 5.9 Secure Operation .................................... 22 5.10 Unique Naming ...................................... 24 5.11 Access ............................................. 25 5.12 Multicast .......................................... 26 5.13 Extensibility ...................................... 27 5.14 Network Service .................................... 29 5.15 Support for Mobility ............................... 30 5.16 Control Protocol ................................... 31 5.17 Private Networks ................................... 32 5.18 Things We Chose Not to Require ..................... 33 6 Routing ............................................... 35 6.1 Scale ............................................... 35 6.2 Policy .............................................. 35 6.3 QOS ................................................. 36 6.4 Feedback ............................................ 36 6.5 Stability ........................................... 36 6.6 Multicast ........................................... 36 7 Security Considerations ............................... 38 8 Acknowledgments ....................................... 39 9 References ............................................ 40 10 Change Log ........................................... 42 10.1 25 May 1994 ........................................ 42 10.2 10 May 1994 ........................................ 42 10.3 25 April 1994 ...................................... 42 10.4 23 March 1994 ...................................... 43 10.5 21 March 1994 ...................................... 43 10.6 10 March 1994 ...................................... 45 10.7 9 March 1994 ....................................... 45 10.8 15 February 1994 ................................... 46 10.9 9 November 1993 .................................... 47 10.10 9 September 1993 .................................. 48 10.11 14 December 1992 .................................. 48 By way of contrast, the following are section headers from a document I wrote to propose a reasonable architecture for hybrid bridge routers (available via anonymous ftp from pluto.dss.com in the Constellation directory). It may not be a great document, but the section headers do hint that the subject of the document is the architecture of hybrid bridge routers. I. Introduction 1 II. IP Routers 5 III. P802.1d MAC Bridges 11 IV. Contrasting Bridges and Routers 21 V. Disjoint Functionality Hybrid Bridge Routers 31 VI. Parallel Router Filtering Bridge Architecture for Hybrid Bridge Routers 31 VII. Logical Subbridge Architecture for Hybrid Bridge Routers 35 VIII. Conclusion 39 Terminology 41 > > >5.3. Performance > > >Furthermore, at a minimum, a > > >host must be able to achieve data transfer rates with > > >IPng comparable to the rates achieved with IPv4, using > > >similar levels of host resources. > > Since poor router performance can affect a whole internet rather than > > simply an individual host, the criterion should have concentrated > > attention on router performance. >It originally did. However, it was also pointed out that if IPng made >host performance 'very bad' then, even if the routers were blindingly >fast, IPng would be a loser. Furthermore, IPng really should not be >perceived as a step backwards wrt IPv4. If IPng made hosts >significantly slower then it would be just such a step. >Now, this might all seem trivial, obvious, irrelevant, and >motherhood. But, on the other hand, host performance was a major >factor in the discussion about addressing on the big-i list. If host >performance wasn't critical then that discussion may well have had a >different outcome. I remember having this argument at Prime (where people used to argue that it was reasonable to get undefined or erroneous results when, because or even though the arguments to a function and its formal parameter definitions were consistent and within range). In IP-type internetworking, N-interface hosts and N-interface routers are distinguishable in that N-interface end hosts do not forward packets. (The single interface host is of course a degenerate case of an N-interface host.) One would think it would be really hard to design an IP-like internetworking system wherein routers were blindingly fast while end hosts performed very badly even though hosts differed from routers only by not doing something that routers did. > > >We limit this requirement to commercially available > > >routers and media. If some network site can obtain a > > >particular media technology "off the shelf", then it > > >should also be able to obtain the needed routing > > >technology "off the shelf." One can always go into some > > >laboratory or research center and find newer, faster, > > >technologies for network media and for routing. We do > > >believe, however, that IPng should be routable at a speed > > >sufficient to fully utilize the fastest available media, > > >though that might require specially built, custom, > > >devices. > > This comment suggests that the new address structure should enable the > > quickest possible route look-up. The quickest possible route look-up > > means that a network number should conveniently correspond to a > > natural register size on common communications computers and that > > accesses to slower processor external memory should be minimized. > > Such needs and 16 byte addresses are hard to reconcile with current > > router technology. >First, we attempted to stay as far away from dictating implementation >as we could. This assertion is an IETF situational justification. Suddenly, there is an IETF principle which rejects dictating implementation. Then how is the OSPF protocol "specification" justified? That novel of a document cannot be considered in any way, shape or form a reasonable protocol specification. It is nothing but one possible (but certainly not obviously the best) implementation specification, > Your comment implies that we should have said, for >example, that addresses must have a 4-byte (or whatever number) >network number field. This would be dangerously close to specifying >the implementation, and not pointing out the problems that were to be >solved. (By pointing out the problem, we in theory allowed for a wide >variety of solutions.) Claiming that somehow specifying a 4-byte network number field specifies the implementation is a complete non-sequitur. Such a specification of the network number field would say nothing about how the network number was structured. In fact, such a network number field could be split into an area and a non-area portion or some other hierarchical scheme. A similar specification of the host ID field would also say nothing about how the host ID field was structured. In fact, such a host ID field could be split into some sort of subnet field and subnet host ID field or some other structured scheme. >Second, some people are envisioning that a majority of traffic in the >future internet will be forwarded not based on topological >information carried around in the packet, but rather on a smaller, >more easily handled, 'flow-id' which would have the properties you >talk about. I note that SIPP has such a flowid. This comment sounds like an admission that SIPP addressing is completely broken with respect to performance and as a consequence another level of complexity and possible errors must be added to compensate for the damage which SIPP addressing does. Thus there may be no way to tell from the address how a given packet might be routed because the "flow id" will determine the routing. In any case, such a field makes the non-data header portion even larger (a major concern on low bandwidth channels), and provides even more bits in the header not protected against errors by checksum. > > >We also observe that many researchers believe that a > > >proper IPng router should be capable of routing IPng > > >traffic over links at speeds that are capable of fully > > >utilizing an ATM switch on the link. This requirement is uncorrellated. Maybe some sort of price-performance is being required. > > ATM is yet another fad technology whose fad may be approaching its > > end...A better targer might be wire-speed routing in the context of a LAN > > switch using fast Ethernet or CDDI. >The base criterion does not mention any specific technology. We felt >that we could not accurately predict what technology would be the >'right' technology in 5 or 10 years. There was no reason to care. The whole point of the internetwork layer is the creation of a virtual network which hides the details of specific technologies. > > >Some predictions have been made that, as the Internet > > >grows and as more and more technically less-sophisticated > > >sites get connected, there will be more failures in the > > >network. These failures may be a combination of simple > > >size; if the size of the network goes up by a factor of n > > >then the total number of failures in the network can be > > >expected to increase by some function of n. Also, as the > > >network's users become less sophisticated, it can be > > >assumed that they will make more, innocent and well > > >meaning, mistakes, either in configuration or use of > > >their systems. This failure estimate model is not reasonable. >Also, we are envisioning a future where the entities who connect to >the Internet will not be like they are today. They will be sites that >are non-technical (in the networking sense) and probably will not >have the system operations staff that current sites have. Imagine a >dentist's office connecting to the network. This is also the reason >why we are stressing a 'plug-and-play' configuration ability. The >less that has to be configured, the less chance of making such errors. Such sites will probably deal with their internetworking service needs the same way they deal with their telephone service needs. Just as they have a small PBX, they might have an internet interconnection device. When the PBX doesn't work, they call the supplier. If the internet interconnection device doesn't work, they would call the supplier. In any case, the section of the requirements document which dealt with "plug-and-play" was completely confused. My Appletalk and IPX hosts are plug-and-play, but they do not boot over the network. Network boot and plug-and-play are completely orthogonal. > > >5.12. Multicast > > The above comment is idiotic. Exactly how a network layer multicast > > is resolved to a MAC layer address for some arbitrary medium is not > > obviously part of the network layer design. >It says 'When mac-layer multicasting is available, use it in preference >to broadcasts.' This requirement is not relevant to the specification of IPng. How an IPng packet is to be transported across a given medium is part of a medium specific IPng encapsulation specification and not part of the IPng protocol specification. A sensible encapsulation specification would specify network layer multicasts be transported with whatever MAC addresses make the most sense. It is not to hard to envision a medium where mac-layer multicasting might be present but where mac-layer broadcast might make more sense as an encapsulation (e.g. a switched medium where multicasts were limited to some small number of hosts -- perhaps 16 -- while broadcasts would reach all hosts within the communcations subnet on a dedicated out of band channel). > > Furthermore, as Appletalk > > has abundantly shown a protocol that uses multicast exclusively can > > certainly be antisocial in the sense of burning up a lot of bandwidth. >This criterion does not say that one should use multicasts instead of >unicasts. There are certain types of applications (eg multi-person >conferencing, finding servers) where using unicasts is not the best >way to go. If the existance of these applications is a given, then we >have a choice of using MAC-level multicasts or broadcasts (where >mcasts are available). We believe that multicasts are preferred in >these situations. You misunderstood my comment. Appletalk uses multicasts exclusively in situations where IP would use broadcasts. > > >6. Routing > > >Routing is a very critical part of the Internet. In fact, the > > >Internet Engineering Task Force has a separate Area which is > > >chartered to deal only with routing issues. This Area is > > >separate from the more general Internet Area. > > >We see that routing is also a critical component of IPng. > > >There are several criteria, such as Scaling, Addressing, and > > >Network Services, which are intimately entwined with routing. > > Shouldn't routing performance be included among these critical > > components? >What exactly is routing performance? I have lead teams working on compilers, word processors, spreadsheets and switches. Every once in a while I would review an engineer's work and point out that a given approach would lead to unacceptably low performance. If the engineer then tried to suggest that there were conceptual problems with defining performance for the target application, I had a serious problem because the engineer was trying to rationalize away a complete lack of understanding with respect to the technology, performance issues or software engineering in general. Someone who had a modicum of understanding might have consulted one of the standard textbooks like Computer Architecture: A Quantitative Approach or Computer Organization & Design: The Hardware/Sortware Interface (both by Patterson & Hennessy) and tried to determine how some of the general principles outlined there might apply to the problem at hand. > There are at least three >separate functions that are commonly subsumed under the term >'routing' and the performance could apply to any of the three. In this case we might ask what activity is most critical to the vast majority of users of the network. Does he care about the distribution of routing information? In a well functioning network, the network converges to a stable topology and nothing should change very often. Does he care about the calculation of routes by routers which really should in a well functioning network come to the same result iteration after iteration? No, but after the speed with which packets are received or transmitted at the local interface, he would care about how quickly packets are switched in the routers from the incoming to the outgoing interfaces (unless he is exceptionally patient). The ratio of data to control information would probably concern him (especially on low bandwidth channels). > We >believe that we have performance of Forwarding packets well covered. There is no basis for this belief. With the size of addresses and cruft like the flow ID, IPng will be a disaster on low to moderate speed channels. In environments where successive packets transmitted between two end hosts are likely to follow different equal cost routes described by possibly very different values of parameters like MTU. MTU might continuously have to be rediscovered and many packet transmissions will fail because MTU on an intermediate network was exceeded. In such a network, best network performance might have been achieved with a packet size somewhat less than the MTU on most possible paths but which might lead to fragmentation on other paths (were fragmentation supported). Single frame acknowledged protocols (of which I believe Sun NFS is an example) may suffer major performance losses because of choices made with respect to IPng. On ethernet and other LAN networks, the performance of a single frame acknowledged protocol could be enhanced (with IPv4) by purposefully setting packet size larger than the medium specific MTU. In this way several full size IP packets can be transmitted before an acknowledgement is required. The IPng requirements for no legitimate reason discarded this useful capability which might in some cases provide significant performance enhancements. Such a decision is not only bad engineering, but is pure obnoxiousness and verges on a rape of customers who over the years have come to depend on the existence of a feature discarded by unjustified fiat. >The other functions, information distribution (i.e. the routing >protocols) and route calculation are harder to specify. Should we say >that the 'Routing Protocols should be efficient' and 'Route >calculation should be fast'? This seems too nebulous. >Frank Kastenholz >To: Joachim Martillo >Cc: big-internet@munnari.oz.au, ietf@cnri.reston.va.us >Subject: Re: IPng recommendation >From: Craig Partridge >Date: Thu, 04 Aug 94 10:17:06 -0700 >Hi: > Let me see if I can reply to some of your concerns about the IPng >criteria document. (I'll skip spots where you agreed with it and some spots >where I wasn't sure of what the key point was). > First off, the concern on 10**15 end-hosts. We're quite clear >about why we said that. We derived it straight from other work which we >felt wasn't quite demanding enough in terms of the number of devices in the >home. The fact that it comes out to 250,000 addresses per human only reflects >some of the Internet's difficulties with efficient address allocation. Then IPng requirements should have required that this difficulty be addressed. >> This comment suggests that the new address structure should enable the >> quickest possible route look-up. The quickest possible route look-up >> means that a network number should conveniently correspond to a >> natural register size on common communications computers and that >> accesses to slower processor external memory should be minimized. >> Such needs and 16 byte addresses are hard to reconcile with current >> router technology. >Um, no, I'm afraid I don't agree with this analysis. I think a better >answer is to say that the header size should be a small number of cache >lines in size (the unit of access is no longer a register size). With >128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two >cache lines. Furthermore, most RISC systems have so many registers that >putting the entire header into registers isn't hard -- and the address >lookup in 90% of the cases is just a hash followed by a couple of compares. Caches can help with the route table, and a lot of registers can help with address comparisons. But caches do not help in groveling through the header of a received packet, and header information must still be exchanged between registers and slow processor external memory. The longer the header is, the more time will be expended in this transfer for a given hardware implementation. At Prime the networking stars always wanted to argue that future hardware would compensate for the lousy performance of networking software, but in the IP internet context we have to worry about a massive performance loss on the massive installed base of hardware because of design decisions made in (somewhat misguided) anticipation of the performance capabilites of future hardware. >> BTW, after groveling through numerous packet switching implementations >> and network drivers, almost invariably I have found that bottlenecks >> and low performance have been due not to protocol design but poor >> software implementations or (often even more importantly) due to the >> host OS architecture. The protocol design has generally been an >> extremely minor component of network/packet-switching performance. >Yep. But there are folks working on making very very fast implementations >and they are getting burned by protocol design issues. I would have to analyze the implementations. An argument that a protocol must be designed in a specific way because some researcher in some unique environment had some sort of problem is not is not an argument but simply an unjustified assertion. Tony Bono, Director of Bridge Router Development at Penril Datability Networks, came across such bogus justification with respect to task exchange time for the OS of a packet switch. Supposedly the task exchange had to meet some requirements which he did not have security clearance to read. Once he got clearance, he found that there was no such requirements and that the other engineer simply had been unable to justify his position rationally. >> >5.5. Transition >> >The transition plan should address the issue of cost >> >distribution. That is, it should identify what tasks are >> >required of the service providers, of the end users, of >> >the backbones and so on. >> This comment is rather scary. The IETF collectively has no obvious >> expertise in public finance, accounting or political economics. >> >> The one area where the IETF has tried to distribute costs is network >> management, and in this case the IETF has managed to make small >> installations subsidize the development of SNMP on behalf of a few >> large network providers even though the small installations have no >> real need of such a thing. >I dunno. We've got a lot of folks who've led successful startups etc. >Or putting this another way, if the idea is that folks who are in the IETF >cannot at least try to address issues of finance, accounting or economics, >why should we believe they are qualified to run businesses? Scoring in the high tech industry often has little to do with business qualifications. In any case, costing is a bean-counter issue. Rarely do bean-counters become successful entrepreneurs, and few successful entrepreneurs have started out as bean-counters. In any case, hi-tech engineers seem particularly bad at costing, and are probably the last ones who should be addressing such an issue. >At some level, one just has to look at some of these problems -- so we will. But mention of these problems is really irrelevant to the IPng requirements specification. >> >IP Header Checksum >> >There has been discussion indicating that the IP Checksum >> >does not provide enough error protection to warrant its >> >performance impact. The argument states that there is >> >almost always a stronger datalink level CRC, and that >> >end-to-end protection is provided by the TCP checksum. >> >Therefore we believe that an IPng checksum is not >> >required per-se. >> The IP header checksum is not intended to provide end-to-end data >> integrity but rather provides local address integrity. Few routers >> provide EDAC. Stuck bits in the wrong place after receive datalink >> CRC is calculated could easily cause some poor neighboring router to >> be inundated with misdirected packets whose lack of data integrity >> might not be detected until much later or even never (if the new >> address corresponds to no actual address). This problem could be >> particularly serious in the cases of applications which rarely or >> infrequently require acknowledgement of transmitted data packets. >Read the paragraph again. It says that local address integrity is sufficiently >protected by the link CRC and that end-to-end integrity of the IP datagram >is ensured by the end-to-end TCP checksums. Simple engineering. You need to learn more about hardware. It is simply cheaper to design packet switch memories and hardware I/O FIFOs without error detection or without error detection and correction. I have grovelled through the hardware designs of 5 different internetwork packet switches. None would guarantee local address integrity as you seem to expect. If anyone reading this note knows of a packet switch with the sort of error detection circuitry which Partridge seems to assume, I would be interested to learn about it. >Craig >From: Dave Katz >Subject: IPng recommendation >Sorry, I thought you were caught by the "can't forward to another box >on the wire without a router" red herring. >Address autoconfiguration has been defined at the ISO level only as a >server-based process. However, there is nothing to explicitly bar >other approaches. At least one ES vendor has implemented a scheme that >falls back to being completely serverless on isolated LANs (trivial, >since there's a "local scope" address format defined). This obviously >can be done without being in violation of any spec (since from the outside >you can't tell that it wasn't just statically defined). This scheme makes a lot of sense if once the isolated LAN is connected to an internet, the local scope addresses are supplanted by global scope addresses. >There is also an internet draft (draft-ietf-tuba-addr-assign-00.txt) that >attempts to formalize the spectrum of possibilities into a single mechanism. >So, yes, I think you've been burned by bad info again, in that there >is no requirement per se to have a router present. > From: Craig Partridge > Date: Thu, 04 Aug 94 10:56:12 -0700 > Sender: craig@aland.bbn.com > Dave: > You mean I've been burned by bad info again? > My understanding was that if one wanted to do certain types of dynamic > address assignment under OSI one had to have a router present because dynamic > assignment required ES-IS and ES-IS required a router to be present. Is this > incorrect? > Craig An important part of developing requirements for IPng should have been learning how other protocol suites dealt with relevant issues. Analysis and comparison could have provided insights and helped avoid pitfalls. IPX and Appletalk are in many ways superior to classic IP. DECNET has been transitioned several times to newer versions that offered more capabilities. SNA has generally provided particularly high performance communications between end hosts. IPng would look a lot less problematic if the WG had approached the task of developing requirements for IPng far more systematically. IPng would look far less parochial and far less prone to recapitulate errors already made and fixed in other contexts, had the WG made more extensive use of internetworking knowledge developed outside the arena of TCP/IP. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com From owner-Big-Internet@munnari.OZ.AU Tue Aug 16 19:29:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15066; Tue, 16 Aug 1994 17:59:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA25306; Tue, 16 Aug 1994 17:58:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA25288; Tue, 16 Aug 1994 17:43:41 +1000 Precedence: list Received: from [36.53.0.155] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11732; Tue, 16 Aug 1994 16:33:37 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA00620; Mon, 15 Aug 1994 14:18:09 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Aug 1994 14:18:13 -0700 To: Joachim Martillo From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPng recommendation Cc: kasten@ftp.com, martillo@pluto.dss.com, big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US Joachim, As always, your contributions assisting the IETF to understand its continued pattern of failure, as well as your subtle touch with personal exchanges, is I am sure appreciated by the breadth and depth of the Internet community. We shall, of course, endeavor to learn from the errors you so consistently point out. Can't imagine how we've managed to fail so completely, all these years. d/ P.S. No need to thank me. I'm sure I can intuit your own appreciation of my response. ----- Dave Crocker 675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205 Sunnyvale, CA 94086 (USA) From owner-Big-Internet@munnari.OZ.AU Thu Aug 18 16:40:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27240; Thu, 18 Aug 1994 16:40:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27793; Thu, 18 Aug 1994 16:39:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27779; Thu, 18 Aug 1994 16:20:19 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26840; Thu, 18 Aug 1994 16:19:54 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 18 Aug 94 15:12:15 +0900 From: Masataka Ohta Message-Id: <9408180612.AA17188@necom830.cc.titech.ac.jp> Subject: Re: Still going... To: jcjones@MIT.EDU Date: Thu, 18 Aug 94 15:12:12 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9408180031.AA13031@cacciatore.MIT.EDU>; from "jcjones@MIT.EDU" at Aug 17, 94 8:31 pm X-Mailer: ELM [version 2.3 PL11] > 1. Security: > > I'm using a hybrid system. Public key is used to get packets from > host to host securely. A symmetric system is used to encrypt the data > stream between two communicating processes. Both systems seem to be > awfully slow (will NOT support video). I have no more ideas. Anyone > care to comment? Use symmmetric system of Caesar, not CBC-DES. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Aug 18 16:42:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22877; Thu, 18 Aug 1994 14:00:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA27653; Thu, 18 Aug 1994 13:59:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA27637; Thu, 18 Aug 1994 13:41:14 +1000 Precedence: list From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17633; Thu, 18 Aug 1994 10:32:16 +1000 (from jcjones@MIT.EDU) Received: from CACCIATORE.MIT.EDU by MIT.EDU with SMTP id AA28493; Wed, 17 Aug 94 20:31:55 EDT Received: by cacciatore.MIT.EDU (5.57/4.7) id AA13031; Wed, 17 Aug 94 20:31:53 -0400 Message-Id: <9408180031.AA13031@cacciatore.MIT.EDU> To: Big-Internet@munnari.OZ.AU Subject: Still going... Date: Wed, 17 Aug 94 20:31:52 EDT Sorry guys. While many of you seem to have accepted SIPP-16 for lack of something better, I cannot. When I read the papers on SIPP-16, I can't help but cringe at the fact that I may just well be reading the seed document for what will become the basis for universal connectivity for several decades to come. The very thought triggers a temporal migraine. I don't want to find myself 20 years from now trying to explain to some young computer geek how the IETF ever allowed SIPP-16 to become a standard. If you want to fix IP, fine. Fix IP. But don't push IPng (SIPP-16) as the universal protocol. If you want to create the universal protocol, do just that, create it. 10 Steps to Creating a Universal Internetworking Protocol: 1. Think to yourself, "I would like to create a rock-solid, state-of-the-art universal networking protocol. 2. Go off into a dark hole and think creatively. If you are afraid of the dark, bring along a friend or two, but not more. 3. Clear your mind(s). Let the ideas flow. Resist the temptation to latch on to old ideas simply because new ideas aren't coming fast enough, *unless* those old ideas have scientific merit. 4. Write down your ideas in a notebook. 5. From ideas in notebook, generate a preliminary design specification. 6. Examine the design specification for integrity. If the protocol has any serious design flaws, goto 1. 7. Figure out how to make the protocol compatible with what's already out there without compromising the essence of the design. 8. If design is not compatible with industry standards, goto 7. 9. Write a proposal, and submit it to the IETF and the internetworking community. 10. Fight like hell to keep others from altering the design unless they have good, TECHNICALLY SUPPORTABLE reasons. This is the approach I have taken, and it seems to be working so far. Unfortunately, I'm running out ot time (School starts in September), and the ideas aren't coming as fast as I would like them to, so I would appreciate a little help from anyone who can provide it. More than two may reply :-). 1. Security: I'm using a hybrid system. Public key is used to get packets from host to host securely. A symmetric system is used to encrypt the data stream between two communicating processes. Both systems seem to be awfully slow (will NOT support video). I have no more ideas. Anyone care to comment? 2. Routing table lookup performance: I (erroneously?) assumed that there could be multiple routes selected for a given packet. Is this true? Some people mentioned hash values, implying that one route entry would be hit and possibly selected. What's the deal here? Is it too much to ask that all route entries be examined per packet? (You may assume a maximum of say, 1000 entries, with and average on the order of 20). Thanks, J.C. Jones 129 Franklin Street Cambridge, Ma 01239 (617) 494-1034 jcjones@athena.mit.edu From owner-Big-Internet@munnari.OZ.AU Fri Aug 19 00:40:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08516; Fri, 19 Aug 1994 00:40:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA28255; Fri, 19 Aug 1994 00:39:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA28239; Fri, 19 Aug 1994 00:24:36 +1000 Precedence: list Received: from transarc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08140; Fri, 19 Aug 1994 00:24:33 +1000 (from lws+@transarc.com) Received: by transarc.com (5.54/3.15) id for Big-Internet@munnari.oz.au; Thu, 18 Aug 94 10:24:23 EDT Received: via switchmail; Thu, 18 Aug 1994 10:24:23 -0400 (EDT) Received: from po2.transarc.com via qmail ID ; Thu, 18 Aug 1994 10:23:53 -0400 (EDT) Received: from manwe via qmail ID ; Thu, 18 Aug 1994 10:01:39 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.manwe.rs.aix32 via MS.5.6.manwe.rs_aix3; Thu, 18 Aug 1994 10:01:38 -0400 (EDT) Message-Id: <4iIqb2mSMUw_0v30hE@transarc.com> Date: Thu, 18 Aug 1994 10:01:38 -0400 (EDT) From: Lyle_Seaman@transarc.com To: jcjones@mit.edu Subject: Re: Still going... Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9408180612.AA17188@necom830.cc.titech.ac.jp> References: <9408180612.AA17188@necom830.cc.titech.ac.jp> Excerpts from transarc.external.big-internet: 18-Aug-94 Re: Still going... Masataka Ohta@necom830.c (392) > Both systems seem to be > > awfully slow (will NOT support video). I have no more ideas. Anyone > > care to comment? > Use symmmetric system of Caesar, not CBC-DES. Um. I think the point is "use something faster than DES", right, not "use a substitution cipher"? I hope so. Check out "Fast Software Encryption" (Ross Anderson, Ed. Pub. Springer-Verlag 1994). Actually, I'm not sure what the official title is, it might be "LN COMP SCI 809 ENCRYPTION ALGORITHMS". ISBN: 0-387-58108-1 From owner-Big-Internet@munnari.OZ.AU Fri Aug 19 01:06:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08052; Fri, 19 Aug 1994 00:20:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA28197; Fri, 19 Aug 1994 00:19:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA28181; Fri, 19 Aug 1994 00:05:31 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06263; Thu, 18 Aug 1994 23:20:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15429; Thu, 18 Aug 94 09:17:59 -0400 Date: Thu, 18 Aug 94 09:17:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9408181317.AA15429@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU Subject: Re: Still going... Cc: jnc@ginger.lcs.mit.edu From: jcjones@mit.edu While many of you seem to have accepted SIPP-16 for lack of something better, I cannot. ... I don't want to find myself 20 years from now trying to explain to some young computer geek how the IETF ever allowed SIPP-16 to become a standard. Well, you'd better get mentally prepared. Actually, you don't have to; I plan to leave the explaining up to the people who thought it was a good idea. (This is assumed that SIPP-16 is a success in the market, which of course remains to be seen.) 10 Steps to Creating a Universal Internetworking Protocol: 2. Go off into a dark hole and think creatively. ... 3. Clear your mind(s). Let the ideas flow. Resist the temptation to latch on to old ideas simply because new ideas aren't coming fast enough ... 10. Fight like hell to keep others from altering the design unless they have good, TECHNICALLY SUPPORTABLE reasons. Been there. Done that. Didn't work. Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 19 03:00:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11222; Fri, 19 Aug 1994 02:20:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA28366; Fri, 19 Aug 1994 02:19:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA28361; Fri, 19 Aug 1994 02:18:24 +1000 Precedence: list Received: from gateway.sequent.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09285; Fri, 19 Aug 1994 01:07:23 +1000 (from mckenney@sequent.com) Received: from eng3.sequent.com by gateway.sequent.com (5.61/1.34) id AA07116; Thu, 18 Aug 94 08:07:31 -0700 Received: by eng3.sequent.com (5.65/1.34) id AA06754; Thu, 18 Aug 94 08:06:58 -0700 From: "Paul E. McKenney" Message-Id: <9408181506.AA06754@eng3.sequent.com> Subject: Re: Still going... To: jcjones@MIT.EDU Date: Thu, 18 Aug 1994 08:06:57 -0700 (PDT) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9408180031.AA13031@cacciatore.MIT.EDU> from "jcjones@MIT.EDU" at Aug 17, 94 08:31:52 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2908 >10 Steps to Creating a Universal Internetworking Protocol: > >1. Think to yourself, "I would like to create a rock-solid, > state-of-the-art universal networking protocol. >2. Go off into a dark hole and think creatively. If you are afraid > of the dark, bring along a friend or two, but not more. >3. Clear your mind(s). Let the ideas flow. Resist the temptation to > latch on to old ideas simply because new ideas aren't coming fast > enough, *unless* those old ideas have scientific merit. >4. Write down your ideas in a notebook. >5. From ideas in notebook, generate a preliminary design specification. >6. Examine the design specification for integrity. If the protocol > has any serious design flaws, goto 1. >7. Figure out how to make the protocol compatible with what's already > out there without compromising the essence of the design. >8. If design is not compatible with industry standards, goto 7. >9. Write a proposal, and submit it to the IETF and the internetworking > community. >10. Fight like hell to keep others from altering the design unless > they have good, TECHNICALLY SUPPORTABLE reasons. > >This is the approach I have taken, and it seems to be working so far. >Unfortunately, I'm running out ot time (School starts in September), >and the ideas aren't coming as fast as I would like them to, so I >would appreciate a little help from anyone who can provide it. More >than two may reply :-). I encourage your efforts! If you are single-minded, diligent, and willing to work with others -- especially those others who used these same 10 steps, but came up with radically different answers than you did -- then perhaps if in, say, ten years time unforeseen changes in requirements and technology place great stress on SIPP-16, you will be ready with the solution. And at that time, there will be forward-looking folks like yourself who will argue that your solution should not be adopted. They will be considering yet other changes to requirements... ;-) Thanx, Paul >1. Security: > >I'm using a hybrid system. Public key is used to get packets from >host to host securely. A symmetric system is used to encrypt the data >stream between two communicating processes. Both systems seem to be >awfully slow (will NOT support video). I have no more ideas. Anyone >care to comment? > >2. Routing table lookup performance: > >I (erroneously?) assumed that there could be multiple routes selected >for a given packet. Is this true? Some people mentioned hash values, >implying that one route entry would be hit and possibly selected. >What's the deal here? Is it too much to ask that all route entries be >examined per packet? (You may assume a maximum of say, 1000 entries, >with and average on the order of 20). > >Thanks, > >J.C. Jones >129 Franklin Street >Cambridge, Ma 01239 >(617) 494-1034 >jcjones@athena.mit.edu > From owner-Big-Internet@munnari.OZ.AU Fri Aug 19 11:01:04 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17838; Fri, 19 Aug 1994 06:16:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02145 Fri, 19 Aug 1994 05:42:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA28571; Fri, 19 Aug 1994 05:39:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA28566; Fri, 19 Aug 1994 05:27:51 +1000 Precedence: list Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14359; Fri, 19 Aug 1994 04:25:33 +1000 (from jcjones@MIT.EDU) Received: from W20-575-27.MIT.EDU by MIT.EDU with SMTP id AA00817; Thu, 18 Aug 94 14:25:30 EDT Received: by w20-575-27.MIT.EDU (5.0/4.7) id AA04979; Thu, 18 Aug 1994 14:25:21 +0500 Message-Id: <9408181825.AA04979@w20-575-27.MIT.EDU> To: Masataka Ohta Cc: Big-Internet@munnari.OZ.AU, Lyle_Seaman@transarc.com Subject: Re: Still going... In-Reply-To: Your message of "Thu, 18 Aug 1994 15:12:12 +0200." <9408180612.AA17188@necom830.cc.titech.ac.jp> Date: Thu, 18 Aug 1994 14:25:20 EDT From: "John C. Jones" Content-Length: 918 >> 1. Security: >> >> I'm using a hybrid system. Public key is used to get packets from >> host to host securely. A symmetric system is used to encrypt the data >> stream between two communicating processes. Both systems seem to be >> awfully slow (will NOT support video). I have no more ideas. Anyone >> care to comment? > Use symmmetric system of Caesar, not CBC-DES. I guess I failed to mention that I am not using DES. I'm toying around with a scheme using cellular automatons but it doesn't seem to work (it's not secure, but the principle is the same.) The reason I began to try alternative methods in the first place is that I read somewhere a couple of months ago that even hardware implementations of DES could not encrypt at high-end video rates (Handbook of LAN Technology, Paul Fortier, I think). Is this true? What kind of encryption rates can we realistically expect on the average desktop? From owner-Big-Internet@munnari.OZ.AU Fri Aug 19 11:39:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22702; Fri, 19 Aug 1994 08:40:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA28734; Fri, 19 Aug 1994 08:40:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA28727; Fri, 19 Aug 1994 08:30:52 +1000 Precedence: list From: smb@research.att.com Received: from research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18171; Fri, 19 Aug 1994 06:26:34 +1000 (from smb@research.att.com) Message-Id: <9408182026.18171@munnari.oz.au> Received: by gryphon; Thu Aug 18 16:13:05 EDT 1994 To: "John C. Jones" Cc: Masataka Ohta , Big-Internet@munnari.OZ.AU, Lyle_Seaman@transarc.com Subject: Re: Still going... Date: Thu, 18 Aug 94 16:13:04 EDT I guess I failed to mention that I am not using DES. I'm toying around with a scheme using cellular automatons but it doesn't seem to work (it's not secure, but the principle is the same.) The reason I began to try alternative methods in the first place is that I read somewhere a couple of months ago that even hardware implementations of DES could not encrypt at high-end video rates (Handbook of LAN Technology, Paul Fortier, I think). Is this true? What kind of encryption rates can we realistically expect on the average desktop? See @inproceedings{verfastdes, author = {H. Eberle and C. P. Thacker}, title = {A 1 {G}bit/second {GaAs} {DES} Chip}, booktitle = {Proceedings of the IEEE 1992 Custom Integrated Circuits Con ference}, publisher = {IEEE}, year = 1992, month = {May}, pages = {19.7/1--4} } Yes, that's a gigabit/second. I suspect that that's fast enough. From owner-Big-Internet@munnari.OZ.AU Fri Aug 19 16:27:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08943; Fri, 19 Aug 1994 16:20:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA29126; Fri, 19 Aug 1994 16:20:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA29110; Fri, 19 Aug 1994 16:00:37 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03543; Fri, 19 Aug 1994 13:46:18 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 19 Aug 94 12:38:46 +0859 From: Masataka Ohta Message-Id: <9408190339.AA02662@necom830.cc.titech.ac.jp> Subject: Re: Still going... To: jcjones@MIT.EDU (John C. Jones) Date: Fri, 19 Aug 94 12:38:43 JST Cc: Big-Internet@munnari.OZ.AU, Lyle_Seaman@transarc.com In-Reply-To: <9408181825.AA04979@w20-575-27.MIT.EDU>; from "John C. Jones" at Aug 18, 94 2:25 pm X-Mailer: ELM [version 2.3 PL11] > >> 1. Security: > >> > >> I'm using a hybrid system. Public key is used to get packets from > >> host to host securely. A symmetric system is used to encrypt the data > >> stream between two communicating processes. Both systems seem to be > >> awfully slow (will NOT support video). I have no more ideas. Anyone > >> care to comment? > > > Use symmmetric system of Caesar, not CBC-DES. > > I guess I failed to mention that I am not using DES. I'm toying > around with a scheme using cellular automatons but it doesn't seem to > work (it's not secure, but the principle is the same.) Cellular automatons? What? CRC based scrambler should work fine with frequent exchange of keys through DES. > The reason I > began to try alternative methods in the first place is that I read > somewhere a couple of months ago that even hardware implementations of > DES could not encrypt at high-end video rates (Handbook of LAN > Technology, Paul Fortier, I think). Is this true? A subtle question. Even with hardware, you can't make latency of each DES calculation so short. But for throughput, you can pipeline or you can use multiple processors. The problem is that the throughput of CBC-DES is bounded by the latency even though pipilining is used. So, DES/sec is totally different from CBC-DES/sec. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Aug 19 18:20:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13001; Fri, 19 Aug 1994 18:20:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA29242; Fri, 19 Aug 1994 18:20:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA29237; Fri, 19 Aug 1994 18:12:52 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11630; Fri, 19 Aug 1994 17:35:41 +1000 (from kre@munnari.OZ.AU) To: "John C. Jones" Cc: Masataka Ohta , Big-Internet@munnari.OZ.AU, Lyle_Seaman@transarc.com Subject: Re: Still going... In-Reply-To: Your message of "Thu, 18 Aug 1994 14:25:20 EDT." <9408181825.AA04979@w20-575-27.MIT.EDU> Date: Fri, 19 Aug 1994 17:35:35 +1000 Message-Id: <1878.777281735@munnari.OZ.AU> From: Robert Elz Date: Thu, 18 Aug 1994 14:25:20 EDT From: "John C. Jones" Message-ID: <9408181825.AA04979@w20-575-27.MIT.EDU> even hardware implementations of DES could not encrypt at high-end video rates I know there's been a reply to that query, in the negative (ie: hardware does exist) - and I should also say that I am most certainly no encryption or video expert (or anything even approaching either - not even a novice), however could not video encryption work together with video copression schemes, such that only one in every N bytes/words/whatever of video data actually need be encrypted, the rest being rendered useless by the compression scheme breaking totally once data sync is lost if those encrypted bytes are not recovered correctly? Might this work well enough to permit even encryption and decryption in software, not requiring Gb/s type DES chips? It also seems to me that anything likely to really need data bandwidths of this magnitude will almost certainly benefit from compression of some kind - the aim of compression is to make every bit in the resulting compressed scheme essential to the final decompression algorithm (redundancy is the anthisesis of compression) - and that as above, encypting only a small fraction of the compressed data stream should be as effective as encrypting all of it, shouldn't it? kre ps: I doubt that Big-Internet is the correct place to carry on a discussion like this. While there are certainly people who understand both video and encryption on it, there are far more of them in other places. From owner-Big-Internet@munnari.OZ.AU Wed Aug 24 05:17:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10478; Wed, 24 Aug 1994 04:51:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA04830; Wed, 24 Aug 1994 04:50:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA04814; Wed, 24 Aug 1994 04:36:14 +1000 Precedence: list Received: from [200.9.244.2] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09941; Wed, 24 Aug 1994 04:36:05 +1000 (from @secyt.gov.ar:ftp@colort.edu.ar) Received: by secyt.gov.ar with UUCP id <1322>; Tue, 23 Aug 1994 15:32:54 -0300 Received: by colort.edu.ar (PcCorreo 4.2) with UUCP; Tue, 23 Aug 94 14:25:42 ARG Date: Tue, 23 Aug 1994 11:25:42 -0300 From: "ftp" Message-Id: <341hw110@colort.edu.ar> X-Mailer: PcCorreo 4.2 / (c) Fernando Lopez Guerra. To: big-internet@munnari.OZ.AU Subject: help help From owner-Big-Internet@munnari.OZ.AU Thu Aug 25 08:33:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08335; Thu, 25 Aug 1994 08:33:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA06274; Thu, 25 Aug 1994 08:31:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06258; Thu, 25 Aug 1994 08:18:11 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07575; Thu, 25 Aug 1994 08:16:24 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 25 Aug 94 01:09:42 +0900 From: Masataka Ohta Message-Id: <9408241609.AA15587@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: kre@munnari.OZ.AU Date: Thu, 25 Aug 94 1:09:40 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <842.776628429@munnari.OZ.AU>; from "Robert Elz" at Aug 12, 94 4:07 am X-Mailer: ELM [version 2.3 PL11] > This list was constructed comparatively quickly, as no > discussion of the models was entertained. Instead their > proponents, or some of them, will write a short submission > supporting their view of what an EID should be like, and why, > and submit it to the Big-Internet mailing list for public > review. Some of those may become Internet Drafts. > Here is my home work. In short, it is a counter proposal against IPv6's attempt to newly introduce provider dependence. The names EID/locator are intentionally NOT used. Any comments? Masataka Ohta IPv6 Numbering Plan for Provider Independence Introduction IPv4 addresses do not contain provider dependent information. Thus, with IPv4 addresses, we can select and change providers without reassigning IP addresses. On the other hand, IPv6 addresses contain provider dependent part for routing aggregation. If host identification is controlled by providers, it is difficult to change providers or have multiple provider. The more serious problem is security. As the host identification is the core for security, subscribers does not want the identification is controlled by providers. This memo proposes an address assignment scheme for IPv6 which allows both routing aggregation and provider independence, supporting 10^12 networks and 10^15 hosts. The proposal also allows efficient forwarding on routers. Anti-trust mechanism for provider ID assignment is also proposed to have geographically-near-optimal and least-costly routing with proper provider selection. Assignment Plan for IPv6 address The 16 byte IPv6 address is divided into four fields: 5 byte "Provider ID", 2 byte "Subscriber ID", 1 byte "Subnet ID" and 8 byte "Interface ID". "Provider ID" and "Subscriber ID" together is called "Provider dependent part". Provider dependent part is supplied by providers and dynamically reconfigurable at system boot time or even during operation. It is expected that routers to providers supply provider dependent part information through anycasting. Interface ID is a globally unique ID of an interface of a host. It is supplied by subscribers. The configuration may be automatic. But it is expected that renumbering is necessary not so often, in general, only when a host is purchased or the host is moved to different suborganization of the provider. Host specific information such as IP address to host name mapping is looked up only through the Masataka Ohta [Page 1] IPv6 Numbering Plan for Provider Independence Interface ID and there is no provider dependence of security. Subnet ID is also supplied by subscribers and identifies a subnet within a subscribers LAN. The configuration may be automatic through nearest routers. Renumbering is necessary when a location of a host is changed to a different subnet. Network layer identification of a host is done through Interface ID just like the current IPv4. Users can change providers at will just by disconnecting one of its external routers and connect it to a new provider. Interfaces of a host of a subscriber belonging to multiple providers may have multiple provider dependent parts but only a single interface ID. Routing is controlled purely by the first 8 bytes of IPv6 address: "Provider ID", "Subscriber ID" and "Subnet ID" and is more efficient than schemes using full 16 bytes. Assignment Plan for Provider ID, Subscriber ID and Subnet ID 5 byte provider ID uniquely identifies a provider in the Internet. 5 byte provider ID combined with 2 byte subscriber ID uniquely identifies a subscriber in the Internet. 1 byte subnet ID uniquely identifies a subnet in a subscribers network. A large subscriber having more than 256 subnets will have multiple subscriber IDs from a provider. A large provider having more than 65536 subscriber IDs or having some geographical constraints will have multiple provider IDs. For geographically-near-optimal routing, a provider ID should not cover an area of 100Km radius. Thus, a large provider must use different provider IDs for hosts located more than 200Km apart. Thus, a subscriber can specify to use a local provider A, then use low-rate long-distance-provider B and finally use the provider A who is also serving the destination. [Note: It is expected that the provider have IX to other providers within the 200Km radius. But that's a operational requirement and should be separated from assignment policy]. About 17,000 IDs are necessary to cover the surface of the Earth. Inter-planetary communication is NOT considered here. Masataka Ohta [Page 2] IPv6 Numbering Plan for Provider Independence Anti-trust mechanism for provider ID assignment is also proposed to have geographically-near-optimal routing. Assignment Plan for Interface ID First three of Interface ID is assigned from IANA to country NICs. Each country NIC use the next three bytes for independent subscribers. A subscriber use the last two bytes for the internal use. Supporting 10^12 networks and 10^15 hosts How the requirement to support 10^12 networks and 10^15 hosts can be satisfied? First, how routing between 10^12 networks is possible? 10^3 hosts within a subnet can easily be identified by the Interface ID. Thus, (Provider ID, Subscriber ID, Subnet ID) must identify 10^12 networks. It is not unnatural that a provider, in average, supports at least 10^3 subscribers. It can also be safely assumed that subnet ID can identify 10^1 subnets. Thus, Provider ID is required to identify 10^8 hosts. Considering that the requirement contains 10^2 safety factor, the least two significant bytes of the Provider ID are reserved for the factor. The remaining 3 bytes (2^24>10^7) are much more than enough to identify 10^6 providers. It is assumed that by the time we support 10^12 networks, flat routing of 10^6 providers is not a problem at all. The reserved lower two bytes of provider ID may also be used for two-level routing among providers. Next, how identification of 10^15 hosts is possible? 10^3 hosts of a subscriber can easily be identified by the last two bytes of Interface ID. For the remaining 10^12 factor, IANA and country NICs are expected to manage the upper 6 bytes completely densely. Thus, it should be possible to support more than 10^14 networks. Conclusion As the 16 byte address space is so large, it is possible to use it wisely to enjoy full provider independence, including provider change without renumbering and long distance provider selection by provider IDs. Masataka Ohta [Page 3] From owner-Big-Internet@munnari.OZ.AU Fri Aug 26 01:16:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13202; Thu, 25 Aug 1994 23:46:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07027; Thu, 25 Aug 1994 23:44:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07018; Thu, 25 Aug 1994 23:41:26 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12754; Thu, 25 Aug 1994 23:36:51 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: Big-Internet@munnari.OZ.AU Subject: Re: Draft minutes - Toronto EID BOF In-Reply-To: Your message of "Thu, 25 Aug 1994 01:09:40 +0200." <9408241609.AA15587@necom830.cc.titech.ac.jp> Date: Thu, 25 Aug 1994 23:36:36 +1000 Message-Id: <2559.777821796@munnari.OZ.AU> From: Robert Elz Date: Thu, 25 Aug 94 1:09:40 JST From: Masataka Ohta Message-ID: <9408241609.AA15587@necom830.cc.titech.ac.jp> Here is my home work. Well - that's not exactly what was intended in the part of the minutes that you quoted - but that's understandable, as I'm yet to do my homework, and actually send the solicitations for the input that anticipated... Very soon now I promise. The rest of your message I think should be considered without complicating it by tangling it up with the details of what might or might not be an EID. kre From owner-Big-Internet@munnari.OZ.AU Wed Aug 31 20:27:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15167; Wed, 31 Aug 1994 20:24:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA14054; Wed, 31 Aug 1994 20:23:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA14038; Wed, 31 Aug 1994 20:04:08 +1000 Precedence: list From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Received: from clix.aarnet.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12412; Wed, 31 Aug 1994 19:07:00 +1000 (from Jeff.Latimer@FINANCE.ausgovfinance.telememo.au) X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 19:02:58 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 31 Aug 1994 19:04:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 31 Aug 1994 19:03:31 +1000 Date: Wed, 31 Aug 1994 19:03:31 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: IPNG@SUNROOF.ENG.SUN.COM, Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au, big-internet@munnari.oz.au, /G=GERARD/S=JOSEPH/PRMD=IBMMAIL/ADMD=IBMX400/C=AU/@clix.aarnet.edu.au, ALAN.LLOYD@DCTHQ.datacraft.telememo.au, CMOORE@CELSIUS.OZ.AU, BRUCE-STEER@SAA.sa.telememo.au, "/I=J/S=HOULDSWORTH/OU=STE0906/O=ICL/PRMD=ICL/ADMD=GOLD 400/C=GB/"@clix.aarnet.edu.au , GUPTILA.V.DESILVA@ITSCOMMS.ATONAT.ausgovtax.telememo.au, MIKE.DUFFY@ITS-EXEC.ATONAT.ausgovtax.telememo.au, GEORGE.S.STACEY@ITSCOMMS.ATONAT.ausgovtax.telememo.au, Ann.Whitehead@FINANCE.ausgovfinance.telememo.au X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Aug 31 19:03:29 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 290319310894 Alternate-Recipient: Allowed Message-Id: <290319310894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: IPNG@SUNROOF.ENG.SUN.COM (Non Receipt Notification Requested), Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au (Non Receipt Notification Requested), big-internet@munnari.OZ.AU (Non Receipt Notification Requested) Cc: /G=GERARD/S=JOSEPH/PRMD=IBMMAIL/ADMD=IBMX400/C=AU/@clix.aarnet.edu.au (Non Receipt Notification Requested), ALAN.LLOYD@DCTHQ.datacraft.telememo.au (Non Receipt Notification Requested), CMOORE@CELSIUS.OZ.AU (Non Receipt Notification Requested), BRUCE-STEER@SAA.sa.telememo.au (Non Receipt Notification Requested), "/I=J/S=HOULDSWORTH/OU=STE0906/O=ICL/PRMD=ICL/ADMD=GOLD 400/C=GB/"@clix.aarnet.edu.au (Non Receipt Notification Requested), GUPTILA.V.DESILVA@ITSCOMMS.ATONAT.ausgovtax.telememo.au (Non Receipt Notification Requested), MIKE.DUFFY@ITS-EXEC.ATONAT.ausgovtax.telememo.au (Non Receipt Notification Requested), GEORGE.S.STACEY@ITSCOMMS.ATONAT.ausgovtax.telememo.au (Non Receipt Notification Requested), Ann.Whitehead@FINANCE.ausgovfinance.telememo.au (Non Receipt Notification Requested) Subject: Re: Consensus on NSAPs required >Please, folks, move further discussion about CLNP >or address size OFF the IP6 list and onto the big-internet >list. This will help those of us who do automatic input >filtering. >That's big-internet@munnari.oz.au for the list, and >big-internet-request@munnari.oz.au for [un]subscribe requests. - I must say that I have difficulty with this. We have a problem here and we could take it off line but as being relatively new to this environment how do we approach so that the argument can be heard. Call it a "Court of Appeal" if you like. Are you saying, go to big-internet just to bury the issue? We need to sort this out pronto as lot of work could be wasted if the issue is successfully argued later. Some assistance for an appellant might take the agro out this issue. Jeff From owner-Big-Internet@munnari.OZ.AU Wed Aug 31 21:43:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17690; Wed, 31 Aug 1994 21:43:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA14173; Wed, 31 Aug 1994 21:43:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA14157; Wed, 31 Aug 1994 21:28:37 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16945; Wed, 31 Aug 1994 21:27:45 +1000 (from kre@munnari.OZ.AU) To: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Cc: Kim.Fenley@ADITCS.CM-DIMP.HQADF.defencenet.gov.au, big-internet@munnari.OZ.AU, /G=GERARD/S=JOSEPH/PRMD=IBMMAIL/ADMD=IBMX400/C=AU/@clix.aarnet.edu.au, ALAN.LLOYD@DCTHQ.datacraft.telememo.au, CMOORE@CELSIUS.OZ.AU, BRUCE-STEER@SAA.sa.telememo.au, "/I=J/S=HOULDSWORTH/OU=STE0906/O=ICL/PRMD=ICL/ADMD=GOLD 400/C=GB/"@clix.aarnet.edu.au, GUPTILA.V.DESILVA@ITSCOMMS.ATONAT.ausgovtax.telememo.au, MIKE.DUFFY@ITS-EXEC.ATONAT.ausgovtax.telememo.au, GEORGE.S.STACEY@ITSCOMMS.ATONAT.ausgovtax.telememo.au, Ann.Whitehead@FINANCE.ausgovfinance.telememo.au Subject: Re: Consensus on NSAPs required In-Reply-To: Your message of "Wed, 31 Aug 1994 19:03:31 +1000." <290319310894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> Date: Wed, 31 Aug 1994 21:27:38 +1000 Message-Id: <3489.778332458@munnari.OZ.AU> From: Robert Elz Date: Wed, 31 Aug 1994 19:03:31 +1000 From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-ID: <290319310894*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> Call it a "Court of Appeal" if you like. The IETF has procedures like that - however like real courts of appeal, they deal with errors in procedure (errors of law), decisions made that you don't like (ie: you lose the argument, or didn't bother arguing at all) don't create rights to appeal. Are you saying, go to big-internet just to bury the issue? I don't think that's it - rather B-I is a list where people argue a lot about all kinds of issues related to the IPng protocol design - it had extensive discuissions on whether 16 bytes was OK, incl discussion on both variable addressing and nsaps in June and July. B-I is also the public list of the IPng directorate (as it was briefly for the ROAD work). On the other hand the ipng list is meant for the people actually developing the protocols and implementations that meet the decisions that have been taken - its the wrong place to argue those decisions (would be like protesting the Mabo legislation in the Family court - simply the wrong forum - that one has work to do, and shouldn't be distracted by other work - however important that other work may seem to be - non Australians can ignore this local reference). We need to sort this out pronto as lot of work could be wasted if the issue is successfully argued later. The point is that the issue has been fully argued already. In immence amounts of volume (if nothing else). kre ps: I deleted the ipng list from this message. pps: if you missed the earlier prod from Brian, send subscription (and unsubscription) requests for the B-I list to "Big-Internet-Request@munnari.OZ.AU" (the capitalisation doesn't matter).