From brian@dxcoms.cern.ch Wed May 11 15:17:55 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA15951 for ; Wed, 11 May 1994 09:18:31 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08660; Wed, 11 May 1994 15:17:57 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21114; Wed, 11 May 1994 15:17:55 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405111317.AA21114@dxcoms.cern.ch> Subject: COMMERCIALIZING INTERNET? [Orig: Internet Economics....] - comp.infosystems.www #15733 (fwd) To: ipng@cmf.nrl.navy.mil Date: Wed, 11 May 1994 15:17:55 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 13323 Folks, In case you have not seen this (re IPng accounting requirement) Brian [forwarding trail deleted] ---------- Forwarded message ---------- Date: Thu, 5 May 1994 09:28:44 -0500 Reply-To: H-Net Political History discussion list Sender: H-Net Political History discussion list From: H-Pol Co-moderator Peter Knupfer Subject: NETNEWS: Internet Economics: Will user fees be necessary? To: Multiple recipients of list H-POL TAXPAYER ASSETS PROJECT - INFORMATION POLICY NOTE May 3, 1994 This is a note about an important issue: the future pricing of Internet services. Please repost freely. - University of Michigan Economist Hal Varian says the Internet is likely to face some type of usage based pricing in the future. - Varian says increasing demands on Internet by multimedia applications and commercial bypass of telephone networks will lead to significant increases in demands on Internet resources, and create pressures for usage based pricing models. - Varian proposes a system of congestion based pricing, that will allow free off-peak usage, but speculates that other outcomes are possible, and - Predicts eventual demise of CIX model of flat rate (no settlements) pricing for Network Service Providers. NOTES ON PROFESSOR HAL VARIAN'S APRIL 21 TALK ON INTERNET ECONOMICS by James Love (love@essential.org) May 3, 1994 On April 21, the Telecommunications Policy Roundtable (TPR) held its first workshop on the future of democratic discourse on the Internet. Hal Varian, a professor of economics and finance from the University of Michigan, presented "Economic FAQs about the Internet," a paper co-authored with Jeffery K. Mackie-Mason. The Workshop was held at the Carnegie Institution in Washington, DC, and attended by about 60 persons. There was considerable interest in the topic. TAP had received more than 400 requests for copies of the paper (including about 350 requests by electronic mail). The paper is available for anonymous ftp, gopher, or World Wide Web at gopher.econ.lsa.umich.edu, or by sending an email message to ndaly@essential.org. Professor Varian's prepared talk followed the paper fairly closely, with a number of facts and antidotes thrown in to illustrate his main points. Among economists Varian is known as a superb expositor, and his presentation was as clear and accessible as the paper. Varian spent the first part of his talk describing such topics as who "owns" various components of the Internet (backbones, midlevel networks, etc), technical aspects of Internet routing, and the growth of traffic on the Internet. I won't bother to go over all the points which are explained in the paper, but a few items are worth mentioning. Varian disclosed that Internet data packets contain an unused "priority bit," that was originally designed to allow Military brass to assign priorities in data routing. The costs of routers (workstations) had fallen much faster than the long distance transport costs, and the long distance backbone facilities were often the bottleneck. Varian also spent a good amount of time explaining how Internet usage is changing, and that while electronic mail is the service most widely used, it constitutes only about 8 percent of the bits sent over the network. New applications, such as the multimedia Mosaic, Internet Fax, and Internet radio are rapidly becoming large users of Internet resources, and these new uses of the Internet are creating huge pressures to change the way Internet services are priced. To illustrate his point, Varian talked about the new Power PCs, which will allow a single user (a college student talking to his parents) to hook up a video camera, and send about 1 megabyte of data per second to the Internet, nearly tying up an entire T-1 line. Varian indicated that the power of workstations connected to the Internet is increasing much faster than the capacity of the Internet to carry traffic. Moveover, a number of commercial users of the Internet are rapidly finding ways to bypass the higher priced telephone networks, both domestically and internationally. Varian was focused largely on the increased congestion cause by the new demands on the Internet. Interestingly, his own research indicated that peak demands shifted from day to day, and peak and off-peak usage could not be easily predicted by the time-of-day, as it is for telephone service. In the United States the Internet is unregulated, and there are no internal prices for Internet usage. Network service providers typically buy bandwidth, or capacity, and face zero marginal costs for usage. End users face a variety of charges, depending upon how their service providers resell access to the network. Some foreign countries, such as New Zealand and Chile, charge Internet users for traffic, as measured by bits. Different uses for Internet services have different requirements in terms of routing priorities. Electronic mail generally does not require an immediate claim on network bandwidth, and can be managed to travel "off peak." On the other hand, some services, such as video conferencing, Internet "talk," or running Mosaic, generally allow the user to command bandwidth at a particular time. Varian was quite clear that he believes that the problem of congestion on the Internet will become a much larger problem as the Internet becomes used for a more diverse set of applications (and the growing power of desktop computers to generate data). Varian said that he believes there will eventually be prices for Internet usage, and the only real uncertainty will be which pricing system is used. A very difficult problem will be the development of accounting systems and other mechanisms to facilitate billing for Internet usage. Generally speaking, it is not simple to determine if data packets contain electronic mail, fax transmissions, video, or other data, making content based pricing problematic. There are also a number of complex issues relating to when or where traffic would be "charged" for internet usage, since users gain access to the Internet from a highly decentralized network of workstations and networks. Varian also talked about problems in determining if senders or receivers would pay for data transmissions, which he illustrated by talking about ftp or gopher servers (who was the "sender" of the data, the person sending the query, or the file server which returns data?). According to Varian, a number of persons are working on these problems, and many important decisions will be determined by engineers working on technical issues. He singled out the Internet Society's Internet Engineering Task Force as the most important forum for groups sorting these issues out. Varian said that any scheme to charge for internet usage would also involved non-trivial costs in terms of metering or accounting, and possibly significant changes in the culture of the Internet (the question on many persons minds is the future of the Internet Listserves), although on a more optimistic note, he said the costs of routing and backbone services should be low, if calculated on a per user basis. Varian said little about the Commercial Internet Exchange (CIX) in his prepared remarks, but in response to questions, he said that he did not believe the CIX pricing model (a flat fee for connectivity) was sustainable, and he thought that the new Network Access Point (NAP) providers (Ameritech, Pac Bell, Sprint, and MFS) would employ a usage based pricing approach. Varian also talked at some length about work underway to create mechanisms for charging for other types of transactions, using a variety of schemes to create "virtual cash" for use on the Internet, such as the services recently announced by Commerce Net using technology developed under NSF funded R&D. Varian said that government R&D in this area was welcomed, because it provided neutral non-proprietary systems that couldn't be controlled or manipulated by a single firm. Varian described the new Internet architecture, which is based upon four NAPs, each controlled by a telephone company, which Varian described as the new "cloverleaves" for the Internet (connecting various backbones and networks), and the new vBNS high speed backbone. Varian said the high interest in the vBNS contract was due largely to its strategic role in the development of new Internet technologies, including accounting and payment mechanisms, which may eventually be deployed to the entire Internet. (MCI "won" the recent NSF contract for the vBNS, but the award is being contested by Sprint. AT&T was also rumored to have been an unsuccesful bidder on the vBNS). Varian's own preference for Internet pricing is a system that only charges for priority routing. As described in several papers (written with MacKie-Mason), Varian would employ a system whereby users would "bid" for access when congestion was a problem, and routers would give priority to packets that had the highest willingness to pay. Users would pay the lowest price that was accepted in this routing "auction," so everyone would have an incentive to reveal their true willingness to pay. Under Varian's scheme, all Internet traffic which did not claim priority status would travel for free. Thus, for example, a large Internet mailing list such as Humanist, PACS-L or CPSR- Announce could mail for "free," with an off peak priority. For Varian's scheme to work, it would be necessary to have routers compare "bids" by packets, priority bidders would have to "pay" for access to someone, and there would have to be a high degree of consensus, so the priority packets would not face bottlenecks or delays anywhere on the Internet. Varian acknowledged that it was possible that the Varian (and MacKie- Mason) system of pricing might not be adopted, and some less elegant system, such as pricing by the bit, may be coming. A number of persons wanted to know who would decide these issues, and Varian was not too specific. The message (the "guess") seemed to be that the companies which controlled the NAPs and a critical mass of the backbones would have a lot to say about what was eventually adopted. Varian was asked to speculate about future telco investments in Internet providers, such as purchases of companies like PSI or UUNET, but he was reluctant to predict much, other than to emphasize the importance of competitive free entry into the market for Internet services, which would undermine monopolist practices. Varian was asked if it was possible that a coalition of Internet providers would have the power to implement a pricing scheme that would have an adverse impact on the future of Internet listserves (many of which "send" more than 100,000 messages per day), but he was reluctant to be very specific in his predictions, other than to say that many outcomes were possible. Note: On April 29, a follow-up workshop was held with Dr. Steve Wolff of NSF, Professor David Farber, and PSI CEO William Schrader. Notes from that workshop and other information regarding Internet pricing will be posted to tap-info. --------------------------------------------------------------------- TAP-INFO is an Internet Distribution List provided by the Taxpayer Assets Project (TAP). TAP was founded by Ralph Nader to monitor the management of government property, including information systems and data, government funded R&D, spectrum allocation and other government assets. TAP-INFO reports on TAP activities relating to federal information policy. tap-info is archived at ftp.cpsr.org; gopher.cpsr.org and wais.cpsr.org Subscription requests to tap-info to listserver@essential.org with the message: subscribe tap-info your name --------------------------------------------------------------------- Taxpayer Assets Project; P.O. Box 19367, Washington, DC 20036 v. 202/387-8030; f. 202/234-5176; internet: tap@essential.org +---------------------------------------------------------------+ | Earl Babbie ][ BABBIE@NEXUS.CHAPMAN.EDU ][ CIS:76424,156 | | Chapman University, Orange CA 92666 ][ Voice: 714-997-6565 | +---------------------------------------------------------------+ ********************************************************************** * Sharron S. Humenick Humenick@UWYO.EDU * * School of Nursing, University of Wyoming * * Box 3065 Phone 307-766-2319 * * Laramie, Wyoming 82071-3065 Fax: 307-766-6821 * ********************************************************************** -- =============================================================================== | Hibatur Rahman Ahmad | http://www.lehigh.edu/hra2/public/www-data/hra2.html | =============================================================================== From kasten@mailserv-D.ftp.com Wed May 11 09:44:36 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA16227 for ; Wed, 11 May 1994 09:46:02 -0400 Received: from ftp.com by ftp.com ; Wed, 11 May 1994 09:45:55 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 11 May 1994 09:45:55 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA22213; Wed, 11 May 94 09:44:36 EDT Date: Wed, 11 May 94 09:44:36 EDT Message-Id: <9405111344.AA22213@mailserv-D.ftp.com> To: brian@dxcoms.cern.ch Subject: Re: COMMERCIALIZING INTERNET? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 1099 > NOTES ON PROFESSOR HAL VARIAN'S APRIL 21 TALK > ON INTERNET ECONOMICS >.... Somewhat interesting. My only real comment is that a) the criteria keep the current operating 'priciple' of 'cooperative anarchy' and b) with the network services criterion, we should have the ability to sort packets into various classes - we do not mention what the classes are but presumably, the classification structure would be fairly flexible and dynamic. So, since the Internet would remain a cooperative anarchy, some providers can do flat-rate charging, others can do free access, others can do usage based charging, others can do Varian's "bidding". By having a flexible packet classification structure, we could tag packets as to whether we are willing to pay for their carriage or not, and how much, and so on. My conclusion is that the criteria seem to provide for all the needed elements to build an accounting scheme such as Varian described, or any other scheme. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From scoya@CNRI.Reston.VA.US Thu May 12 15:44:14 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA25887 for ; Thu, 12 May 1994 15:45:38 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11776; 12 May 94 15:44 EDT To: ipng@cmf.nrl.navy.mil Subject: DRAFT Minutes from May 9 Teleconference Date: Thu, 12 May 94 15:44:14 -0400 From: Steve Coya Message-ID: <9405121544.aa11776@IETF.CNRI.Reston.VA.US> DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference May 9, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Steve Bellovin / AT&T Jim Bound / DEC Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Paul Francis / NTT Mark Knopper / Ameritech Greg Minshall / Novell Frank Kastenholz / FTP Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- Ross Callon / Wellfleet Dave Clark / MIT Craig Partridge / BBN 1. The directorate approved the minutes of the teleconference held on April 25. Coya to place into IETF Shadow directories, and send copies of the minutes to the IAB and IESG. 2. A verbal roll call was taken to ascertain who would be at the retreat. Of those on the call, all were planning to attend except for Jon Crowcroft and Brian Carpenter (Brian will attend via phone). Coya to probe the three directorate members who did not participate in the call to see if they will be attending the retreat. 3. Allison announced that she and Scott had prepared an IPNG track for the Toronto IETF meeting. 4. Scott provided a brief summary of what occurred in the IPNG area during Interop in Vegas, and mentioned some upcoming meetings where there will be an IPNG panel. Allison summarized what would/could be happening at the INET meeting in Prague. 5. Allison outlined what is expected in the technical reviews being done by the directorate. Everyone was polled, and those who have not yet submitted their reviews stated they would have something soon, some by next week, all will be done prior to the retreat. 6. Frank Kastenholz reviewed some of the comments/suggestions received about the requirements document. Following with tradition, each item was discussed in minute detail as/when mentioned :-) 7. The desire for a good revision of the requirements document, to be available as a reference point in time for the retreat, was reiterated. The document will be frozen and released in its final form just after the retreat. 8. The directorate stated that each candidate should bring a paper copy of their own document set. A suggestion that the decision be made based on the least amount of documentation (i.e simplicity speaks for itself) was greeted with mirth, but was not adopted by the directorate. Quote du jours: It was not marketing material per se, but was without content and presented in an upbeat manner. From J.Crowcroft@cs.ucl.ac.uk Fri May 13 09:15:45 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA29104 for ; Fri, 13 May 1994 04:16:18 -0400 Message-Id: <199405130816.EAA29104@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 May 1994 09:15:48 +0100 To: ipng@cmf.nrl.navy.mil Subject: Re: IPng Architecure and an IPng Architect Date: Fri, 13 May 94 09:15:45 +0100 From: Jon Crowcroft I believe we have all the pieces of an architecture, but perhaps i have perceived them as a whole, where maybe i'm either wrong, or else that perception is hard when yo uare closer to the IETF than me. Pieces come from the work that has gone on in some of the research groups now for some time, and more recently in working groups. There is a clear overlap between these pieces, and they way some of them should be implemented, actually goes a long way to addressing some of the base points in the IPng requirements document. note that once upon a time, the requirements used to be split into the basic ones, routing & addressing, and the 'frills' we would add since if we are doing an IPng, we must get a number of things in at this opportunity as there is no other. However, we now have a set of requirements hich i believe interlock very nicely, and lead towards a unified architecture that is self supporting. key pieces are not the boring details of addresses (eid and paths etc) and routes; key pieces are: Flows, as per integrated services wg, and the papers from scott shenker, dave clark, lizia zhang, both in int-serv, and at various SIGCOMM and other conferences. Multicast, as in the DVMRP, then MOSPF and CBT, and now PIM work. Resource Reservation - the specification of flows to routers i na robust, but non virtual circuit way, wisely independent of unicast or multicast routing algorithm. Security: the IAB retraet produced a report which cites the use of a lower layer ID (flow) authenticated, as of use for access control, authentication, assistance in prevention of traffic analysis etc etc Talking to a lot of commercial customers, their view of the requirement is biased towards these latter problems, and NOT the simple matter of address space and router table management. [because of the amount of commercial and multimedia traffic expected, e.g. from reuters, telerate, the financial times, e.g. from the BBC, e.g. from teaching, healthcare]. If you can authenticate the flow id, and instatiate the state in routers, you buy the network multi-service support, link sharing, and all the rest. You also buy fast packet forwarding. A lot of this is expressed in Nimrod, but I find that the way it is there is hard to digest at the moment. Once this is a basic building block, the format of the fields that actually build a path is largely irrelevant, provided there are enough bits, since they are not referenced often. However, there is one major constraint on them from elksewhere that does bite: migration. if you buy the idea of interworking IPv4 and IPng, rather than dual stack, then a handy format is important. Personally, I belive dual stack is unacceptable for financial reasons, unless someone can show me why interworking is more expesnive, and given our expierence of interworking colouirred book, ISO and IPv4, i doubt they will. so, while i am not going to write a review of all the proposals, I believe it is quite obvious what the consclusion of what i'm saying is. on the matter of accounting, obviously a reasoanble authenticated flow gives to low cost accounting. since the current favoured models of billing by people who actually understand the economics of such things (e.g. scott shenker, or Hal Varian) favours a 3 tier system: 1 best effort traffic continues to be datagram, but should be serveed round robin (with random early drop or similar) or any queueing scheme that attmepts to do statistically even share - other traffic comes into 2 categroies. 2. stuff that is best effort QoS (i.e. if there is capacity, provide the QoS, otherwise degrade) and 3. absolute QoS (predictive or guaranteed) whether there is congestion or not. charging for internet should be fixed, except for the last or last two classes... we have work in hand to head towards this, so we need the change control to make it happen over the next 3 years as we evolve ipng.... we probably want a minimum of legacy code in routers....but what do i know about routers anyhow... regards jon From sob@hsdndev.harvard.edu Sat May 14 23:10:21 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA08329 for ; Sat, 14 May 1994 23:10:26 -0400 Date: Sat, 14 May 94 23:10:21 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405150310.AA14303@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: another white paper Network Working Group S. Bellovin IPng White Paper AT&T Bell Laboratories Experimental 14 May 1994 The Shape of the Bits Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Overview and Rational The existing debate has focused on SIPP versus TUBA versus CATNIP. Some people point to existing support for TUBA-like headers, while others point to SIPP's ease of parsing. But those are the wrong things to look at. To look at the headers is to focus on the shape of the bits. But that is all but irrelevant. With a few exceptions, detailed near the end of this memo, bits can be filed, hammered, glued, bent, and otherwise worked into the proper shape. What is of interest is what those bits do, regardless of what they look like. In this memo, I will attempt to extract the salient areas of difference. It may be that the best choice for IPng can be synthesized, not by merging two or three of the candidates, but by selecting among the different philosophical aspects in the different areas. The areas discussed here are security, address formats, and Bellovin [Page 1] White Paper The Shape of the Bits 14 May 1994 transition. The analysis for autoconfiguration and routing is similar. Security Services SIPP's security protocol is derived from SP3. It uses encapsulation of the payload, and a SAID to select a key, algorithm, etc. TUBA's security protocol is derived from NLSP, which is derived from SP3. By a curious coincidence, it, too, uses encapsulation of the payload, and a SAID to select a key, algorithm, etc. In other words, the two IPng candidates use a virtually identical security mechanism. The most significant semantic difference is the existence of a sequence number in the SIPP version, to provide some protection against replay. But the existence of such sequence numbers -- and the question is quite controversial -- is orthogonal to any IPng issues. For now, we should assume an encapsulating security protocol, and pick the shape later. A more difficult question, and one that is relevant to this directorate, is what aspects of a security protocol should be mandatory. On the one hand, IPv4 has none, and the Internet is surviving (though in some cases just barely) without one. On the other hand, there have been calls for universal cryptographic authentication. A complicating factor is the plethora of legal restrictions on the import, use, or export of cryptographic technology. SIPP's routing headers make security more urgent. But if similar functionality is added to TUBA, say to support mobility, the same need will arise. I therefore recommend that support for an authentication encapsulation be mandatory with IPng -- whichever candidate is chosen. The scope is not yet clear; it may be desirable to have it operable gateway-to-gateway or user-to-user as well as the more obvious host-to-host. I regard it as mandatory that IPng be firewall-friendly. TUBA is somewhat nicer in this regard, since SIPP's nested headers make it harder to find the transport header for filtering. With either, an encapsulating encryption protocol hides such information. I recommend that both header formats be augmented to include a transport header pointer. This field would be adjusted as necessary to accomodate options or headers added along the way. Network elements that create packets with no visible transport header -- i.e., those that do encryption or create fragments -- should set the field to NULL. Naturally, firewalls are free to reject such packets. Bellovin [Page 2] White Paper The Shape of the Bits 14 May 1994 It is unclear router-to-host messages should be authenticated. Multicast messages cannot be authenticated without the use of public key techniques; however, those are probably too expensive to use on a routine basis. Unicast messages, such as redirects, could be authenticated using a network layer security protocol; however, that would require a fair amount of extra state per end system in each router. If this were implemented, hosts could randomly challenge routers to repeat recent multicast advertisements using authenticated unicast; a mismatch would would be grounds for sounding an alarm. Address Formats TUBA and CATNIP use CNLP NSAPs for addressing. Particular instantiations of these NSAPs are used for IPv4 addresses. SIPP uses fixed-length 64-bit addresses, with a compatibility-mode bit used to indicate the presence of an IPv4 address. Other combinations of high-order address bits are used to denote particular semantics, such as local addresses. The two essential questions here are whether or not NSAPs (and by extension, CLNP itself) are valuable because of the existing OSI infrastructure, and whether or not the SIPP semantics are valuable. If SIPP semantics are valuable, they can easily be embedded in a TUBA or CATNIP NSAP, possibly by allocation of a new AFI. The SIPP address formats are almost completely untried in the real world. It is thus unclear how valuable they will ultimately turn out to be. On the other hand, they offer the promise of new functionality. Transition SIPP uses a combination of tunneling and packet format translators during transition. CATNIP uses translation and IP options. TUBA requires dual stacks. None are pretty. The translators are a potential bottleneck. Doing the translation is much more expensive than today's routing function. This will be especially serious for large interior routers, which may be servicing many high-speed networks. On the other hand, dual-stack code will require significantly more software development and maintenance into the indefinite future. Both IPv4 and IPng must be supported, with corresponding hooks in the transport protocols. Even some applications will have to know the difference, if they wish to take advantage of new functionality but still behave properly (if suboptimally) when talking to older neighbors. Bellovin [Page 3] White Paper The Shape of the Bits 14 May 1994 Alone of the three proposals, CATNIP is closely tied to its transition strategy. Indeed, that is its raison d'etre. (My apologies for the missing ^...) Both SIPP and TUBA could use the other's transition strategy without significant loss. Oddly enough, I recommend pursuing both. Initial deployments of IPng should be dual stack, to permit interoperability with the vast majority of neighbor systems, and without the need to develop and deploy translator boxes first. As translators become available, support for IPv4 can gradually be dropped as systems are upgraded. The need to talk to the remainder of the IPv4 base can be handled by the translators, which by then should be common. The Shape of the Bits The remaining issue is what the headers should look like. SIPP has the elegance and simplicity of fixed-format headers. TUBA uses CLNP, which is already supported by most routers. It also has variable- length addresses, which, some claim, are inherently slower to parse. That may not be so. Cisco, at least, claims to be able to route OSI at greater than 170K packets/second. To the extent that performance is enhanced by properly-aligned addresses, we can decree a preferred address format, as per TURNIPP. Performance will be better if this format is used, but systems will still work even if it is not. A similar analysis applies to SIPP's nested headers. There is no reason we cannot nest TUBA or CATNIP headers, if we so choose. This would provide fragmentation, source routing, etc. Conclusion We need to agree on the functionality we want. The shape of the bits is almost irrelevant. Bellovin [Page 4] From sob@hsdndev.harvard.edu Sun May 15 00:32:40 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA08586 for ; Sun, 15 May 1994 00:32:54 -0400 Date: Sun, 15 May 94 00:32:40 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405150432.AA19801@hsdndev.harvard.edu> To: deering@parc.xerox.com Subject: Re: DECnet Phase IV to Phase V presentation Cc: ipng@cmf.nrl.navy.mil Steve, Bill gave me a copy so that it could be forwarded to the IPng directorate and to that TACIT WG. I did not ask about wider dist. Can we leave it there for a few days so thedirectorate people can get it than remove it? Jim - can you ask Bill if it would be ok to put it up on hsdndev for full public distribution? Thanks Steve for going through the work, I think there is a bunch of good stuff there. Scott From jcurran@nic.near.net Sun May 15 00:52:42 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA08621 for ; Sun, 15 May 1994 00:53:44 -0400 Received: from platinum.near.net by nic.near.net id aa27397; 15 May 94 0:53 EDT To: Scott Bradner cc: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: DECnet Phase IV to Phase V presentation In-reply-to: Your message of Sun, 15 May 1994 00:32:40 -0400. <9405150432.AA19801@hsdndev.harvard.edu> Date: Sun, 15 May 1994 00:52:42 -0400 From: John Curran Message-ID: <9405150053.aa27397@nic.near.net> -------- ] Thanks Steve for going through the work, I think there is a bunch of ] good stuff there. The last 5 slides are a particularly good summary of some of the lessons learned on how to design effective transition mechanisms. Thanks Scott and Steve! /John From J.Crowcroft@cs.ucl.ac.uk Sun May 15 16:34:44 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA09850 for ; Sun, 15 May 1994 11:35:26 -0400 Message-Id: <199405151535.LAA09850@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 15 May 1994 16:34:46 +0100 To: sob@hsdndev.harvard.edu (Scott Bradner) cc: ipng@cmf.nrl.navy.mil Subject: Re: another white paper In-reply-to: Your message of "Sat, 14 May 94 23:10:21 EDT." <9405150310.AA14303@hsdndev.harvard.edu> Date: Sun, 15 May 94 16:34:44 +0100 From: Jon Crowcroft > The Shape of the Bits very amusing title:-) > The remaining issue is what the headers should look like. SIPP has > the elegance and simplicity of fixed-format headers. TUBA uses CLNP, > which is already supported by most routers. It also has variable- > length addresses, which, some claim, are inherently slower to parse. > That may not be so. Cisco, at least, claims to be able to route OSI > at greater than 170K packets/second. 170k pps is not very fast... also note (sorry to repeat myself), that noone, but noone, supports multicast CLNP. or flows. or, to my knowledge, NLSP that i can use outside the US ... or free host CLNP implementations with any reasoanble testedness. the 'existing code' argument favours none of the proposals (which is nice in a way...i like lvel playing fields!) >Conclusion > We need to agree on the functionality we want. The shape of the bits > is almost irrelevant. i thought the requirements document craig&frank wrote was this jon From jallard@microsoft.com Sun May 15 18:18:57 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA11376 for ; Sun, 15 May 1994 21:23:01 -0400 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA27395; Sun, 15 May 94 17:24:34 -0700 Message-Id: <9405160024.AA27395@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sun, 15 May 94 17:24:33 PDT To: ipng@cmf.nrl.navy.mil Subject: Re: concern over retreat..... Date: Sun, 15 May 94 18:18:57 >My second inclination then is to have the experts stay in another >room during the meeting, and be called upon only for the >portions of the meeting that concern their particular expertise. >This would require that they state the expertise they represent >before they come, and they be limited to that. Perhaps it is >impossible to keep them in another room (it is kind of a strange >thing to do), but I think they must somehow be limited in their >discourse to the specific expertise that they represent. i have similar concerns and agree more or less with an approach similar to yours. although i haven't seen a formal agenda, it may make sense to have a directorate-only meeting where we outline our questions and specific concerns, narrow them as much as possible between the members, and only then call in the experts for answers, input, and bribes. we could then kick them out, dileberate further, and repeat the process. i realize that this approach probably sounds a bit lawyer-esque, but i've sat through more mud-slinging sideshows at ietf wg's where work to be done was derailed by finger pointing and breathlessly inspired religious debates between opposing positions. a mechanism similar to what paul has described may be more effective than issuing gag-orders. scott/allison - what are the experts expecting? how were you planning on managing their partipation? _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From kre@munnari.OZ.AU Mon May 16 10:31:57 1994 Return-Path: kre@munnari.OZ.AU Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA11223 for ; Sun, 15 May 1994 20:33:38 -0400 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24068; Mon, 16 May 1994 10:32:00 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil Subject: Re: continuing EID discussion In-Reply-To: Your message of "Mon, 16 May 1994 08:57:19 +0200." <9405152357.AA15021@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 10:31:57 +1000 Message-Id: <18310.769048317@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405152357.AA15021@cactus.slab.ntt.jp> You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". No, that's not the solution, its a requirement - the reason is that I don't believe that location dependant identifiers can be allocated in an effecient enough manner that we can reasonably allocated a fixed width field of any reasonable size that we can really be sure is going to last forever. Encoding all that location information simply uses too many bits for no useful purpose in the identifier that's required. For this we have to pick something that will last forever without changing format - forever, not just 50 or 100 years. Maybe 128 bit identifiers encoding location might do, but even there I'd be hesitant, as I know how much wastage there is going to be in those things. 256 bits might be enough. I think I'd prefer to make the things location independant, so the allocation policy can be effecient, and we can stick with a reasonably sized field. kre From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:31:57 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA11330 for ; Sun, 15 May 1994 21:11:52 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24495; Mon, 16 May 1994 10:43:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24453; Mon, 16 May 1994 10:33:18 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24068; Mon, 16 May 1994 10:32:00 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil Subject: Re: continuing EID discussion In-Reply-To: Your message of "Mon, 16 May 1994 08:57:19 +0200." <9405152357.AA15021@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 10:31:57 +1000 Message-Id: <18310.769048317@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405152357.AA15021@cactus.slab.ntt.jp> You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". No, that's not the solution, its a requirement - the reason is that I don't believe that location dependant identifiers can be allocated in an effecient enough manner that we can reasonably allocated a fixed width field of any reasonable size that we can really be sure is going to last forever. Encoding all that location information simply uses too many bits for no useful purpose in the identifier that's required. For this we have to pick something that will last forever without changing format - forever, not just 50 or 100 years. Maybe 128 bit identifiers encoding location might do, but even there I'd be hesitant, as I know how much wastage there is going to be in those things. 256 bits might be enough. I think I'd prefer to make the things location independant, so the allocation policy can be effecient, and we can stick with a reasonably sized field. kre From francis@cactus.slab.ntt.jp Mon May 16 08:57:19 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id TAA11090 for ; Sun, 15 May 1994 19:57:59 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 08:57:20 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA04204; Mon, 16 May 1994 08:57:20 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15021; Mon, 16 May 94 08:57:19 JST Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405152357.AA15021@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > > let me say that I hope nobody is still considering the > notion of requiring EIDs for IPng. > > I certainly am. > > As I said before, we should specify requirements, not > solutions. > > EIDs are requirements, not solutions. Or, if the acronym > invokes bad vibes, then the requirement can be stated as ... > > IPng must provide a method to transmit location independant > identifiers for the use of transport protocols, and others, > and the definition the uses of TCP and UCP over IPng must > include using this location independant identifier in their > pseudo-checksums. > > To me, that is requiring EIDs (and one specific use for them). Yes, this is still requiring EIDs, and I still think it doesn't make sense as a requirement. You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". What if you worded it this way: IPng must provide a method to transmit identifiers for the use of higher-layer protocols. The identifier must remain the same throughout the lifetime of the higher-layer protocol, independent of the location of the identified node, and independent of the route used for the packets. This to me is a requirement. I believe that it captures the functionality that you desire without stating that EIDs are the solution. Do you agree? PF > > There's a reason for this - apart from all the other likely > uses of EIDs, defining the transport level to use this > location independant (and hence routing useless) identifier > enables the IP layer to be upgraded much more seamlessly > if (when) needed in the future. > > Pulling one network level header off, doing address (locator) > substitution if needed, and sticking a modified header on > as packets flow from one region of the net to another is a > possibility. What won't be is fiddling TCP to manipulate its > checksum to account for changes in the identifier it uses. > That may be possible now, most of the time, but we have to assume > that in the future at least some packets will either be > encrypted, or signed, above the network level, meaning that > modifications are impossible - modifications at the net level > have to be permitted to allow things like hop counts to be > adjusted, and for manipulation of options, etc. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different > network layers, > > This I agree with. > > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), > > this is a solution, not a requirement, and while I agree with > it as a possibility, I wouldn't require it. > > and 3) is administered by vendors not users (it comes > attached to computers out of the box). > > But this I asbolutely (and totally) disagree with. I require > a mapping from EID into name, that is I want EIDs to be *the* > binary identifier. To make this mapping plausible, there > has to be some kind of administrative relationship between > EIDs owned by some administration (company, department, > individual, whatever), so they can reasonably be made to > fit into the DNS (or any other kind of directory). I do > not require EIDs to be fixed for all time, they only need > remain while any connection using them remains alive - if all > connections die when a host is rebooted, and there is some > way to handle dynamic DNS registration, then assigning a new > (currently unused, not new for all time) EID to a host at boot > time is just fine. > > I have no problem with a vendor assigned ID being used to > acquire the EID from some kind of server, nor, if the > organisation can manage it, to using it with some organisation > prefix to form the EID, but using a vendor assigned number > alone seems unworkable. Using vendor assigned numbers this > way also eases the pressure on them to absolutely guarantee > global uniqueness - their number only needs to be unique within > the organisation in which its used, which means that occasional > errors in id assignment by the vendors can almost certainly be > tolerated - just as we usually tolerate duplicate IEEE assigned > numbers today. > > kre > > Paul's message - if you've seen it before, no need to read > any further.... > > Date: Thu, 12 May 94 10:12:05 JST > From: francis@cactus.slab.ntt.jp (Paul Francis) > Message-Id: <9405120112.AA20949@cactus.slab.ntt.jp> > To: sipp@sunroof.Eng.Sun.COM > Subject: continuing EID discussion (was Re: FORMAL REQUEST : SIPP EIDs and Locators) > > Since the discussion of the Subject Re: FORMAL REQUEST : SIPP EIDs and Locators > has degraded to counting angels and slinging mud, I have stopped reading > it and am concerned that others have also stopped reading it and therefore > didn't look at my reply to Steve and Christian, which I spent a fair amount > of time and thought on. > > So, at the expense of sending the same message to the list twice, I here > resubmit my message under the new Subject..... > > PF > > --------------------------------------------------------------- > > > I want to rebutt the comments of Steve and Christian regarding > the costs/benefits of EIDs. But first let me say that I hope > nobody is still considering the notion of requiring EIDs for > IPng. As I said before, we should specify requirements, not > solutions. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different network layers, > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), and 3) is > administered by vendors not users (it comes attached to > computers out of the box). To make it clear that this is > what I'm talking about, let me call this particular beast > a VANITY (Vendor-Assigned Node-Identifying Transport Yodel). > > (If you're wondering about "Yodel", this is a reference to the > ancient practice of Swiss herders identifying each other by > their distinctive yodel. Yes, I'm making this up..... :-) > > In the following I quote Steve's message. I didn't save > Christian's message, so I'll paraphrase what I remember > him saying. > > > > - EIDs are neither necessary nor sufficient to solve the problems > > for which they are usually cited as a solution, e.g., multi-homing, > > mobility, dynamic address changing. > > This is true except for the case of "serverless" host address > auto-configuration, which I believe to be a very important > requirement, and which I think is the primary benefit of VANITYs. > I think this use alone justifies the use of VANITYs. The other > uses (Steve mentions) are icing on the cake, but I agree with > Steve that these can be done other ways, as shown with SIPP. > > > - EIDs are yet another name space to be allocated and managed, in addition > > to addresses and DNS names. Our experience with our existing name > > spaces makes me *very* loath to create another, especially without a > > *very* concrete reason. > > > > Christian also mentioned the cost of managing "another" name space. > I would like to argue, to the contrary, that the use of VANITYs very > significantly *reduces* the cost of name space management--specifically > because they allow for host auto-configuration. Let's assume that > most of the cost of name space management is human cost. Currently, > hundreds and soon (if not already) thousands of people are involved > in assigning millions of IP host numbers. Further, > those are the people who are the least qualified to be assigning > numbers (not because they aren't smart, but because it isn't their > primary job, they're not networking gurus, etc.). If you use > VANITYs, you move this function to a smallish number of vendors > (some hundreds rather than many thousands), where the assignment > process can be localized, focused, and probably largely automated. > You save countless man-hours. > > >- It may well turn out that higher-level protocols will end up defining > > higher-level IDs at a much finer grain than the EIDs that have been > > proposed in this community, for example, globally unique process IDs > > in support of fine-grain process migration. (See the VMTP protocol > > spec for one example of such an approach.) Such higher-level IDs > > are likely to make EIDs redundant. > > I think this is a wash. Probably a good way for an application to > manage such a number space is to take the network layer identifier > and append some additional information specific to that application. > If the network layer identifier is an address (i.e., combination > locator/identifier), then the address also is "redundant". Either way, > you are replicating some information. However, if you believe > VANITYs to be stable for longer than addresses, perhaps the use of > VANITYs to help manage the application EIDs is better than the > use of addresses. > > > >- In the most common case, where the locating semantics of either or both > ............ > > of changing addresses, or whatever), requiring the presence of pure > > EIDs would make the packet header significantly larger than it would > > otherwise be. True, the price we accept for our connectionless internet > > Agreed. > > > model is a large header on every packet. But I think we have a duty as > > designers to make relatively efficient use of that header space, since > > it is a "tax" imposed on every packet. I am particularly concerned > > I agree. If all other things are equal, we should favor smaller > headers.....but...... > > > about header size because I see increasing use of encapsulation as a > > multi-purpose mechanism in the Internet, such that many packets may > > end up carrying multiple SIPP headers on at least some part of their > > At least some of the reasons for such encapsulations would be eliminated > if we had VANITYs (for instance, the use of encapsulation for getting > mobility). > > > journey. I'm also concerned with making it possible to forward SIPP > > packets at very high speed, and keeping the basic header size relatively > > compact is one part of that (e.g., more likely to fit into a cache line, > > when using a general-purpose processor as a packet switch). > > Mumble. Maybe so. The use of VANITYs doesn't increase the amount > of info that has to be examined, though, so perhaps with some care > one can manage to funnel only the needed info into the cache line. > I don't know for sure, and it probably differs significantly from > machine to machine. Another point is that the VANITY might help > high speed switching because it can be used as a flow ID, blah blah > mumble hand wave. > > > A common answer to the large header size issue is to suggest using > > header compression over slow links. Besides the fact that that > > does not address the high-speed forwarding issue, another problem > > is that our current strategy for header compression in IPv4 only works > > for TCP traffic and relies on certain properties of TCP. However, I > > expect much of the high-volume traffic in the future to be UDP, e.g., > > What? High volume over slow links? If you can solve that one you > can become a rich man! :-) > > If it is high volume (and therefore high speed), you by definition > don't need header compression. > > > real-time audio and video. I don't know what's involved in building > > a robust header compression scheme for SIPP/UDP headers (there's a > > good project for someone to work on!), but I'd rather not depend on > > I agree. In fact, SIPP could use this like yesterday.... > > > it being easy or cheap to do. Another, perhaps unfounded, concern is > > that compression spends CPU cycles to save bandwidth, but we may want > > to support nodes that are starved for *both* CPU and bandwidth, e.g., > > very low-powered wireless devices. > > I suspect that a machine that is starved for CPU and bandwith will > not be exchanging packets simultaneously with a large number of other > devices, and therefore compression should work well at low cost > (i.e., lots of redundancy from packet to packet). > > > Ok, finally I want to address Christian's comments (and Minshall has > also mentioned this) about the non-uniqueness of IEEE 802 numbers. > I agree that this is a problem, but I wonder how much. In the > context of SIPP, the spec is very specific about requiring the use > of "universally administered" 802 numbers. Thus, I *hope* that > the "soft" assignments of 802 numbers doesn't apply. As for sloppy > practice by vendors resulting in duplicate "universally administered" > 802 numbers, at least with SIPP this should rarely cause a real > problem (unless I'm missing something). *If* we get SIPP hosts to > *always* assign a different flow ID for each route sequence it is > using, then duplicate 802 numbers only cause a problem when > 1) the hosts with the duplicates are talking to the same machine, > 2) the flow IDs are the same, and 3) the other identifiers, such > as transport socket, are all the same. I think that the probability > of this is small enough that failures caused for this reason will > be in the noise compared to failures caused for other reasons. > > /* start aside */ > > As an aside, this is *yet another* good reason to have > hosts always assign a flow ID. I'm now thoroughly > convinced that the cost of doing this is well worth it. > Off the top of my head, the benefits are: > > 1. Hosts receiving packets can use the flow ID to > detect a change in route sequence. Thus, they > don't have to parse through the route sequence > every time. > > 2. Routers can use the flow ID to identify flows. > My gut feeling is that 90% or more of real time > could be handled without explicit flow setup. > > 3. If not 2, then at least routers can use it to > aid their caching strategies (I know that there > are other issues here, like how to advance ther > route header). > > 4. "Fixes" the blatant distant-snooping security hole > introduced by route sequence reversal. (Sorry Ran, > but having thought about this more, I remain > convinced that this technique is useful for this > purpose.) > > 5. The duplicate VANITY problem. > > /* end aside */ > > > Actually, this notion that a host can successfully talk to > multiple other hosts that have the same VANITY is interesting > to me (not that I'm advocating it). Specifically, it makes > me ask what the point is to IP header authentications, especially > in the absense of higher-layer authentication. As long as > packets can successfully get from source to dest and back, what > does the network layer care about authentication? The application > cares about authentication, but authenticating the network layer > for the purpose of authenticating the application seems weak > and more expensive than doing it at the application. > > Maybe I'm just being dense, but can someone please re-iterate > for me why we need to authenticate at the network layer? > > PF > > From owner-Big-Internet@munnari.OZ.AU Mon May 16 08:57:19 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA11310 for ; Sun, 15 May 1994 21:06:44 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24440; Mon, 16 May 1994 10:27:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24374; Mon, 16 May 1994 10:07:23 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22845; Mon, 16 May 1994 09:57:30 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 08:57:20 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA04204; Mon, 16 May 1994 08:57:20 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15021; Mon, 16 May 94 08:57:19 JST Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405152357.AA15021@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > > let me say that I hope nobody is still considering the > notion of requiring EIDs for IPng. > > I certainly am. > > As I said before, we should specify requirements, not > solutions. > > EIDs are requirements, not solutions. Or, if the acronym > invokes bad vibes, then the requirement can be stated as ... > > IPng must provide a method to transmit location independant > identifiers for the use of transport protocols, and others, > and the definition the uses of TCP and UCP over IPng must > include using this location independant identifier in their > pseudo-checksums. > > To me, that is requiring EIDs (and one specific use for them). Yes, this is still requiring EIDs, and I still think it doesn't make sense as a requirement. You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". What if you worded it this way: IPng must provide a method to transmit identifiers for the use of higher-layer protocols. The identifier must remain the same throughout the lifetime of the higher-layer protocol, independent of the location of the identified node, and independent of the route used for the packets. This to me is a requirement. I believe that it captures the functionality that you desire without stating that EIDs are the solution. Do you agree? PF > > There's a reason for this - apart from all the other likely > uses of EIDs, defining the transport level to use this > location independant (and hence routing useless) identifier > enables the IP layer to be upgraded much more seamlessly > if (when) needed in the future. > > Pulling one network level header off, doing address (locator) > substitution if needed, and sticking a modified header on > as packets flow from one region of the net to another is a > possibility. What won't be is fiddling TCP to manipulate its > checksum to account for changes in the identifier it uses. > That may be possible now, most of the time, but we have to assume > that in the future at least some packets will either be > encrypted, or signed, above the network level, meaning that > modifications are impossible - modifications at the net level > have to be permitted to allow things like hop counts to be > adjusted, and for manipulation of options, etc. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different > network layers, > > This I agree with. > > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), > > this is a solution, not a requirement, and while I agree with > it as a possibility, I wouldn't require it. > > and 3) is administered by vendors not users (it comes > attached to computers out of the box). > > But this I asbolutely (and totally) disagree with. I require > a mapping from EID into name, that is I want EIDs to be *the* > binary identifier. To make this mapping plausible, there > has to be some kind of administrative relationship between > EIDs owned by some administration (company, department, > individual, whatever), so they can reasonably be made to > fit into the DNS (or any other kind of directory). I do > not require EIDs to be fixed for all time, they only need > remain while any connection using them remains alive - if all > connections die when a host is rebooted, and there is some > way to handle dynamic DNS registration, then assigning a new > (currently unused, not new for all time) EID to a host at boot > time is just fine. > > I have no problem with a vendor assigned ID being used to > acquire the EID from some kind of server, nor, if the > organisation can manage it, to using it with some organisation > prefix to form the EID, but using a vendor assigned number > alone seems unworkable. Using vendor assigned numbers this > way also eases the pressure on them to absolutely guarantee > global uniqueness - their number only needs to be unique within > the organisation in which its used, which means that occasional > errors in id assignment by the vendors can almost certainly be > tolerated - just as we usually tolerate duplicate IEEE assigned > numbers today. > > kre > > Paul's message - if you've seen it before, no need to read > any further.... > > Date: Thu, 12 May 94 10:12:05 JST > From: francis@cactus.slab.ntt.jp (Paul Francis) > Message-Id: <9405120112.AA20949@cactus.slab.ntt.jp> > To: sipp@sunroof.Eng.Sun.COM > Subject: continuing EID discussion (was Re: FORMAL REQUEST : SIPP EIDs and Locators) > > Since the discussion of the Subject Re: FORMAL REQUEST : SIPP EIDs and Locators > has degraded to counting angels and slinging mud, I have stopped reading > it and am concerned that others have also stopped reading it and therefore > didn't look at my reply to Steve and Christian, which I spent a fair amount > of time and thought on. > > So, at the expense of sending the same message to the list twice, I here > resubmit my message under the new Subject..... > > PF > > --------------------------------------------------------------- > > > I want to rebutt the comments of Steve and Christian regarding > the costs/benefits of EIDs. But first let me say that I hope > nobody is still considering the notion of requiring EIDs for > IPng. As I said before, we should specify requirements, not > solutions. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different network layers, > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), and 3) is > administered by vendors not users (it comes attached to > computers out of the box). To make it clear that this is > what I'm talking about, let me call this particular beast > a VANITY (Vendor-Assigned Node-Identifying Transport Yodel). > > (If you're wondering about "Yodel", this is a reference to the > ancient practice of Swiss herders identifying each other by > their distinctive yodel. Yes, I'm making this up..... :-) > > In the following I quote Steve's message. I didn't save > Christian's message, so I'll paraphrase what I remember > him saying. > > > > - EIDs are neither necessary nor sufficient to solve the problems > > for which they are usually cited as a solution, e.g., multi-homing, > > mobility, dynamic address changing. > > This is true except for the case of "serverless" host address > auto-configuration, which I believe to be a very important > requirement, and which I think is the primary benefit of VANITYs. > I think this use alone justifies the use of VANITYs. The other > uses (Steve mentions) are icing on the cake, but I agree with > Steve that these can be done other ways, as shown with SIPP. > > > - EIDs are yet another name space to be allocated and managed, in addition > > to addresses and DNS names. Our experience with our existing name > > spaces makes me *very* loath to create another, especially without a > > *very* concrete reason. > > > > Christian also mentioned the cost of managing "another" name space. > I would like to argue, to the contrary, that the use of VANITYs very > significantly *reduces* the cost of name space management--specifically > because they allow for host auto-configuration. Let's assume that > most of the cost of name space management is human cost. Currently, > hundreds and soon (if not already) thousands of people are involved > in assigning millions of IP host numbers. Further, > those are the people who are the least qualified to be assigning > numbers (not because they aren't smart, but because it isn't their > primary job, they're not networking gurus, etc.). If you use > VANITYs, you move this function to a smallish number of vendors > (some hundreds rather than many thousands), where the assignment > process can be localized, focused, and probably largely automated. > You save countless man-hours. > > >- It may well turn out that higher-level protocols will end up defining > > higher-level IDs at a much finer grain than the EIDs that have been > > proposed in this community, for example, globally unique process IDs > > in support of fine-grain process migration. (See the VMTP protocol > > spec for one example of such an approach.) Such higher-level IDs > > are likely to make EIDs redundant. > > I think this is a wash. Probably a good way for an application to > manage such a number space is to take the network layer identifier > and append some additional information specific to that application. > If the network layer identifier is an address (i.e., combination > locator/identifier), then the address also is "redundant". Either way, > you are replicating some information. However, if you believe > VANITYs to be stable for longer than addresses, perhaps the use of > VANITYs to help manage the application EIDs is better than the > use of addresses. > > > >- In the most common case, where the locating semantics of either or both > ............ > > of changing addresses, or whatever), requiring the presence of pure > > EIDs would make the packet header significantly larger than it would > > otherwise be. True, the price we accept for our connectionless internet > > Agreed. > > > model is a large header on every packet. But I think we have a duty as > > designers to make relatively efficient use of that header space, since > > it is a "tax" imposed on every packet. I am particularly concerned > > I agree. If all other things are equal, we should favor smaller > headers.....but...... > > > about header size because I see increasing use of encapsulation as a > > multi-purpose mechanism in the Internet, such that many packets may > > end up carrying multiple SIPP headers on at least some part of their > > At least some of the reasons for such encapsulations would be eliminated > if we had VANITYs (for instance, the use of encapsulation for getting > mobility). > > > journey. I'm also concerned with making it possible to forward SIPP > > packets at very high speed, and keeping the basic header size relatively > > compact is one part of that (e.g., more likely to fit into a cache line, > > when using a general-purpose processor as a packet switch). > > Mumble. Maybe so. The use of VANITYs doesn't increase the amount > of info that has to be examined, though, so perhaps with some care > one can manage to funnel only the needed info into the cache line. > I don't know for sure, and it probably differs significantly from > machine to machine. Another point is that the VANITY might help > high speed switching because it can be used as a flow ID, blah blah > mumble hand wave. > > > A common answer to the large header size issue is to suggest using > > header compression over slow links. Besides the fact that that > > does not address the high-speed forwarding issue, another problem > > is that our current strategy for header compression in IPv4 only works > > for TCP traffic and relies on certain properties of TCP. However, I > > expect much of the high-volume traffic in the future to be UDP, e.g., > > What? High volume over slow links? If you can solve that one you > can become a rich man! :-) > > If it is high volume (and therefore high speed), you by definition > don't need header compression. > > > real-time audio and video. I don't know what's involved in building > > a robust header compression scheme for SIPP/UDP headers (there's a > > good project for someone to work on!), but I'd rather not depend on > > I agree. In fact, SIPP could use this like yesterday.... > > > it being easy or cheap to do. Another, perhaps unfounded, concern is > > that compression spends CPU cycles to save bandwidth, but we may want > > to support nodes that are starved for *both* CPU and bandwidth, e.g., > > very low-powered wireless devices. > > I suspect that a machine that is starved for CPU and bandwith will > not be exchanging packets simultaneously with a large number of other > devices, and therefore compression should work well at low cost > (i.e., lots of redundancy from packet to packet). > > > Ok, finally I want to address Christian's comments (and Minshall has > also mentioned this) about the non-uniqueness of IEEE 802 numbers. > I agree that this is a problem, but I wonder how much. In the > context of SIPP, the spec is very specific about requiring the use > of "universally administered" 802 numbers. Thus, I *hope* that > the "soft" assignments of 802 numbers doesn't apply. As for sloppy > practice by vendors resulting in duplicate "universally administered" > 802 numbers, at least with SIPP this should rarely cause a real > problem (unless I'm missing something). *If* we get SIPP hosts to > *always* assign a different flow ID for each route sequence it is > using, then duplicate 802 numbers only cause a problem when > 1) the hosts with the duplicates are talking to the same machine, > 2) the flow IDs are the same, and 3) the other identifiers, such > as transport socket, are all the same. I think that the probability > of this is small enough that failures caused for this reason will > be in the noise compared to failures caused for other reasons. > > /* start aside */ > > As an aside, this is *yet another* good reason to have > hosts always assign a flow ID. I'm now thoroughly > convinced that the cost of doing this is well worth it. > Off the top of my head, the benefits are: > > 1. Hosts receiving packets can use the flow ID to > detect a change in route sequence. Thus, they > don't have to parse through the route sequence > every time. > > 2. Routers can use the flow ID to identify flows. > My gut feeling is that 90% or more of real time > could be handled without explicit flow setup. > > 3. If not 2, then at least routers can use it to > aid their caching strategies (I know that there > are other issues here, like how to advance ther > route header). > > 4. "Fixes" the blatant distant-snooping security hole > introduced by route sequence reversal. (Sorry Ran, > but having thought about this more, I remain > convinced that this technique is useful for this > purpose.) > > 5. The duplicate VANITY problem. > > /* end aside */ > > > Actually, this notion that a host can successfully talk to > multiple other hosts that have the same VANITY is interesting > to me (not that I'm advocating it). Specifically, it makes > me ask what the point is to IP header authentications, especially > in the absense of higher-layer authentication. As long as > packets can successfully get from source to dest and back, what > does the network layer care about authentication? The application > cares about authentication, but authenticating the network layer > for the purpose of authenticating the application seems weak > and more expensive than doing it at the application. > > Maybe I'm just being dense, but can someone please re-iterate > for me why we need to authenticate at the network layer? > > PF > > From francis@cactus.slab.ntt.jp Mon May 16 09:44:58 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id UAA11243 for ; Sun, 15 May 1994 20:45:02 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 09:44:59 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA04620; Mon, 16 May 1994 09:44:59 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15601; Mon, 16 May 94 09:44:58 JST Date: Mon, 16 May 94 09:44:58 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160044.AA15601@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil Subject: concern over retreat..... I am becoming increasingly concerned (upset actually) about the participation of non-directorate member invitees at the meeting. I was initially under the impression that they would be coming only as "experts", and thus (I assumed) their input would naturally be limited to what they are experts on--primarily the documents that they authored. It seems to me, however, that they are being expected to participate practically as full-fledged members of the Directorate. I think there was a message at one point that they would be expected to be familier with the various proposals and white papers. I am also familier with one case where an invited person was asked to give presentations on existing protocols (IPX, Appletalk) that he is not generally familier with. I have so far been impressed with the generally non-partisan participation of the members. I was looking forward to more of the same in Chicago. In addition, I think that the current group has managed to develop something of a rapport. Now, however, I am losing faith that we can have anything other than a "my-protocol-is-better-than-yours" show-down. My inclination at this point is to un-invite all of the invited experts except perhaps one TUBA expert. I agree that TUBA is under-represented compared to SIPP, since SIPP has both Steve and I, and TUBA has only Mark (as far as I know....I don't have a list of the membership, but I can't think of another TUBA principal on the Directorate....in any event, I remember Mark saying that he felt TUBA was under-represented, so......). However, it is unfair to the invitees that they be un-invited now, so perhaps that is not an option. My second inclination then is to have the experts stay in another room during the meeting, and be called upon only for the portions of the meeting that concern their particular expertise. This would require that they state the expertise they represent before they come, and they be limited to that. Perhaps it is impossible to keep them in another room (it is kind of a strange thing to do), but I think they must somehow be limited in their discourse to the specific expertise that they represent. Comments? PF From francis@cactus.slab.ntt.jp Mon May 16 10:03:22 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA11295 for ; Sun, 15 May 1994 21:05:17 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 10:03:23 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA04877; Mon, 16 May 1994 10:03:23 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15986; Mon, 16 May 94 10:03:22 JST Date: Mon, 16 May 94 10:03:22 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160103.AA15986@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > You are assuming the solution in the above "requirement", > that is, you are assuming a "location independant identifier". > > No, that's not the solution, its a requirement - the reason is > that I don't believe that location dependant identifiers can > be allocated in an effecient enough manner that we can > reasonably allocated a fixed width field of any reasonable > size that we can really be sure is going to last forever. Ok, then add the requirement that said identifier must be less than or equal to whatever number you find appropriate, say 64 bits? Well, even that is specifying a solution. A real requiement would say something like "the identifier must be parsable by a current state of the art computer in xx micro-seconds). Blah. PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:03:22 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id AAA11862 for ; Mon, 16 May 1994 00:06:51 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA24770; Mon, 16 May 1994 13:21:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA24761; Mon, 16 May 1994 13:20:49 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25353; Mon, 16 May 1994 11:04:12 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 10:03:23 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA04877; Mon, 16 May 1994 10:03:23 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15986; Mon, 16 May 94 10:03:22 JST Date: Mon, 16 May 94 10:03:22 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160103.AA15986@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > You are assuming the solution in the above "requirement", > that is, you are assuming a "location independant identifier". > > No, that's not the solution, its a requirement - the reason is > that I don't believe that location dependant identifiers can > be allocated in an effecient enough manner that we can > reasonably allocated a fixed width field of any reasonable > size that we can really be sure is going to last forever. Ok, then add the requirement that said identifier must be less than or equal to whatever number you find appropriate, say 64 bits? Well, even that is specifying a solution. A real requiement would say something like "the identifier must be parsable by a current state of the art computer in xx micro-seconds). Blah. PF From sob@hsdndev.harvard.edu Mon May 16 07:00:12 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA12849 for ; Mon, 16 May 1994 07:00:19 -0400 Date: Mon, 16 May 94 07:00:12 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405161100.AA19484@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: poke We have not yet received proposal reviews from most of you. Since we need to have these reviews to finalize the detailed agenda for the retreat, we would like it if you could get the reviews to us asap. Scott & Allison From craig@aland.bbn.com Mon May 16 09:20:29 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA14719 for ; Mon, 16 May 1994 12:22:38 -0400 Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14129 for ipng@cmf.nrl.navy.mil; Mon, 16 May 94 12:22:27 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA06706; Mon, 16 May 1994 09:20:30 -0700 Message-Id: <199405161620.JAA06706@aland.bbn.com> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: ipng@cmf.nrl.navy.mil Subject: Re: concern over retreat..... In-Reply-To: Your message of Mon, 16 May 94 09:44:58 +0200. <9405160044.AA15601@cactus.slab.ntt.jp> From: Craig Partridge Date: Mon, 16 May 94 09:20:29 -0700 Sender: craig@aland.bbn.com Paul: I seem to be a quasi-IPng directorate member by virtue of working on the requirements document but I'm not going to be in Chicago (so I may have some tiny objectivity). You raise a good point. When I was on the IETF Nominating Committee in 1993, we eventually adopted a practice of holding some meetings which excluded the ex-officio members -- in part because of situations where ex-officio members would start saying that they didn't like the nom com's decisions and wouldn't support them in public. (We had some reaction that if one wasn't willing to be on the firing line, even for the parts one didn't like, one should be in the meeting making decisions). My point is largely that if you expect the Chicago meeting to go over difficult topics, your additional members may harm group decision making (in part, because they don't identify with the group). Craig From brian@dxcoms.cern.ch Mon May 16 18:32:20 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA14809 for ; Mon, 16 May 1994 12:32:55 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29409; Mon, 16 May 1994 18:32:21 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05001; Mon, 16 May 1994 18:32:20 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405161632.AA05001@dxcoms.cern.ch> Subject: Re: concern over retreat..... To: ipng@cmf.nrl.navy.mil Date: Mon, 16 May 1994 18:32:20 +0200 (MET DST) In-Reply-To: <199405161620.JAA06706@aland.bbn.com> from "Craig Partridge" at May 16, 94 09:20:29 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 456 I think it is essential that at least one session this week is IPng Directorate members ONLY where people can really say what they think. It might even be best to ask the proposal chairs to withdraw from that session. If there is no such session, the results will be suspect. Wish I could be there with you to thump on the table about this. Brian (totally zonked by the big-i list: we need to stop going over the same ground every four months or so.) From bound@zk3.dec.com Tue May 17 00:37:30 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA19133 for ; Tue, 17 May 1994 00:40:11 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA20165; Mon, 16 May 94 21:37:38 -0700 Received: by xirtlu.zk3.dec.com; id AA05382; Tue, 17 May 1994 00:37:36 -0400 Message-Id: <9405170437.AA05382@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Regrets on the Retreat Date: Tue, 17 May 94 00:37:30 -0400 X-Mts: smtp Fellow Directorate, Unfortuneately due to business and personal reasons I cannot travel to the retreat at this time. I spoke with both Allison and Scott. I can be available for teleconference as its possible. Sincerely, /jim From francis@cactus.slab.ntt.jp Tue May 17 10:24:12 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA18340 for ; Mon, 16 May 1994 21:24:22 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 17 May 1994 10:24:13 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA26518; Tue, 17 May 1994 10:24:13 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA28968; Tue, 17 May 94 10:24:12 JST Date: Tue, 17 May 94 10:24:12 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405170124.AA28968@cactus.slab.ntt.jp> To: brian@dxcoms.cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: concern over retreat..... > > I think it is essential that at least one session this week > is IPng Directorate members ONLY where people can really say > what they think. It might even be best to ask the proposal I think perhaps the first agenda item should be how to deal with the invited guests--and that this item should be discussed without invited guests present. > chairs to withdraw from that session. If there is no such > session, the results will be suspect. Wish I could be there > with you to thump on the table about this. > This is a reasonable idea. Much as I'd like to, and try, I don't think I can ever completely take my SIPP hat off.... >From my so-far-limited-experience, the trans-pacific jet lag hits hard at about 2:00 PM, so even if I don't leave the room, any discussion that takes place at that time may in effect be in my absense..... :-) PF From Greg_Minshall@Novell.COM Tue May 17 14:58:38 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA26153 for ; Tue, 17 May 1994 18:03:11 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18636; Tue, 17 May 94 16:06:13 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:38 PDT Date: Tue, 17 May 94 14:58:38 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: IPng Architecure and an IPng Architect Cc: ipng@cmf.nrl.navy.mil Jon, >I believe we have all the pieces of an architecture, but perhaps i >have perceived them as a whole, where maybe i'm either wrong, or else >that perception is hard when yo uare closer to the IETF than me. I think we have pieces, some more mature, some less mature. But, i don't think we have a consistent vision (at least, with reference to Steve D's musings, more than the vision of IPv4). >Personally, I belive dual stack is unacceptable for financial reasons, >unless someone can show me why interworking is more expesnive, and >given our expierence of interworking colouirred book, ISO and IPv4, i >doubt they will. All proposals are, to me, ultimately dual stack. SIPP has the transport and even the application wondering "is it real, or is it IPv4?". Greg From Greg_Minshall@Novell.COM Tue May 17 14:58:38 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA26153 for ; Tue, 17 May 1994 18:03:11 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18636; Tue, 17 May 94 16:06:13 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:38 PDT Date: Tue, 17 May 94 14:58:38 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: IPng Architecure and an IPng Architect Cc: ipng@cmf.nrl.navy.mil Status: O Jon, >I believe we have all the pieces of an architecture, but perhaps i >have perceived them as a whole, where maybe i'm either wrong, or else >that perception is hard when yo uare closer to the IETF than me. I think we have pieces, some more mature, some less mature. But, i don't think we have a consistent vision (at least, with reference to Steve D's musings, more than the vision of IPv4). >Personally, I belive dual stack is unacceptable for financial reasons, >unless someone can show me why interworking is more expesnive, and >given our expierence of interworking colouirred book, ISO and IPv4, i >doubt they will. All proposals are, to me, ultimately dual stack. SIPP has the transport and even the application wondering "is it real, or is it IPv4?". Greg From bound@zk3.dec.com Wed May 18 10:34:57 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA00366 for ; Wed, 18 May 1994 10:47:03 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA15118; Wed, 18 May 94 07:35:07 -0700 Received: by xirtlu.zk3.dec.com; id AA08096; Wed, 18 May 1994 10:35:03 -0400 Message-Id: <9405181435.AA08096@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IEEE Addresses as Unique from SIPP List Date: Wed, 18 May 94 10:34:57 -0400 X-Mts: smtp If your not on the SIPP list this just got sent out. We need to be careful if we assume IEEE 802 MAC anything. This corresponds with my intelligence on this subject too. /jim ------- Forwarded Message Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA03898; Wed, 18 May 1994 10:27:13 -0400 Received: from murtoa.cs.mu.OZ.AU by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16557; Wed, 18 May 1994 10:27:05 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA02522; Wed, 18 May 1994 23:44:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA02513; Wed, 18 May 1994 23:35:47 +1000 Received: from xap.xyplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26382; Thu, 19 May 1994 00:04:06 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Wed, 18 May 94 09:49:01 -0500 Received: by xyplex.com (4.1/SMI-4.1) id AA22825; Wed, 18 May 94 10:05:32 EDT Date: Wed, 18 May 94 10:05:32 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9405181405.AA22825@xyplex.com> To: big-internet@munnari.OZ.AU In-Reply-To: Greg Minshall's message of Tue, 17 May 94 14:12:35 PDT <9405172112.AA06513@WC.Novell.COM> Subject: IEEE 802 not unique enough??? Sad to say, IEEE 802 addresses, even if obtained from an "official" source, can't be considered "globally" unique if the possibility exists that an organization's network may be attached in multiple places to the external network. The current practice of some vendors is to use the same 802 address on each interface of multi-interface devices, on the theory that they are attached to "different networks" and therefore isolated. If these networks should find themselves attached to the same external realm, the duplicated addresses may both be visible to an external observer. This is of course a common issue with DECnet routers, which use the same "locally administered" address on each interface. Lately, I've heard of devices that do the same thing but with "globally administered" (i.e. second bit cleared) 802 addresses. A similar condition may occur during flooding with any MAC-layer bridge. It will propagate all the MAC addresses from "over there" to appear to be "over here". This is good, unless (again) there is some observer that can see both networks at the same time. So, how many added bits are need to make 802 addresses acceptable? What implementation rules are necessary to insure that they remain unique? (In other words, how do we define "unique"?) Can we set up the necessary (probably hierachical) prefix assignment mechanism without setting ourselves up for another round of "running out of addresses" in the future? By the way, I understand from some folks that are IEEE regulars that they have a defacto prohibition on any scheme that requires the creation and management of ANOTHER set of globally unique numbers; one is enough trouble to manage for them, I guess... Milan J. Merhar, Xyplex, Inc. 295 Foster St. Littleton, MA 01460 USA Internet: milan@xyplex.com Phone:(508)952-4713 Fax:(508)952-4887 ------- End of Forwarded Message From sob@hsdndev.harvard.edu Thu May 19 08:15:55 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA05672 for ; Thu, 19 May 1994 08:16:09 -0400 Date: Thu, 19 May 94 08:15:55 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405191215.AA22031@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: nsap paper >From skh@merit.edu Thu May 19 01:41:38 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA03972; Thu, 19 May 1994 01:44:17 -0400 Received: (skh@localhost) by merit.edu (8.6.8.1/merit-1.0) id BAA15175; Thu, 19 May 1994 01:40:45 -0400 Date: Thu, 19 May 1994 01:40:45 -0400 From: Susan Hares Message-Id: <199405190540.BAA15175@merit.edu> To: sob@harvard.edu Subject: NSAP paper for Retreat Cc: peter@goshawk.lanl.gov, skh@merit.edu, yakov@watson.ibm.com Status: R Scott: Yakov and Peter assure me that you'd like to have more information on NSAPs. I've written up this RFC for FYI track for Tuba area. It will be posted after a few more days of review. Please consider it still a very rough draft. However, it seems timely for your retreat. I also owe Allison at least one paper due to our last discussion at IETF. I stayed up late to finish it, but I'm called home to a sick child. Allison will chuckle. If this is too informal, oh well.. some of us you just can't train at all. My best wishes to you-all, Sue Hares ---- Network Working Group Susan Hares Request for Comments: DRAFT Merit/NSFNET May 1994 NSAP Usage Status of this memo This memo provides information on the benefits of ISO NSAP (Network Server Access Point) address as part of the IP Next Generation protocol. The purpose of this document is informational, and will be guided along the Information RFC track. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." 1. Overview Network Service Access Points (NSAPs) [1] provide an existing network address space with distributed address administration that provides substantial technical benefits. This memo describes the technical benefits, and provides an overview of the distributed administration of the this addresses. For an IP Next Generation addresses to aid the growth of the Internet, the address space must be easy to administer. Two types of administration will aid the Internet: - easy administration for local, special or limited area networks, and - a continuation of the fine work the Internet Address Naming and Authority (IANA) and Routing Registration Authorities to assign and administer network address assignments. The NSAP address space administration allows both types of administration of assignment of addresses. In addition to assignment addresses, those networks attaching to the Public Internet should be easy to add to routing registrations that aid network operations. The RIPE document "CLNS routing-domain object for the RIPE database" [2] provides an example of one approach that type of registration that uses NSAP addresses. Since ISO routing policy, address assignment, and route aggregation is analogous to Classless Inter- Domain Routing (CIDR) [3] [4][5], the RIPE CLNS document aligns the ISO information kept with the IP CIDR information. The benefit of this approach is that tools developed for use with the RIPE registry for IP CIDR routes may be used ISO CLNS routes. This easy migration path to Tuba IP next generation solution eases some operational issues regarding transition to the IP next generation solution. 2. Technical benefits of NSAP address NSAP addresses provide: 1) Mechanism embed a Unique System ID while still allowing Routing by shortest prefix 2) Easily obtainable local area NSAP addresses 3) Embedded subnet Addresses 4) Routing by Prefixes The Internet can obtain a large address space from ISO and assign and administer space. The NSAP address administration philosophy is to distribute the administration of the addresses. The IANA (Internet Address Naming Authority) and it's distributed European, US or Asian Routing Registration authorities could continue the mechanism for assignment of NSAP addresses as they do for IP version 4 addresses. Today the IANA delegates blocks of addresses to regional authorities such as Europe or Asian groups for assignment. As the Internet grows, it may be in the best interest of the Internet to further distribute the registration of routing addresses and information. This distribution of assignment is in the best philosophy of both the ISO addressing authorities and the IANA. Perhaps this is philosophy is common because it is the only workable plan to handle growth and to encourage up to date and accurate information that will be used. 2.1 Mechanism embed a Unique System ID while still allowing Routing by shortest prefix In the list of IP next generation desires is the desire for a unique system ID per machine. This unique system ID would be attached to each box and allow a machine to be uniquely identified. This unique identification (with no topological significance) may have many uses, such as auto-configuration of addresses or identification in mobile addressing schemes. While it is possible to have autoconfiguration schemes without unique IDs, the autoconfiguration schemes without unique ID involve either extra boxes (to hand out addresses), or involve reuse of addresses (like Appletalk). Since addresses are likely to be cached, reuse of addresses can create confusion with misdelivered packets. Whether this unique system id be 6 bytes or 8 bytes or 10 bytes, or some other length the NSAP address can encompass these systems IDs, and allow additional fields to use as network prefixes. Network prefixes, are defined in this paper to mean those bits in an address that allow the system to be associated with a network. In the CIDR world, this might be 128.2.1/24 prefix (128.2.1 prefix 24 bits in length.) With NSAP addresses this might be 39.840f.80ff.ff00/40 (length of 40 bits). [For explanation on the NSAP dot address format, see reference [6].] The network prefix portion of the NSAP address that comes before these system ID bytes allows the address to be part of larger address plan. Careful assignment of these network prefixes allows for the aggregation of network addresses reachable via a Network Service provider such as NEARNet or in a portion of the world such as Japan or Europe. For example, combining all 193.x.x.x address into one aggregation would greatly reduce routing tables. The aggregation reduces the necessary routing information that a router must hold, or routing protocols must pass. In the ISO 8348/Addendum 2 [1] includes the following addressing plans to choose address formats from: X.121 - 14 digits circuits ISO DCC - country code base F.69 - Telex numbers E.163 - Public Switched Telephone network numbers E.164 - ISDN number of up to 15 digits ISO ICD - International Code Designator Local - Locally defined Address formats. Evident from this list is fact ISO has registered addressing authorities for address formats with different level of technology across the span of many years. To assign to IP Version 7 as another addressing plan, would fit naturally into the ISO philosophy. In addition, the NSAP plans assigns address space for those who want local or private networks. Two of these addressing formats, ISO DCC or Country and ISO ICD used in the early internet CLNS experiments. These two formats have similar 20 octet formats which provides one method of assignment to encourage address assignment that will benefit from aggregation. Examples of these two 20 byte octets are included below, but should be viewed as just a first "guess" at how to do address assignment so we can aggregate large blocks of address. With the advent of CIDR in the Internet, the bright minds that keep our Internet functioning will probably figure out a better way to handle address assignment. A possible IP version 7 NSAP assignment is provided. This example is not the author's or anyone's favorite, it just provides an example of the flexibility of NSAPs. The final examples shows a simple private NSAP network that will never be attached to the public internet with several internal subnet networks. =================================================================== | bytes | | 1 | 2-3 | 4 | 5-7 | 8-9 | 10-11 |12-13| 14-19 | 20 | ------------------------------------------------------------------- | DCC code -ANSI US | |AFI| CC | ver | AAI | resv | RD |Area | System id |Selector| |39 | 840f | 80 |F8000 | 0000 | 0001 |0001 |010203040506|tcp port| ------------------------------------------------------------------- | ICD code - GOSIP | |AFI| ID | ver | AAI | resv | RD |Area | System id |Selector| |47 |0005 | 80 |F8000 | 0000 | 0001 |0001 |010203040506|tcp port| =================================================================== | AFI Internet (One possible V7 assignment < 20 | | bytes | | 1 | 2 | 3 | 5-7 | 8-9 |10-15 | | |AFI| ver |IANA| AAI | RD | System id |Selector| |33 | 80 | 01 |F8000 | 0001 |010203040506|tcp port| ==================================================== | private network - | | bytes | | 1 | 2 | 3-8 | 9 | |AFI | net | system id |tcp port| | 49 | 01 | 010203040506 | 01 | ==================================== 2.2) Ease getting pre-assigned NSAP addresses without Registration To encourage Internet growth, it has to be easy to get a block of addresses that will be guaranteed to be unique. With NSAPs, there are many methods of obtaining addresses, some of which do not involve having to ask anyone for addresses for local or private networks. The example above with the "LOCAL" AFI allows a user to define what ever he wants within the network. Any of the public addressing plans can be used, such an X.121 address, or the E.163 or E.164. With AFI values can be assigned for IPX or IPv4, so that anyone with a current address of that form automatically can have an NSAP address. And addresses are long enough for new hierarchical address assigning schemes, such as the GOSIP scheme. Routing doesn't care how many schemes there are or how addresses have been handed out -- routing just treats it like a pile of bits and routes to the longest matching address prefix. A new AFI value could be assigned for the Internet's New Generation. Address under this AFI could use the IANA procedures to assign and register the new addresses. Multicast addresses assignments proposed in ISO, are also distributed in the same manner unicast are distributed. One of the AFIs, means Multi-cast "local " which is can only be used in a private network. So, multi-cast and a unicast address can be assigned for private networks without address administration. 2.3) Embedded subnet Addresses Some topologies consist of routing across large clouds such as ATM or X.25. ATM claims to use NSAPs, but in reality the large public ATM nets will route based on E.164 (telephone numbers). In clouds such as these, it is possible to get routing across these clouds for "free" -- no configuration and no routing messages. The E.164 addresses Address space is defined as: =================================================================== | bytes | | 1 | 2 - 8 | 9 -15 | 16 | ------------------------------------------------------------------- | E.164 | |AFI| IDP | private network assignment | |45 | 91 13 19 36 33 00 00 | 0000 0001 0001 01 | tcp port | ------------------------------------------------------------------- Simply use the point of attachment of the cloud as Inter-Domain- Portion (IDP) of an E.164 address, which we'll call again the "network prefix", and assign the rest of the address as convenient within the private net hanging off the large cloud. It is not necessary for every address to have this form in order to get the benefit. If some portion of addresses can be assigned this way, it offloads the routing protocol and the system administrators by that much. 2.4) Routing by Prefixes ISO Routing is to the longest matching address prefix. CIDR routing also uses the match of the longest matching addresses prefix. NSAP prefixes simply carry on in a larger space the basic concepts of CIDR. It is desirable, whatever way addresses are handed out, that there be good summarization of addresses possible. All the current schemes for assigning network prefixes will result in addresses that match the topology pretty well. After CIDR, the network operators will be used to setting up routing plans on the basis of longest matching prefix addresses. Growing into NSAP space will follow naturally after the CIDR work. 3.) Distributed Administration of NSAP addresses Two types of administration will aid the Internet: a) easy administration of private or local networks, b) A continuation of the fine work the Internet Address Naming and Authority and NIC (IANA). The NSAP address space administration allows both types of administration ISO has delegated large portions of the NSAP Address space to other authorities such as the Internet. The Internet could obtain a set(s) of network address space to administer from ISO. Once assigning a block to the Internet, ISO has no more interaction so the IANA could operate as usual. Local or private numbers provide a basis for one part of the ISO space. This is an example of a "no-administration" for assignment of NSAPs. As long as you don't connect to the rest of the internet, you can start with the "local" AFI and define you own NSAP. Users of existing ISO address NSAP space may want to register for Internet routing by Internet-Routing Registration authorities. One benefit of the NSAP addresses are that the registration authorities can expand the current CIDR architecture to include NSAP addresses. Current work in RIPE on what information to keep in CLNS routing register has produced the following draft RIPE document, "CLNS routing-domain object for the RIPE database" by Sue Hares and Hank Steenman. Registration of routing for CIDR requires registration of: 1) Network prefixes - such as 128.2.0/10 (/10 = bit length 10) 2) aggregates and aggregation policy, 3) assignment of Autonomous System for Routing Domains 4) routing policy The registration of NSAP addresses requires the exact type of information: 1) Network prefixes - such as 39.840F/24 (bit length 24) 2) aggregates and aggregation policy, 3) assignment of Routing Domain Identifiers for Routing Domains 4) routing policy The benefits of using NSAP mechanism is that tools build to query or debug the CIDR network can be grown into NSAP tools because the basic databases are extremely similar. 4. Acknowledgements The author wishes to thank Yakov Rekhter(IBM) and Peter Ford (Los Almos Labs) for their "encouragement" to write this information RFC, and for their early review of the document. However, all heretical ideas and comments can be only blamed on my pre-occupation the pragmatism of doing what it takes to get networks working. My thanks to Allison Malkin for our discussion at the Seattle IETF that reminded me why I started to drain the ISO swamp. 5. References [1] ISO 8473/Addendum 2 - Information Processing Systems - Data Communications - Protocol for Providing the Connectionless-mode Network Service, 1988. [2] "CLNS routing-domain object for the RIPE database, version 3.b - RIPE working draft Sue Hares and Hank Steenman [3] Fuller, V., Li, T., Yu, J, and Varadhan, K., "Class-Less Inter- Domain Routing: an Address Assignment and Aggregation Strategy", RFC1519, September 1993 [4] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with CIDR", RFC1518, September 1993 [5] Rekhter, Y. "Exchanging Routing Information Across Provider Boundaries in CIDR Environment" [6] Hares, S., Wittbrodt, C., "Essential Tools for the OSI Internet" Authors' Addresses Susan Hares Merit, Inc 1071 Beal Avenue Ann Arbor, MI 4810x Phone: (313) 936-2095 Email: skh@merit.edu From bound@zk3.dec.com Sat May 21 00:04:21 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA16696 for ; Sat, 21 May 1994 00:10:48 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA05680; Fri, 20 May 94 21:05:48 -0700 Received: by xirtlu.zk3.dec.com; id AA19570; Sat, 21 May 1994 00:04:27 -0400 Message-Id: <9405210404.AA19570@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Bob Moskowitz (Chrysler) thoughts today on IPng Date: Sat, 21 May 94 00:04:21 -0400 X-Mts: smtp ------- Forwarded Message Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Apr94-1041AM) id AA17413; Fri, 20 May 1994 07:51:46 -0400 Received: from murtoa.cs.mu.OZ.AU by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA06698; Fri, 20 May 1994 07:51:41 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA03526; Fri, 20 May 1994 21:10:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03499; Fri, 20 May 1994 20:56:57 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06172; Fri, 20 May 1994 21:25:18 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA00957; Fri, 20 May 94 06:25:58 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ar05319; 20 May 94 11:15 GMT Date: Fri, 20 May 94 06:21 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Noel Chiappa To: big internet Subject: Re: Thoughts on the IPng situation... Message-Id: <20940520112102/0003858921NA2EM@mcimail.com> >At that point, whether you pick TUBA or SIPP or whatever is more of a >political statement, than a technical one. :-( For the most part, I am too busy making TCP/IP happen at Chrysler in a BIG way to participate in these conversations. But.... There is one VERY big criteria for us corporate folks that will drive us to an IPng, given a business need. That is the DOS/Windows migration plan. Forget your UNIX work, it does not represent a significant number of install machines in the corporate world (yes I help set Chrysler Finance up with 3,000+ NeXtstep systems). Now all too many DOS/Windows systems are already running dual stack, IP and IPX. It might actually happen later this year that Novell will really get NWIP to the point that it can be used large scale, but my colleagues that do IPX are not holding their breath. This tends to lead me, personally, to be very much concerned about a dual stack transition. I want to REPLACE the IP kernel in DOS with an IPng kernel. Yes I have worked with DLL implementations and found them lacking. Perhaps we will soon have VxD implementations, but that is VERY hard and I would doubt if an IPng would do that out the door. The next big criteria is address migration. I would want a clean port of my IP addresses to IPng addresses. In the past year, the corporate side of our network (still waiting on numbers from engineering) went from 3,000 IP interfaces to 8,800 interfaces (according to our HP OpenView). Dreaming up a new addressing scheme is not all that much fun. As it is we are fighting a DNS/X.500/NDS naming fight... So from where I stand today (and granted I have only scanned the drafts), SIPP looks good to me and I would recommend it to my colleagues. But then if I am shown how easy the same items are with TUBA or CATNIP, or TURNIPP, I could end up needing to reconsider. My voice carries some weight here. But this is not Chrysler's position, yet. Bob Moskowitz Chrysler Corp ------- End of Forwarded Message From bound@zk3.dec.com Sat May 21 01:42:12 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA16945 for ; Sat, 21 May 1994 01:45:33 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA08462; Fri, 20 May 94 22:43:20 -0700 Received: by xirtlu.zk3.dec.com; id AA20660; Sat, 21 May 1994 01:42:18 -0400 Message-Id: <9405210542.AA20660@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: To-Do's A.S.A.P. IMHO Date: Sat, 21 May 94 01:42:12 -0400 X-Mts: smtp Address changes: Can someone put together real short the layout of the suggested address format so it can be analyzed in depth from an implementation perspective on a host and router, as a quick logic check. The other question is what do any address changes do to the existing routing protocols available to us for the Internet? Transition Requirements: I find that we still have to make transition lists annoying but OK. I am making a list too and I encourage others to do the same. But lets schedule a transition meeting very soon that looks at how do you do those requirements on the East Coast. I don't care where its hosted here but we need Bob Gilligan there not just for IPAE but because he has really looked at this too from an implementation perspective as I have. And don't tell me you can't look at this right now from an implementation perspective because you can, you just don't know what the Transition spec will be (on this I agree). But any good implementor has an idea of where the pain and engineering cost will be to build transition software for IPng, unless they are not keeping up with the pack, the discussions, and the TUBA and SIPP Transition specs. Be real. A great trick in the machavellian model of political science is to keep re-inventing the problem when you don't want someone to build a solution to the problem just yet. I won't go into several other tricks. They are not done on purpose, most often its a side affect of working in Corporate America (I don't have a clue about Europe or Asia or other cultures in this space). In addition both TUBA and SIPP did put requirements in their drafts of what they believed the requirements are and spent some thought on why these are requirements. We don't have to re-invent the wheel completely here folks. I would also like Yakov and Peter to be there. This meeting in my mind should not be an architecture meeting but an engineering meeting where we take the requirements and figure out 'how to' from a router and host perspective. Lets get the requirements done by June 1st? Then maybe we can go for meeting the week of June 6th. Do we need two days? A good thing to ask oneself when thinking about transition requirements is are they the same as customer assumptions. For example in the Bob Moskowitz mail I just sent he sounded awful close to saying that he does not want the headache of dual stacks and might just want IPng ONLY on his PC's. But others will say I do want dual stacks. The point is you need to make sure you cover the bases. As Ross said if its too complex then maybe we can't do it. But thats the part we need to analyze and not assume something is to complex without much technical thought from an implementation perspective. Also in the equation if a vendor can make a profit from doing something very complex should also be in the equation. This is an engineering perspective as opposed to a computer science perspective. BBN sounds like a good neutral place for the meeting if John can swing it? EIDs: We need a definition right? I am writing one right now. This is not rocket science. How about figuring this definition out by June 1st? If we get 8 definitions we can probably come up with one with a little work. And put this behind us and move on. I would be glad to assimilate them and produce common thoughts and where people don't see eye-to-eye at all. I still think Steve Deering gave us the different models for EIDs and we can just take SIPP out of the context and probably get a definition real quick. I think part of the test should be to ask Noel if he thinks we got it right. thanks /jim From lixia@parc.xerox.com Sat May 21 17:13:17 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18810 for ; Sat, 21 May 1994 20:14:11 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14630(6)>; Sat, 21 May 1994 17:13:30 PDT Received: by redwing.parc.xerox.com id <57153>; Sat, 21 May 1994 17:13:19 -0700 Date: Sat, 21 May 1994 17:13:17 PDT Sender: Lixia Zhang From: Lixia Zhang To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: To-Do's A.S.A.P. IMHO In-Reply-To: Your message of Fri, 20 May 1994 22:42:12 -0700 Message-ID: > Address changes: > > Can someone put together real short the layout of the suggested address > format so it can be analyzed in depth from an implementation perspective > on a host and router, as a quick logic check. If there is one I'd like to see it too since I left the meeting earlier (but I'm not sure there is one yet :-( > EIDs: > > We need a definition right? I am writing one right now. I'm not sure whether we need a new definition for EID or we just need an agreement with the definitions--different people seem to have different definitions. > This is not > rocket science. How about figuring this definition out by June 1st? > If we get 8 definitions we can probably come up with one with a little > work. And put this behind us and move on. I would be glad to > assimilate them and produce common thoughts and where people don't see > eye-to-eye at all. As an input to your collection: at one dinner several of us tried to list different EID definitions (Steve Deering took some notes so he can correct me): 1 an ID to identify an IP entity (e.g. the IP module running in a host). 2 an ID to identify a transport level entity. This one may or may not have one-to-one correspondence with (1). 3 a running instance of transport entity, e.g. one end of a TCP connection. 4 a process. I recall we listed 5. Steve, what's the 5th one? > I still think Steve Deering gave us the different > models for EIDs and we can just take SIPP out of the context and > probably get a definition real quick. ?? not sure what you were talking here. I see 3 steps in this EID exercise/the EID WG agenda: - an agreement on the definitions. Is the above list correct? - understand the requirements of each EID (e.g. as a transport entity, TCP probably desire a fixed size ID, and hopefully not too big. The life time may also be an issue) - based on the requirements, find ways to produce each of the EIDs. Personally I think IP(ng) has the responsibility for (1) in the above, i.e. have a UID to identify an IP entity to accomplish things like mobility. Whether transport protocols or others use this UID for their purpose is a decision of their own that the proposed EID WG should look into. Lixia From smb@research.att.com Sat May 21 20:47:44 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18899 for ; Sat, 21 May 1994 20:48:22 -0400 From: smb@research.att.com Message-Id: <199405220048.UAA18899@picard.cmf.nrl.navy.mil> Received: by gryphon; Sat May 21 20:47:45 EDT 1994 To: Lixia Zhang cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: To-Do's A.S.A.P. IMHO Date: Sat, 21 May 94 20:47:44 EDT 2 an ID to identify a transport level entity. This one may or may not have one-to-one correspondence with (1). 3 a running instance of transport entity, e.g. one end of a TCP connection. 4 a process. Let me repeat my suggestion of using a random 128-bit number, though with an answer to Lixia's objection. She pointed out, quite correctly, that hosts won't generate random numbers well unless told how to. Let me propose the following. Given that IPng hosts will (I hope) all have strong authentication, they'll need some cryptographic hash function H (i.e, something like MD5 or SHA). Let R0 = H(SysID || hostname || TOD) That's probably quite random, even with collisions in the SysID space. Let Ri+1 = H(Ri || TOD) I suggest including the TOD in the feedback loop so that if some collision ever occurs, it won't be propagated. From lixia@parc.xerox.com Sat May 21 17:51:50 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA18909 for ; Sat, 21 May 1994 20:52:42 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14622(7)>; Sat, 21 May 1994 17:52:03 PDT Received: by redwing.parc.xerox.com id <57153>; Sat, 21 May 1994 17:51:52 -0700 Date: Sat, 21 May 1994 17:51:50 PDT Sender: Lixia Zhang From: Lixia Zhang To: ipng@cmf.nrl.navy.mil Subject: some thought after the retreat Message-ID: I see the IPng retreat as a great success. I wish it had happened earlier. It's a success because it started the process of unifying all the effort towards building a single IPng. I second Jim's suggestion of scheduling a face-to-face meeting to reach an agreement on transitions soon since this issue did not get enough time at the retreat. I also feel the need for a face-to-face meeting on addressing and routing to nail down more details. I know nobody likes travel, but telechat just does not seem to do the job. Although a new IPng WG wont officially start until Toronto IETF, I hope the work would be well underway by then. Lixia From brian@dxcoms.cern.ch Sun May 22 14:39:44 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA20166 for ; Sun, 22 May 1994 08:40:18 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22148; Sun, 22 May 1994 14:39:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA06742; Sun, 22 May 1994 14:39:44 +0200 From: brian@dxcoms.cern.ch (Brian Carpent