From sob@hsdndev.harvard.edu Wed Dec 8 09:03:27 1993 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA11358 for ; Wed, 8 Dec 1993 09:03:36 -0500 Date: Wed, 8 Dec 93 09:03:27 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312081403.AA21004@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: please review asap here is another cut at the ale charter - we would like to get this back to the co-chairs for their review quite soon so can you please take a look at it sometime before tomorrow (Thursday) am EST? A few bits - the ongoing tasks can't be called non-periodic if they're monthly again. - should we ask ALE to consider trying to count the allocations of NSAPs for us by some means too? If we would like to broach this, it has to be done during this iteration. It could be useful. - What about changing the ALE name to Architecture Lifetime Expectations, perhaps if people get sticky about Address not including routing tables? Scott & Allison ------- Address Lifetime Expectations (ALE) WG Chair: Frank Solensky, FTP Software Tony Li, Cisco Systems IPng Area The primary purpose of the Address Lifetime Expectations Working Group is to develop an estimate for the remaining lifetime of the IPv4 address space based on currently known and available technologies. + This concerns both depletion of the address space and overflow + of routing tables. The members of the working group will consider whether more stringent address allocation and utilization policies might provide additional time and, x if so, recommend such policies. The working group will also investigate x whether it is worthwhile to mount a serious effort to reclaim addresses x and/or to renumber significant portions of the Internet. It will also x weigh the benefit of other potential options against their expected cost x and notify the responsible working groups or area directors of those x proposals the ALE group considers worthy of their further attention. + if so, recommend such policies. The working group will enumerate address + lifetime extension mechanisms. It will then evaluate these mechanisms + concerning their possible benefit against their expected cost. Any + mechanism which the ALE working group considers worthy of further + attention will be forwarded to the responsible working groups or area + directors for further evaluation. The working group will have several ongoing activities which will result in non-periodic reports to the IETF community and the IPng Area Directors. x One ongoing activity is to produce predictions of the address space + One ongoing activity is to produce monthly predictions of the address space exhaustion timeframe, + and the routing table overflow timeframe, assessing the accuracy of these predictions and the data on which they are based. The group will also project the impact of various policy compliance data and possible policy recommendations. Another ongoing activity is to monitor the perceived utilization of address space and identify sources of poor utilization, set address utilization goals and to itemize possible policies to improve utilization. The group will also monitor the number of routes present in the Internet backbones, and determine, in conjunction with the CIDR deployment WG, locate sources of poor aggregation within the network, and make necessary recommendations to insure continued operations. Milestones: November 1993 Coordinate with existing efforts in this area, for example, those of the IEPG and the CIDR Deployment BOF. Result is an allocations of tasks agreed among the efforts. April 1994 In cooperation with the BGP Deployment Working Group, produce a report on the status of address aggregation, including additional guidelines/strategies, if necessary. + Includes status of routing tables in the Internet. July 1994 Produce a report on the status of addess space utilization, including goals and guidelines for improving address space utilization. From bound@zk3.dec.com Wed Dec 8 12:22:18 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA13400 for ; Wed, 8 Dec 1993 12:29:38 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA14868; Wed, 8 Dec 93 09:22:27 -0800 Received: by xirtlu.zk3.dec.com; id AA08054; Wed, 8 Dec 1993 12:22:25 -0500 Message-Id: <9312081722.AA08054@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng proposal overviews In-Reply-To: Your message of "Tue, 07 Dec 93 10:24:14 +0100." <9312070924.AA27935@dxcoms.cern.ch> Date: Wed, 08 Dec 93 12:22:18 -0500 X-Mts: smtp Brian, This is a good list. I think we should add: Perceived Performance and Implementations Costs. /jim From bound@zk3.dec.com Wed Dec 8 12:56:23 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA13657 for ; Wed, 8 Dec 1993 13:09:53 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA16672; Wed, 8 Dec 93 09:56:31 -0800 Received: by xirtlu.zk3.dec.com; id AA08875; Wed, 8 Dec 1993 12:56:29 -0500 Message-Id: <9312081756.AA08875@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: please review asap In-Reply-To: Your message of "Wed, 08 Dec 93 09:03:27 EST." <9312081403.AA21004@hsdndev.harvard.edu> Date: Wed, 08 Dec 93 12:56:23 -0500 X-Mts: smtp Scott and Allison, I have no problem with the charter statements on my end. >- should we ask ALE to consider trying to > count the allocations of NSAPs for us by some means too? If we > would like to broach this, it has to be done during this iteration. > It could be useful. I think this would be useful too. But, I would like to see the process stated as to how they find the NSAPs allocated. The reason I ask is that one issue customers have had with OSI is that its not as portably (from a heterogenity perspective) administered as IP. For example each OSI vendor supplies their own incantation of name to address look up and the database constraints as opposed to the common BIND DNS for IP. Right now you can put Digital, Sun, HP, and IBM IP nodes on the network and coordinate name space via DNS. In addition ftp, rcp, telnet, snmp, traceroute, et al. are all the same user command lines for each supplier. >- What about changing the ALE name to Architecture Lifetime Expectations, > perhaps if people get sticky about Address not including routing tables? I don't think this is a good idea simply because prefixing the group with the word architecture takes away from what they are to deliver. In addition it extends their charter from addresses to architecture of a possible new protocol suite for the Internet. Not a good idea. /jim From bound@zk3.dec.com Thu Dec 9 22:52:40 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA26919 for ; Thu, 9 Dec 1993 22:55:26 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA14317; Thu, 9 Dec 93 19:52:50 -0800 Received: by xirtlu.zk3.dec.com; id AA18135; Thu, 9 Dec 1993 22:52:46 -0500 Message-Id: <9312100352.AA18135@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: External Review Board Date: Thu, 09 Dec 93 22:52:40 -0500 X-Mts: smtp In the WP announce we stated the Ext Rev Board would also review the papers. Probably a good idea if we get at least an initial selection of names so people know who the /etc/init players are for now. ???? /jim From ericf@atc.boeing.com Fri Dec 10 08:59:46 1993 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA29338 for ; Fri, 10 Dec 1993 11:58:15 -0500 Received: by atc.boeing.com (5.57) id AA05231; Fri, 10 Dec 93 08:59:46 -0800 Date: Fri, 10 Dec 93 08:59:46 -0800 From: Eric Fleischman Message-Id: <9312101659.AA05231@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, scoya@CNRI.Reston.VA.US Subject: Re: DRAFT minutes from December 6 teleconference Cc: ericf One aspect of the minutes which are not accurate is concerning Ross Callon's dusting off his paper on "hidden addresses". Actually, Ross' paper was just an outline with no meat on the bones yet. It's topic is *NOT* "hidden addresses" but rather the various known schemas for enhancing the life expectancy of IPv4. In this context Local Addresses are but one of the options -- the option which I believe is by far the most important and "workable" of the lot. I also wish to express my displeasure at the equation of DECnet Phase IV "hidden addresses" with the OSI "local addresses" which occurred within this telethon. The two are quite dissimilar. The problem in the DECnet case was that large end users (i.e., Boeing) simply ran out of 16 bit DECnet addresses within the corporate address space. Thus, a kludge was made whereby additional networks could be added within that space which were not (really) known to the corporation's backbone routers. It's been a long time since I dealt with this so I must confess that I no longer recall exactly how this kludge was done. In any case, this is not a schema which I support and thus the equation of this approach with local addresses is quite galling to me. OSI "local addresses" are quite different. A local address is an address space whose addresses are a priori defined to solely have meaning within a given domain (corporation). For this reason, entities with these addresses can not (by definition) use these addresses for communications outside of the corporation. This "security feature" has many very useful elements which are extremely attractive to industry. The fact that it also is an excellent way to achieve "address re-use" within an IPv4 context is an incidental but useful co-incidence to its primary security function. This approach differs from the DECnet approach in that the corporation's backbone routers are as knowledgable about these local addresses as they are about any of the other addresses used within that corporation. OSI local addresses are the default address structure of the TOP NetBIOS protocol. One last matter: the discussion also displayed a frightening lack of understanding as to why industry *MUST* maintain security islands until such a time as adequate security is attainable by other means. This is too important and too large a topic to be covered here now. While I am very cognizant as to the undesirable "down side" of this approach, the alternative is to go bankrupt as a business. This is not hyperbole. If anybody does not understand why this is so, please contact me privately. Sincerely yours, --Eric Fleischman From smb@research.att.com Fri Dec 10 12:10:13 1993 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.4/8.6.4) with SMTP id MAA29428 for ; Fri, 10 Dec 1993 12:12:12 -0500 From: smb@research.att.com Message-Id: <199312101712.MAA29428@picard.cmf.nrl.navy.mil> Received: by gryphon; Fri Dec 10 12:10:14 EST 1993 To: Eric Fleischman cc: ipng@cmf.nrl.navy.mil, scoya@CNRI.Reston.VA.US, ericf@picard.cmf.nrl.navy.mil Subject: Re: DRAFT minutes from December 6 teleconference Date: Fri, 10 Dec 93 12:10:13 EST One last matter: the discussion also displayed a frightening lack of understanding as to why industry *MUST* maintain security islands until such a time as adequate security is attainable by other means. This is too important and too large a topic to be covered here now. While I am very cognizant as to the undesirable "down side" of this approach, the alternative is to go bankrupt as a business. This is not hyperbole. If anybody does not understand why this is so, please contact me privately. Not that it's likely to surprise anyone here, but I agree 100%. Given the abysmal state of host security -- which is bad software engineering, bad administration, old versions, bad passwords, ad infinitum -- there is no alternative to firewalls. From scoya@CNRI.Reston.VA.US Fri Dec 10 12:13:33 1993 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA29441 for ; Fri, 10 Dec 1993 12:14:38 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05898; 10 Dec 93 12:13 EST To: Eric Fleischman cc: ipng@cmf.nrl.navy.mil Subject: Re: DRAFT minutes from December 6 teleconference In-reply-to: Your message of "Fri, 10 Dec 93 08:59:46 PST." <9312101659.AA05231@atc.boeing.com> Date: Fri, 10 Dec 93 12:13:33 -0500 From: Steve Coya Message-ID: <9312101213.aa05898@IETF.CNRI.Reston.VA.US> Eric, >> One aspect of the minutes which are not accurate is concerning Ross >> Callon's dusting off his paper on "hidden addresses". Actually, Ross' >> paper was just an outline with no meat on the bones yet. It's topic is >> *NOT* "hidden addresses" but rather the various known schemas for >> enhancing the life expectancy of IPv4. Are you requesting a change to the text of the minutes? The minutes currently read: Ross Callon is going to search for a paper he started on the use of hidden addresses and sent it to the IPNG list. Based on your comments, I could change (with IPNGDIR approval of course) to: Ross Callon is going to search for a paper/outline he started which included a section on hidden addresses and sent it to the IPNG list. Steve From bound@zk3.dec.com Fri Dec 10 13:20:47 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA00260 for ; Fri, 10 Dec 1993 13:48:53 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA21988; Fri, 10 Dec 93 10:20:57 -0800 Received: by xirtlu.zk3.dec.com; id AA17611; Fri, 10 Dec 1993 13:20:54 -0500 Message-Id: <9312101820.AA17611@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Re: DRAFT minutes from December 6 teleconference In-Reply-To: Your message of "Fri, 10 Dec 93 12:10:13 EST." <199312101712.MAA29428@picard.cmf.nrl.navy.mil> Date: Fri, 10 Dec 93 13:20:47 -0500 X-Mts: smtp ******************************* One last matter: the discussion also displayed a frightening lack of understanding as to why industry *MUST* maintain security islands until such a time as adequate security is attainable by other means. This is too important and too large a topic to be covered here now. While I am very cognizant as to the undesirable "down side" of this approach, the alternative is to go bankrupt as a business. This is not hyperbole. If anybody does not understand why this is so, please contact me privately. Not that it's likely to surprise anyone here, but I agree 100%. Given the abysmal state of host security -- which is bad software engineering, bad administration, old versions, bad passwords, ad infinitum -- there is no alternative to firewalls. ******************************** Yes firewalls in fact work. In fact you can set them up so that complete access outside of your site is restricted to that which is useful to the entities need to access the Internet. The trick is to also make the firewall work when you need to actually also access the Internet in your site as part of your day to day operations. Right now that could mean recursive firewalls. What this gives you is the ability today to have each of your nodes have actual global Intert address such as for Mail and still use that address in your site as your address for those purposes. Yes you can isolate the site with addresses that are not known outside of the site in most all protocol address architectures and this is the most secure. This will also be able to be done with any of the present IPng proposals simply by administration of that address space. I see the point of security and await people to respond as Steve with the expertise regarding protoocols in this process. But what I do not get is the issue of local addresses for security, because it seems self-evident to me that this is an option the market will have with any proposal. So what more can be said regarding using local addresses in IPng? Unless I am missing something then the market can go for it. /jim From rcallon@wellfleet.com Fri Dec 10 13:21:56 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA29907 for ; Fri, 10 Dec 1993 13:18:44 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17661; Fri, 10 Dec 93 13:05:50 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA24579; Fri, 10 Dec 93 13:14:12 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA03759; Fri, 10 Dec 93 13:21:56 EST Date: Fri, 10 Dec 93 13:21:56 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312101821.AA03759@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil, scoya@CNRI.Reston.VA.US Subject: Re: DRAFT minutes from December 6 teleconference 4. The ALE Working Group charter was reviewed. A question was raised as to whether the wg should also consider the routing table exhaustion problem as part of its charter, in addition to focusing on address space usage. Another topic was whether the ALE WG should be asked to evaluate IP address proposals. Ross Callon is going to search for a paper he started on the use of hidden addresses and sent it to the IPNG list. I would reword this to be: Ross Callon is going to search for a paper which he started on methods (beyond CIDR) for extending the lifetime of IP. This includes hidden addresses and some other methods. He will send a copy to the IPng list. From ericf@atc.boeing.com Fri Dec 10 10:26:45 1993 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA29937 for ; Fri, 10 Dec 1993 13:25:20 -0500 Received: by atc.boeing.com (5.57) id AA11162; Fri, 10 Dec 93 10:26:45 -0800 Date: Fri, 10 Dec 93 10:26:45 -0800 From: Eric Fleischman Message-Id: <9312101826.AA11162@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: please review asap Cc: ericf Concerning the New ALE Charter I just returned from a stint on Jury Duty. Thus I am rather behind on Email correspondence... Well, actually I'm now behind on everything. I note that responses on the revised ALE charter were due by Thursday -- and this is Friday. Here's my "very late" two-bits-worth anyway: I like how the new charter reads. Thank you for the changes. I approve of the current charter's name. Changing "Address" to "Architecture", I fear, would lead the group to broader topics than the specific topic of interest: extending IPv4's life span. I do not see any value in having the group follow NSAP allocations. The NSAP world is quite different from the Internet's IP addresses in that there are a great many addressing authorities and the addresses do not all stem from the "same root" as they do in IP. Thus, I do not understand why following NSAP allocations would be profitable even if we were critically interested in OSI -- unless, of course, we wanted to use the information for advocacy purposes. In any case, I am interested as to why our co-chairs believe that this would be a desirable function for the ALE group. In my mind, ALE's area of interest is solely IPv4 -- not IPng or other protocols. If I am wrong, then perhaps others are similarly confused about this matter and this should be specifically addressed in the ALE's charter. Thank you for this opportunity for feedback. Sincerely yours, --Eric Fleischman From Robert_Ullmann.LOTUS@CRD.lotus.com Fri Dec 10 14:36:22 1993 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA00473 for ; Fri, 10 Dec 1993 14:32:12 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA06041; Fri, 10 Dec 93 14:33:45 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA11648; Fri, 10 Dec 93 14:36:22 EST Date: Fri, 10 Dec 93 14:36:22 EST Message-Id: <9312101936.AA11648@Mail.Lotus.com> Received: by DniMail (v1.0); Fri Dec 10 14:36:20 1993 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: CATNIP document The CATNIP proposal is contained in a single document: world.std.com:pub/catnip/draft-ietf-tpix-catnip-00.ps (which hasn't been submitted to the I-D directories because of great difficulties producing a decent ASCII version.) From rcallon@wellfleet.com Fri Dec 10 16:43:18 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA01386 for ; Fri, 10 Dec 1993 16:40:19 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA19377; Fri, 10 Dec 93 16:27:12 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA28045; Fri, 10 Dec 93 16:35:34 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA03851; Fri, 10 Dec 93 16:43:18 EST Date: Fri, 10 Dec 93 16:43:18 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312102143.AA03851@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil Subject: Re: DRAFT minutes from December 6 teleconference Cc: rcallon@wellfleet.com One aspect of the minutes which are not accurate is concerning Ross Callon's dusting off his paper on "hidden addresses". Actually, Ross' paper was just an outline with no meat on the bones yet. It's topic is *NOT* "hidden addresses" but rather the various known schemas for enhancing the life expectancy of IPv4... Well, the best way to describe the detailed outline of the paper (I don't really have a completed paper), at least to the directorate, would seem to be to show you what is in it. The detailed outline is included below. I think that there are already two volunteers for "co-authorship" (Eric and Scott). I am about disappear into an ATM black hole for next week, and hope that Eric and Scott can turn this into a real paper. Ross --------------------------------------- Short Term Proposals to extend the Life of the IP address space Unlimited distribution Ross Callon June, 1993 1. Intro - issue - don't know when IPng will be agreed and ready - need to extend IP as long as possible - CIDR buys much time. However, other compatible methods can also be used in combination with CIDR to further extend the life of IP. - feel that features listed here (esp 1, 2. 3) can buy many years IF GROWTH CONTINUES AT CURRENT RATE - But, growth might accelerate. This implies that the suggestions given here, while important to extend life of IP, are not in any way a reason to slow down push for deployement of IPng - ACKNOWLEDGEMENT: These are not original ideas. Rather I am trying to catalogue ideas Hidden network suggested by and much like DECnet; extend CIDR to whole space suggested by Tony Li; recycle addresses discussed in ROAD group, provider based routing is an extension enhancement of idea related to IPAE proposal. Point is not to be original, but rather to get useful ideas into the field. [1] 2. Hidden Network Numbers (I think that Elise Gerich of Merit has proposed something very similar) - IANA announces that certain IP network numbers will never be assigned to a real network. These are announced as "intended for local use". - Guidelines for extending the life of the IP address space is defined, which tell people when to use these special network numbers as local addresses. - Sites that don't need Internet Access use these local addresss exclusively (do not use any globally unique addresses). - Sites that do need Internet access can also limit use of globally unique addresses: - Some systems don't need Internet access (printers, ...). These use the local addresses. - Some systems only need limited access which can be via relays (such as Email relays). These also use local addresses. - Clearly, any system which is administratively precluded from global internet access will use local addresses. - Other systems need global addresses. For example, workstations and PCs which are using an application which cannot conveniently go via application relays can use global addresses. Similarly, electronic mail relays must have global addresses. - If a physical subnet contains at least one system which requires a global address, plus at least one system which does not, then the subnet has two addresses assigned to it, one which is globally unique, and one which is for local use only. The globally meaningful subnet address should be chosen to be large enough to cover only those systems that require global IP access. I have heard that there is at least one case of a large US Corporation which has a class B IP network number, with only 13 hosts visible from outside of the corporation! (there are lots of other hosts on the network, but they are administratively prohibited from Internet access). Similarly, there are many sites which do not have Internet access at all, but have asked for and received globally meaningful IP addresses because they have been under the impression that this is the correct thing that they are expected to do. Thus there is clearly some situations in which we can save addresses by using local addressing. Note: One disadvantage of local addresses is that systems with local addresses might in principle in the future want access to the Internet, either for an existing application or for a new application. If such systems have local addresses, then when they need in the future to hook up to the Internet they will need to either have their IP address changed to be global, or be updated to understand IPng. Note that if they are being updated to a new application it might be desireable that they be updated to IPng at the same time in any case (some new applications might be defined to only run over IPng). 3. Extend CIDR to Entire IP Address space - currently CIDR just used for class C's (this also helps class B exhaustion) - This allows efficient use of Class B and Class C part of address space. Which buys time. Also helps with routing table size. - But: used part of Class A is less than 1/4 space unused part of class A is greater than 1/4 of space Class B is 1/4 of space Class C is 1/8 of space rest of 1/8 of space. Thus, by extending CIDR to class A we can gain at least 1/4 of space, which represents twice the space available with Class C. If we can reclaim part of underused class A space, then we gain still more. Also, we can make optimal use of Class B space. - This requires IGP and EGP to be classless. The original complaint about using CIDR with the class A space was based on some old routers (with old routing protocols such as the old version of RIP) which could not deal with this (it requires that a single IP network number be used with variable subnet masks). However, if only some domains implement classless IGPs (such as OSPF and I.IS-IS), they can be given space from the subnetted class A address space (so we gain proportional to how much of total internet is updated to use classless IGPs). - Question: We need to describe how this affects the backward (address to name) DNS lookup. I don't think that this should be any different from CIDR with class C's. 4. Address Recycling and Renumbering - recall addresses that aren't widely used - this will make CIDR and hidden networks more effective - also make use of entire address space (recall B's for folks that can use "n" C's; recall A's for folks that can use "n" B's) - could charge for addresses/announcements to motivate address reuse - is not really all that bad (note that Wellfleet Engineering changed all IP addresses about 6 months ago due to a physical move, and got it all straightened out over a weekend). 5. Independent Network-to-Provider and Provider-to-Route mappings - (note that we are not necessarily advocating this method, but are documenting it for completeness). - The IANA (Internet Assigned Numbers Authority) assigns a 16-bit ID to every Internet provider (backbones, regionals, PTTs, etc.) - Inter-domain routing is based on this ID (and is used to calculate an optimal routes to every provider dynamically and rapidly). - Someone (see below), on a once a month basis, creates a large static table mapping from IP Network number (or CIDR aggregration) to provider. The table is distributed to all backbone routers via FTP, or perhaps by Federal Express applied to compact disks. The table maps {IP Address, mask} to {list of providers that service this address} - Every backbone router has a disk (or CD reader) which is used to store this large table. - Backbones routers maitain a forwarding cache mapping {IP Address, mask} to route (next hop router, outgoing interface, etc.). Initialize forwarding cache to empty. - When a backbone router receives an IP packet to be forwarded: - It looks up the destination address in forwarding cache. If there forward packet, else: - It looks up destination address in the large static provider table, determines list of providers which service this address, looks in (dynamically updated) routing table, determines closest regional servicing this destination and resulting route, and puts appropriate entry in the forwarding cache. - As long as the total number of entries in the static table is moderate (perhaps less than 100,000, or larger), it could be maintained in memory on the router. Thus a disk is not really necessary at first (the current table size could obviously be easily maintained in memory). - The large table creation could be partially automated. Also note that this approach covers up some of the ugly parts of CIDR (networks which do not use CIDR-correct addresses only effect the static table, not the dynamic routing; Multi-homed sites are easily handled by this approach). However, CIDR and hidden network numbers will both make this approach work better, by substantially reducing the size of the static table. I therefore consider all of CIDR, Hidden Networks, and "independent mappings" to be compatible and mutually helpful methods to extend the life of the IP address space. The total number of Internet backbones, regionals, and other service providers is, of course, currently small enough that it would be easy to route between them based on flat routing. We might think about how to add policy restrictions into this model (?). For example, the static table might list regionals serving a particular site in order of policy preference (with equal preference regionals noted). Note that this is a rather drastic method, and should only be used if we really need to use it. References [1] "CIDR and the Evolution of the Internet Protocol", H.W.Braun, P.Ford, Y.Rekhter, Proceedings of INET '93, August 1993. From rcallon@wellfleet.com Fri Dec 10 16:44:41 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA01396 for ; Fri, 10 Dec 1993 16:41:45 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA19386; Fri, 10 Dec 93 16:28:34 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA28053; Fri, 10 Dec 93 16:36:57 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA03857; Fri, 10 Dec 93 16:44:41 EST Date: Fri, 10 Dec 93 16:44:41 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312102144.AA03857@cabernet.wellfleet> To: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Subject: Re: DRAFT minutes from December 6 teleconference I also wish to express my displeasure at the equation of DECnet Phase IV "hidden addresses" with the OSI "local addresses" which occurred within this telethon. The two are quite dissimilar. The problem in the DECnet case was that large end users (i.e., Boeing) simply ran out of 16 bit DECnet addresses within the corporate address space. Thus, a kludge was made whereby additional networks could be added within that space which were not (really) known to the corporation's backbone routers. It's been a long time since I dealt with this so I must confess that I no longer recall exactly how this kludge was done. In any case, this is not a schema which I support and thus the equation of this approach with local addresses is quite galling to me. OSI "local addresses" are quite different. A local address is an address space whose addresses are a priori defined to solely have meaning within a given domain (corporation). For this reason, entities with these addresses can not (by definition) use these addresses for communications outside of the corporation. This "security feature" has many very useful elements which are extremely attractive to industry. The fact that it also is an excellent way to achieve "address re-use" within an IPv4 context is an incidental but useful co-incidence to its primary security function. I agree with Eric's comments, although I don't recall the discussion during the telechat. Perhaps this was after I had to leave. One last matter: the discussion also displayed a frightening lack of understanding as to why industry *MUST* maintain security islands until such a time as adequate security is attainable by other means. This is too important and too large a topic to be covered here now. While I am very cognizant as to the undesirable "down side" of this approach, the alternative is to go bankrupt as a business. This is not hyperbole. If anybody does not understand why this is so, please contact me privately. Just as an example of how important reliability and security is: When I was at DEC I met one customer (from a fortune 100 company) who had a two totally redundant computer centers. One of the two was near an airport, and so was buried underground in a bunker which would take a direct hit from a 747 (or any other commercial airplane) crashing into it without going down. They had noticed that if their computer centers both went down for a month or so they would be out of business, and so weren't taking any chances. Naturally they had run out of space in the bunker, and so really didn't care how expensive a computer was, what they cared about was how much computation power they could get into a certain volume of space. (I will let you guess whether they were hooked up to the Internet -- however they were massively networked). Ross From bound@zk3.dec.com Sat Dec 11 00:01:27 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA02810 for ; Sat, 11 Dec 1993 00:05:48 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA15158; Fri, 10 Dec 93 21:01:53 -0800 Received: by xirtlu.zk3.dec.com; id AA16811; Sat, 11 Dec 1993 00:01:33 -0500 Message-Id: <9312110501.AA16811@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil, scoya@CNRI.Reston.VA.US, ericf@picard.cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: DRAFT minutes from December 6 teleconference In-Reply-To: Your message of "Fri, 10 Dec 93 08:59:46 PST." <9312101659.AA05231@atc.boeing.com> Date: Sat, 11 Dec 93 00:01:27 -0500 X-Mts: smtp Regarding DECnet I will go one step further - I don't see any but a generic relationship between DECnet and IPng. I wont say its like comparing apples and oranges but maybe pears and apples. One major difference between PhIV and PhV and IPv4 to IPng is that IPng is supposed to be leaving the Transport in tact and above. This hopefully will insulate and move applications quickly over IPng. Regarding local addresses there is one issue; if autoconfiguration is used to bring up a new node on the network it can be done by creating a temporary local address in some protocols. But, is that also the System Identifier for that machine. It appears TUBA and SIPP are addressing this question, which is good. /jim From jcurran@nic.near.net Sat Dec 11 00:37:14 1993 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA02889 for ; Sat, 11 Dec 1993 00:41:35 -0500 Message-Id: <199312110541.AAA02889@picard.cmf.nrl.navy.mil> Received: from bronze.near.net by nic.near.net id aa21689; 11 Dec 93 0:41 EST To: bound@zk3.dec.com cc: Eric Fleischman , ipng@cmf.nrl.navy.mil, scoya@cnri.reston.va.us, ericf@picard.cmf.nrl.navy.mil Subject: Re: DRAFT minutes from December 6 teleconference In-reply-to: Your message of Sat, 11 Dec 1993 00:01:27 -0500. <9312110501.AA16811@xirtlu.zk3.dec.com> Date: Sat, 11 Dec 1993 00:37:14 -0500 From: John Curran -------- ] From: bound@zk3.dec.com ] Subject: Re: DRAFT minutes from December 6 teleconference ] Date: Sat, 11 Dec 93 00:01:27 -0500 ] ] Regarding DECnet I will go one step further - I don't see any but a generic ] relationship between DECnet and IPng. I wont say its like comparing ] apples and oranges but maybe pears and apples. One major difference ] between PhIV and PhV and IPv4 to IPng is that IPng is supposed to be ] leaving the Transport in tact and above. This hopefully will insulate ] and move applications quickly over IPng. Jim, Applications currently use TCP and UDP with 32-bit identifiers. Short of introducing dynamic numbering, IPng must alter transport layer or risk using less-than-unique 32 bit identifiers for communication. Until we change TCP and UDP API's or use NAT, we haven't actually resolved the IPv4 address depletion problem. /John From bound@zk3.dec.com Sat Dec 11 01:11:09 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA02980 for ; Sat, 11 Dec 1993 01:16:24 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA18188; Fri, 10 Dec 93 22:11:26 -0800 Received: by xirtlu.zk3.dec.com; id AA24887; Sat, 11 Dec 1993 01:11:16 -0500 Message-Id: <9312110611.AA24887@xirtlu.zk3.dec.com> To: rcallon@wellfleet.com (Ross Callon) Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: DRAFT minutes from December 6 teleconference In-Reply-To: Your message of "Fri, 10 Dec 93 16:43:18 EST." <9312102143.AA03851@cabernet.wellfleet> Date: Sat, 11 Dec 93 01:11:09 -0500 X-Mts: smtp ************************* - Sites that do need Internet access can also limit use of globally unique addresses: - Some systems don't need Internet access (printers, ...). These use the local addresses. - Some systems only need limited access which can be via relays (such as Email relays). These also use local addresses. - Clearly, any system which is administratively precluded from global internet access will use local addresses. - Other systems need global addresses. For example, workstations and PCs which are using an application which cannot conveniently go via application relays can use global addresses. Similarly, electronic mail relays must have global addresses. ***************************** - If a physical subnet contains at least one system which requires a global address, plus at least one system which does not, then the subnet has two addresses assigned to it, one which is globally unique, and one which is for local use only. The globally meaningful subnet address should be chosen to be large enough to cover only those systems that require global IP access. *********************************************************** Most Host IP implementations do not and cannot without much code changes use their datalink device for multiple subnets. Because machines that need Internet access may in fact have to exist also as a machine for daily use. If daily use is defined with the local address assignment then the first thing that will have to happen is the machine will need another datalink device like a second Ethernet port. If my machine needs a global IP address but my printer uses a local address subnet I will need to access that printer over the Ethernet that uses that subnet. This now implies the machine support IP routed listener too. Not saying this will not work but it does have some cost for Host machines and Host vendor code bases may have to be altered which will take time. DNS resolvers and /etc/host type files will take care of making sure if an application uses 16.233.14.5 (global IPv4) or 15.14.244.12 (local address). This is a well known how-to-do for IPv4 Hosts when a router is not warranted between subnets. I think also the security hole of using Host gateways from local to global addresses needs some thought. For example I can rlogin as local address machine to a machine that has both local and global addresses which means someone could get into me too. But there are tools out there and configuration parameters in addition to firewalls. ************** I have heard that there is at least one case of a large US Corporation which has a class B IP network number, with only 13 hosts visible from outside of the corporation! (there are lots of other hosts on the network, but they are administratively prohibited from Internet access). Similarly, there are many sites which do not have Internet access at all, but have asked for and received globally meaningful IP addresses because they have been under the impression that this is the correct thing that they are expected to do. Thus there is clearly some situations in which we can save addresses by using local addressing. ******************* I have seen this too just recently good point. In fact I just got asked how to configure CIDR with Class C addresses for 1000 nodes. Its already started. ************************** Note: One disadvantage of local addresses is that systems with local addresses might in principle in the future want access to the Internet, either for an existing application or for a new application. If such systems have local addresses, then when they need in the future to hook up to the Internet they will need to either have their IP address changed to be global, or be updated to understand IPng. Note that if they are being updated to a new application it might be desireable that they be updated to IPng at the same time in any case (some new applications might be defined to only run over IPng). *********************************** Or use both local and global addresses, but clearly it could be an opportunity to move to IPng if the applications they need have been ported to IPng. ******************** - This requires IGP and EGP to be classless. The original complaint about using CIDR with the class A space was based on some old routers (with old routing protocols such as the old version of RIP) which could not deal with this (it requires that a single IP network number be used with variable subnet masks). However, if only some domains implement classless IGPs (such as OSPF and I.IS-IS), they can be given space from the subnetted class A address space (so we gain proportional to how much of total internet is updated to use classless IGPs). *************** Just a note RIPv2 will support CIDR too and has the variable subnet mask. In addition its less work to move from RIP to RIPv2 than OSPF in a pinch on a Host. *************************** - Question: We need to describe how this affects the backward (address to name) DNS lookup. I don't think that this should be any different from CIDR with class C's. ************************* I don't think this is a problem because its just a different set of PTR records. For example: Host Interface 1 Local would be db.15.14.244 file 244.14.15.in-addr-arpa ....... SOA record etc... Host Interface 2 Global would be db.16.233.14 file 14.233.16.in-addr-arpa ....... SOA record etc... A bit more on firewalls which maybe should be part of this document. Lets say XYZ is using the local address scheme assigned by IANA but also needs Internet access with Internet network addresses. But XYZ does not want anyone to come into XYZ except mail on the global network. This can be done with the firewall. In addition a cryptokey can also be used to provide access into your network like when your at an IETF meeting and you want to telnet and ftp files at your home host that is a global machine. We have done this for some Fortune 100 companies. So it works. /jim From bound@zk3.dec.com Sat Dec 11 01:46:40 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA03033 for ; Sat, 11 Dec 1993 01:50:35 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA19811; Fri, 10 Dec 93 22:46:56 -0800 Received: by xirtlu.zk3.dec.com; id AA28303; Sat, 11 Dec 1993 01:46:46 -0500 Message-Id: <9312110646.AA28303@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, Eric Fleischman , ipng@cmf.nrl.navy.mil, scoya@cnri.reston.va.us, ericf@picard.cmf.nrl.navy.mil Subject: Re: DRAFT minutes from December 6 teleconference In-Reply-To: Your message of "Sat, 11 Dec 93 00:37:14 EST." <199312110541.AAA02889@picard.cmf.nrl.navy.mil> Date: Sat, 11 Dec 93 01:46:40 -0500 X-Mts: smtp ** Note ericf@picard.cmf.nrl.navy.mil is bouncing fyi ... too late for me ** to test problem on my end if any...sorry .. John, -------- ] From: bound@zk3.dec.com ] Subject: Re: DRAFT minutes from December 6 teleconference ] Date: Sat, 11 Dec 93 00:01:27 -0500 ] ] Regarding DECnet I will go one step further - I don't see any but a generic ] relationship between DECnet and IPng. I wont say its like comparing ] apples and oranges but maybe pears and apples. One major difference ] between PhIV and PhV and IPv4 to IPng is that IPng is supposed to be ] leaving the Transport in tact and above. This hopefully will insulate ] and move applications quickly over IPng. *************************** Jim, Applications currently use TCP and UDP with 32-bit identifiers. Short of introducing dynamic numbering, IPng must alter transport layer or risk using less-than-unique 32 bit identifiers for communication. Until we change TCP and UDP API's or use NAT, we haven't actually resolved the IPv4 address depletion problem. /John ******************************** Yes this is true and it effects several parts of the transport but the TCP and UDP services are essentially the same from the IPng network layer. I am seeing the porting issues now at the transport infrastructure like the queues and sock_addr_in and out for CLNP and SIPP 64bits. So your right. On the API it will be done different ways and I won't say how I prefer it to be done right now, but clearly at the API a protocol address will be defined for either 32bits or IPngbits. This decision in the API will set a global protocol-switch in the IP_PROTO data structure as an example. This turns the transport into IPng address environment. I agree and until this is really done we have not actually resolved the IPv4 address problem. This is why the API set (and its more than one and effects well-known libraries) I feel should be part of any proposals transition explanation with the performance costs at the API level and the transport layer. The other issue is how easily can IPv4 applications (not IPv4 like telnet, ftp, etc) be moved to the new scheme. And does the new API incantation support binary portability so that for IPv4 applications that do not move keep running even though there are now extensions to the common set of APIs for IPv4. If IPng breaks existing applications at the API before they can leave IPv4 much of the end user market will make loud grinding noises. PIP did propose using a 32bit handle too which may work but I need to look at that again as my brain went void Thursday checking long data types on some public domain code which on Alpha is now 64bits not 32bits. Anyway the PIP handles can kind of be dynamic numbering in a sense. /jim From brian@dxcoms.cern.ch Tue Dec 14 15:10:45 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA09822 for ; Tue, 14 Dec 1993 09:11:38 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04255; Tue, 14 Dec 1993 15:10:48 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29616; Tue, 14 Dec 1993 15:10:46 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312141410.AA29616@dxcoms.cern.ch> Subject: Ross Callon's draft To: ipng@cmf.nrl.navy.mil Date: Tue, 14 Dec 1993 15:10:45 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1530 Ross, I remembered your draft when I saw it again. My reaction is: yes, but this is much wider than what we discussed in the teleconf. It is a good strawman for ALE to look at. On the narrow issue of hidden networks, I don't want to rehash the issue of DECnet IV hidden areas. But my strawman on this would look like this: 1. A "private network" is defined as a subset of the Internet which is managed by a single entity and which is connected to the Internet by one or more routers. Such a network must have at least one NIC-assigned network number (class A, B, C or CIDR). 2. To facilitate both security firewalls and conservation of address space, a set of "private IP network numbers (PINNs)" will be permanently assigned by IANA and reserved for local use inside private networks. PINNS may be freely assigned by the managers of private networks, within the private network, in addition to any NIC-assigned network numbers. 3. In no circumstance shall any router between a private network and the Internet issue any routing announcement referring to any PINN, or transmit any packet to or from a PINN host address. 4. PINN hosts requiring direct Internet connectivity must either be moved to a non-PINN network within the private network, or be accessed via a router with dynamic translation of addresses, such that the host appears to the Internet with a non-PINN address belonging to the private network. 5. IANA will asssign one class A address, 16 class B addresses, and 256 class C addresses as PINNs. Brian From deering@parc.xerox.com Tue Dec 14 06:35:41 1993 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA10333 for ; Tue, 14 Dec 1993 09:36:54 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14829(1)>; Tue, 14 Dec 1993 06:36:00 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 14 Dec 1993 06:35:56 -0800 To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: Ross Callon's draft In-reply-to: brian's message of Tue, 14 Dec 93 06:10:45 -0800. <9312141410.AA29616@dxcoms.cern.ch> Date: Tue, 14 Dec 1993 06:35:41 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Dec14.063556pst.12171@skylark.parc.xerox.com> > 4. PINN hosts requiring direct Internet connectivity must either be > moved to a non-PINN network within the private network, > or be accessed via a router with dynamic translation of > addresses, such that the host appears to the Internet with > a non-PINN address belonging to the private network. Brian, Most routers these days support the existance of more than one subnet on the same wire, so it ought to be possible for a host requiring external communication to simply be assigned a non-PINN address (instead of, or in addition to, a PINN address), without requiring that it be moved to a separate network from PINN hosts or that address translation be performed. Steve From bound@zk3.dec.com Tue Dec 14 10:07:25 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA11381 for ; Tue, 14 Dec 1993 10:12:13 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA19393; Tue, 14 Dec 93 07:07:28 -0800 Received: by xirtlu.zk3.dec.com; id AA07690; Tue, 14 Dec 1993 10:07:31 -0500 Message-Id: <9312141507.AA07690@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Ross Callon's draft In-Reply-To: Your message of "Tue, 14 Dec 93 15:10:45 +0100." <9312141410.AA29616@dxcoms.cern.ch> Date: Tue, 14 Dec 93 10:07:25 -0500 X-Mts: smtp Ross, I would also like to see mention that the proposal can be implemented as I stated using multiple interfaces and firewalls. This provides users who use IPv4 Host Gateways to hide IPv4 subnets today to also make use of this proposal. There are two approaches to solve this problem. One the way Brian stated and the other the way I stated in my response to your strawman. I have an IPv4 machine I am sending this mail to you on and using part of what I sent you. No one can get to my machine except through mail unless we let you. But I and others can converse on the Internet. We also hide our subnets or make them unavailable internally in engineering depending on the type of work. I can't commit to writing more stuff but in a pinch I would clean up what I sent so you could paste it in, but if another could do it that would be better. Maybe Scott and Eric can add it in if they are putting finishing touches on? I would like to ask you and the Directorate that DECnet IV not be mentioned at all in the strawman or allude to DECnet IV (or Phase V). I think this is a dead horse and has been beaten enough. thanks /jim From jcurran@nic.near.net Tue Dec 14 11:33:45 1993 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA12700 for ; Tue, 14 Dec 1993 11:33:50 -0500 Message-Id: <199312141633.LAA12700@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa01009; 14 Dec 93 11:33 EST To: ipng@cmf.nrl.navy.mil Subject: PINN Hosts and security Date: Tue, 14 Dec 1993 11:33:45 -0500 From: John Curran Formalizing PINN is probably a good idea, but we should not be using "improved security" as a possible justification. If there is packet- forwarding going on, then it is quite simple to access such hosts from the Internet, even when going against the flow of routing. We can certainly say that it's "as secure as IPv4". (thus following time-honored traditions in the IETF... :-) /John From smb@research.att.com Tue Dec 14 12:07:26 1993 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.4/8.6.4) with SMTP id MAA13162 for ; Tue, 14 Dec 1993 12:09:21 -0500 From: smb@research.att.com Message-Id: <199312141709.MAA13162@picard.cmf.nrl.navy.mil> Received: by gryphon; Tue Dec 14 12:07:27 EST 1993 To: ipng@cmf.nrl.navy.mil Subject: Re: PINN Hosts and security Date: Tue, 14 Dec 93 12:07:26 EST I don't think that we should encourage or support the notion of private addresses. They only lead to trouble, and the increase in security compared with other firewall technologies is low. First of all, if I can keep my internal routes from leaking, I can do so whether they're officially private, officially assigned to me, or conjured up by my random address daemon. The attacks possible -- tunneling, source routing, and the like -- are the same in any event. Second, address translation doesn't work well for some protocols, especially FTP. Well, it could have worked, but 99% of the clients and servers generate/expect PORT commands before every file transfer, and the default association isn't used. How is a packet-level address translator supposed to munge PORT commands? Even if you used an auxiliary FTP gateway, which interpreted and modified the PORT command to specify an externally-usable address, you'd still have the problem that the data call is an incoming call to the client -- and very few firewalls are happy about such things. There are starting to be FTP clients that use PASV instead (and I'm drafting an RFC on the subject), but so far, they're few and far between. (And some FTP servers don't support PASV, even though they ``must''.) Third, giving official sanction to local-only addresses is giving official sanction to trouble. In my experience, the one sure thing you can say about networks is that they *will* interconnect at some point, even if you ``know'' now that they won't. In the case of a corporate firewall, the interconnection might be because of a merger (when AT&T bought NCR, our IP networks were able to talk because we *did* use official addresses, despite our firewall). Or it might be because of a joint venture -- if your company and mine both use use net 126 for our internal nets, we're going to have a very hard time setting up shared access to existing machines. Yes, one can always renumber. Do we really want to promulgate policies that will encourage that pain? Right now, I'm shying away from renumbering just 30 machines on a local net, even though routing will be better if I do (don't ask for details; they're too painful), because one of the machines in question is a well-known internal FTP and DNS site. Reusing hidden addresses is useful in the short term, to stretch the IPv4 lifetime. But IPng is supposed to create a big enough address space that that isn't going to be a problem, right? --Steve Bellovin From rcallon@wellfleet.com Tue Dec 14 14:52:07 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA00642 for ; Tue, 14 Dec 1993 15:53:57 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04603; Tue, 14 Dec 93 14:35:44 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA00803; Tue, 14 Dec 93 14:44:12 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04537; Tue, 14 Dec 93 14:52:07 EST Date: Tue, 14 Dec 93 14:52:07 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312141952.AA04537@cabernet.wellfleet> To: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: Ross Callon's draft I remembered your draft when I saw it again. My reaction is: yes, but this is much wider than what we discussed in the teleconf. It certainly is more than just hidden network numbers. It is a good strawman for ALE to look at. I think that *some group* should look at it. I was under the impression that this goes wider than the scope of ALE. On the narrow issue of hidden networks, I don't want to rehash the issue of DECnet IV hidden areas. But my strawman on this would look like this: 1. A "private network" is defined as a subset of the Internet which is managed by a single entity and which is connected to the Internet by one or more routers. Such a network must have at least one NIC-assigned network number (class A, B, C or CIDR). 2. To facilitate both security firewalls and conservation of address space, a set of "private IP network numbers (PINNs)" will be permanently assigned by IANA and reserved for local use inside private networks. PINNS may be freely assigned by the managers of private networks, within the private network, in addition to any NIC-assigned network numbers. 3. In no circumstance shall any router between a private network and the Internet issue any routing announcement referring to any PINN, or transmit any packet to or from a PINN host address. So far I agree completely. 4. PINN hosts requiring direct Internet connectivity must either be moved to a non-PINN network within the private network, or be accessed via a router with dynamic translation of addresses, such that the host appears to the Internet with a non-PINN address belonging to the private network. I was thinking that a single physical subnet may have two network numbers assigned to it, one for local use (a subnet of a PINN), and one using global IP addresses. Thus, if a previously local host wants to "go public", it would need to have its address changed, but would not have to physically move. I don't think that dynamic translation of addresses in routers is a good idea. 5. IANA will asssign one class A address, 16 class B addresses, and 256 class C addresses as PINNs. Again, this seems about right. Ross From rcallon@wellfleet.com Tue Dec 14 14:54:39 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA00635 for ; Tue, 14 Dec 1993 15:53:22 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04619; Tue, 14 Dec 93 14:38:17 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA00847; Tue, 14 Dec 93 14:46:45 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04541; Tue, 14 Dec 93 14:54:39 EST Date: Tue, 14 Dec 93 14:54:39 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312141954.AA04541@cabernet.wellfleet> To: deering@parc.xerox.com Subject: Re: Ross Callon's draft Cc: ipng@cmf.nrl.navy.mil Most routers these days support the existance of more than one subnet on the same wire, so it ought to be possible for a host requiring external communication to simply be assigned a non-PINN address (instead of, or in addition to, a PINN address), without requiring that it be moved to a separate network from PINN hosts or that address translation be performed. Steve; I am not sure whether Brian meant physical movement (physically connect to a different subnet), or logical movement (leave the host physically in the same place, but give it a different IP address). However, I agree completely that the latter is best: This would simply require that for those specific subnets where you want to have both globally-addresses and locally-addresses hosts, you will need to use routers which support multiple subnets on the same wire. Ross From rcallon@wellfleet.com Tue Dec 14 15:12:15 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by (8.6.4/8.6.4) with SMTP id PAA00342 for ; Tue, 14 Dec 1993 15:13:03 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04770; Tue, 14 Dec 93 14:55:52 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA01196; Tue, 14 Dec 93 15:04:20 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04556; Tue, 14 Dec 93 15:12:15 EST Date: Tue, 14 Dec 93 15:12:15 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312142012.AA04556@cabernet.wellfleet> To: bound@zk3.dec.com Subject: Re: Ross Callon's draft Cc: ipng@cmf.nrl.navy.mil I would also like to see mention that the proposal can be implemented as I stated using multiple interfaces and firewalls. This provides users who use IPv4 Host Gateways to hide IPv4 subnets today to also make use of this proposal. There are two approaches to solve this problem. One the way Brian stated and the other the way I stated in my response to your strawman. I have an IPv4 machine I am sending this mail to you on and using part of what I sent you. No one can get to my machine except through mail unless we let you. But I and others can converse on the Internet. We also hide our subnets or make them unavailable internally in engineering depending on the type of work. Yes this is very similar. However, what I am concerned about is that eventually we are going to find IP addresses in short supply, and thus those systems which are "local" will not want to use up a publically assigned globally meaningful address. This leaves the customer with such "local" machines with two other choices: Use some official PINN space, or just grab any random address and start using it as a local address. The latter would seem workable, since the address is not going to be advertised out on the Internet by this particular company. However, there is a problem... Let's suppose that a large company "XYZ Uncorporated" has a large number of machines with local addresses, plus a much smaller number of machines with global addresses, located on the same subnets. Let's assume that the small number of machines with globally meaningful IP addresses have access to the public Internet. If the other machines (with local addresses) on XYZ's private network just used some address taken at random, then somewhere in the world may be a network with the same addresses, but being used "officially" for global network access. So, suppose that a globally addressed machine on XYZ's private network wants to send out two copies of a message, one to a machine on the same subnet which uses a local address, and one to a machine on the other side of the world which happens to be using the same address, but officially. This doesn't work. This means that for Private Internet Network Numbers to work, then some small part of the IP address space must be assigned for this purpose. I think that it will not take much space (a single class A might be enough) although Brian's proposal might make life easier for folks wanting to use PINN's. I can't commit to writing more stuff but in a pinch I would clean up what I sent so you could paste it in, but if another could do it that would be better. Maybe Scott and Eric can add it in if they are putting finishing touches on? I hope that Scott and Eric are busily editing while I am typing (rather than doing my real job, which has nothing to do with IPng). I would like to ask you and the Directorate that DECnet IV not be mentioned at all in the strawman or allude to DECnet IV (or Phase V). I think this is a dead horse and has been beaten enough. I will try to avoid public flogging of DECnet Phase 4 and 4-->5 transition as much as possible. Unfortunately, there are important lessons to learn from the phase 4 to phase 5 transition, and so far the IETF does not seem to have learned them :-(. I would hate to copy all the same mistakes over into the IP to IPng transition. Ross From rcallon@wellfleet.com Tue Dec 14 15:25:51 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA00622 for ; Tue, 14 Dec 1993 15:52:43 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04925; Tue, 14 Dec 93 15:09:29 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA01475; Tue, 14 Dec 93 15:17:57 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04574; Tue, 14 Dec 93 15:25:51 EST Date: Tue, 14 Dec 93 15:25:51 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312142025.AA04574@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil, smb@research.att.com Subject: Re: PINN Hosts and security Sorry about barraging the nets with text... I don't think that we should encourage or support the notion of private addresses. They only lead to trouble, and the increase in security compared with other firewall technologies is low. Absolutely this is not a security mechanism. We should use large clear are repeated warnings that use of private network numbers does nothing to improve security. However, I think that folks will want to do this for address space conservation reasons. For example, some companies are going to find that they only need a single class C for those systems that need Internet access, and that they have trouble getting enough globally meaningful IP address space to give global addresses to the much larger set of machines that they have in their nets. Thus, my feeling is: PINN for address conservation, yes yes yes PINN for security, NO NO NO NO NO NO NO NO, NEVER NEVER NEVER!! (I will delete your security comments, because I agree) Second, address translation doesn't work well for some protocols, especially FTP. Well, it could have worked, but 99% of the clients and servers generate/expect PORT commands before every file transfer, and the default association isn't used. How is a packet-level address translator supposed to munge PORT commands? Even if you used an auxiliary FTP gateway, which interpreted and modified the PORT command to specify an externally-usable address, you'd still have the problem that the data call is an incoming call to the client -- and very few firewalls are happy about such things. There are starting to be FTP clients that use PASV instead (and I'm drafting an RFC on the subject), but so far, they're few and far between. (And some FTP servers don't support PASV, even though they ``must''.) I don't like address translation (I should call in Noel as a guest writer to express my disdain for address translation in sufficiently flowery and graphic text). Thus I think that we should make it clear that if a host with a PINN address later wants global connectivity, then it will need to have its address changed. Now, I fear that address translation may be one of those things which is marginally workable, and that someone will actually build and deploy it. Thus we should probably avoid truely horrendous problems that would result if anything that we do is fundamentally incompatible with it. Third, giving official sanction to local-only addresses is giving official sanction to trouble. In my experience, the one sure thing you can say about networks is that they *will* interconnect at some point, even if you ``know'' now that they won't. In the case of a corporate firewall, the interconnection might be because of a merger (when AT&T bought NCR, our IP networks were able to talk because we *did* use official addresses, despite our firewall). Or it might be because of a joint venture -- if your company and mine both use use net 126 for our internal nets, we're going to have a very hard time setting up shared access to existing machines. A merger is one case where local addresses could become nasty. Yes, one can always renumber. Do we really want to promulgate policies that will encourage that pain? Right now, I'm shying away from renumbering just 30 machines on a local net, even though routing will be better if I do (don't ask for details; they're too painful), because one of the machines in question is a well-known internal FTP and DNS site. Golly, we just renumbered all of engineering about 6 months ago. It didn't seem all that bad. I think that it is a bit like having teeth drilled; thinking about it can be worse than having it done and over with, although it is better not to go through it too often. Reusing hidden addresses is useful in the short term, to stretch the IPv4 lifetime. But IPng is supposed to create a big enough address space that that isn't going to be a problem, right? Well, that depends upon how quickly we get IPng out there and deployed. There seems to be a widespread feeling that IP will still be around after the point where the IP address space is inadequate. I have some sympathy with the notion that address translation is soooooo bad that we want to avoid it at all costs, and that local addressing sort of makes life easier for address translation. However, folks are already doing local addresses, shouldn't we make it work as well as we can? Ross From bound@zk3.dec.com Tue Dec 14 15:59:14 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA00818 for ; Tue, 14 Dec 1993 16:09:57 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA14458; Tue, 14 Dec 93 12:59:32 -0800 Received: by xirtlu.zk3.dec.com; id AA20672; Tue, 14 Dec 1993 15:59:20 -0500 Message-Id: <9312142059.AA20672@xirtlu.zk3.dec.com> To: rcallon@wellfleet.com (Ross Callon) Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Ross Callon's draft In-Reply-To: Your message of "Tue, 14 Dec 93 15:12:15 EST." <9312142012.AA04556@cabernet.wellfleet> Date: Tue, 14 Dec 93 15:59:14 -0500 X-Mts: smtp FYI ..... I tend to agree with Steve about the whole idea of private local use addresses and that we may be opening pandoras box. >Let's suppose that a large company "XYZ Uncorporated" has a large number of >machines with local addresses, plus a much smaller number of machines with >global addresses, located on the same subnets. Let's assume that the small >number of machines with globally meaningful IP addresses have access to the >public Internet. If the other machines (with local addresses) on XYZ's >private network just used some address taken at random, then somewhere in >the world may be a network with the same addresses, but being used >"officially" for global network access. So, suppose that a globally addressed >machine on XYZ's private network wants to send out two copies of a message, >one to a machine on the same subnet which uses a local address, and one to >a machine on the other side of the world which happens to be using the same >address, but officially. This doesn't work. Yes it will if they use only assigned local addresses from some authority. Then that local address will not be used by others. >This means that for Private Internet Network Numbers to work, then some >small part of the IP address space must be assigned for this purpose. I >think that it will not take much space (a single class A might be enough) >although Brian's proposal might make life easier for folks wanting to >use PINN's. OK.... Yes thats what I thought we were going to ask for. This way my scenario will work and I can just have my Global address and still communicate with my local address printer via present Host Gateway subnet configuration. (I thought that printer example was a good one too). If we don't get assigned local addresses bought into via ALE then I don't think this should be formally documented. And I for one would not recommend my company ever use it. Because we have figure out how to have security with global addresses. >I will try to avoid public flogging of DECnet Phase 4 and 4-->5 transition >as much as possible. Unfortunately, there are important lessons to learn >from the phase 4 to phase 5 transition, and so far the IETF does not seem >to have learned them :-(. I would hate to copy all the same mistakes over >into the IP to IPng transition. I agree with your point about network layer transition there are mistakes to be avoided. If we can keep it in that context that would make life easier for me. )---> thanks ........ /jim From rcallon@wellfleet.com Tue Dec 14 18:27:15 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA01912 for ; Tue, 14 Dec 1993 18:28:45 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA06447; Tue, 14 Dec 93 18:10:52 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA04522; Tue, 14 Dec 93 18:19:20 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04717; Tue, 14 Dec 93 18:27:15 EST Date: Tue, 14 Dec 93 18:27:15 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312142327.AA04717@cabernet.wellfleet> To: bound@zk3.dec.com Subject: Re: DRAFT minutes from December 6 teleconference Cc: ipng@cmf.nrl.navy.mil I just found that there is some old mail that I haven't responded to. ***************************** - If a physical subnet contains at least one system which requires a global address, plus at least one system which does not, then the subnet has two addresses assigned to it, one which is globally unique, and one which is for local use only. The globally meaningful subnet address should be chosen to be large enough to cover only those systems that require global IP access. *********************************************************** Most Host IP implementations do not and cannot without much code changes use their datalink device for multiple subnets. Because machines that need Internet access may in fact have to exist also as a machine for daily use. If daily use is defined with the local address assignment then the first thing that will have to happen is the machine will need another datalink device like a second Ethernet port. If my machine needs a global IP address but my printer uses a local address subnet I will need to access that printer over the Ethernet that uses that subnet. This now implies the machine support IP routed listener too. Not saying this will not work but it does have some cost for Host machines and Host vendor code bases may have to be altered which will take time. DNS resolvers and /etc/host type files will take care of making sure if an application uses 16.233.14.5 (global IPv4) or 15.14.244.12 (local address). This is a well known how-to-do for IPv4 Hosts when a router is not warranted between subnets. I was assuming that if two IP subnet numbers are assigned to a single physical network, then if there are two hosts on that physical network but on different logical subnets, and they want to talk, then they have to talk via a router. Clearly this is something that will need to be specified in our paper. I think also the security hole of using Host gateways from local to global addresses needs some thought. For example I can rlogin as local address machine to a machine that has both local and global addresses which means someone could get into me too. But there are tools out there and configuration parameters in addition to firewalls. I was thinking that hosts would serve as gateways only for very limited applications. The most obvious is Email, which is already widely in use. However, I did not intend for this to help security, but rather only to save addresses. Clearly we have to decide whether local addresses buy anything at all for security, and either clearly state that this is not security at all, or else describe to what extent it helps (as soon as you say "local addresses", then lots of folks are going to think "security", so you have to figure out ahead of time what to say back). ... Just a note RIPv2 will support CIDR too and has the variable subnet mask. In addition its less work to move from RIP to RIPv2 than OSPF in a pinch on a Host. I think that it is unfortunate to see hosts implementing OSPF, but that is another issue. I agree that we should also mention RIPv2. *************************** - Question: We need to describe how this affects the backward (address to name) DNS lookup. I don't think that this should be any different from CIDR with class C's. ************************* I don't think this is a problem because its just a different set of PTR records. For example: I think that I agree, but I just haven't thought about this detail enough. Ross From ericf@atc.boeing.com Tue Dec 14 15:51:08 1993 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA02008 for ; Tue, 14 Dec 1993 18:51:52 -0500 Received: by atc.boeing.com (5.57) id AA04282; Tue, 14 Dec 93 15:51:08 -0800 Date: Tue, 14 Dec 93 15:51:08 -0800 From: Eric Fleischman Message-Id: <9312142351.AA04282@atc.boeing.com> To: bound@zk3.dec.com, rcallon@wellfleet.com Subject: Re: Ross Callon's draft Cc: ericf, ipng@cmf.nrl.navy.mil Dear Group, I desire to interject some realism into our local address discussion. I must confess that my response is being given during a time in which I am totally pre-occupied by an extremely vexing security-related problem. Thus, I am doubtlessly being inadequately tactful. For this I apologize in advance. I sincerely hope that nobody is offended. Such is not my intention. However, the bottom line from the large end-users point-of-view is: If end users have no availability to use viable local addresses, we will have to use other people's addresses to accomplish the same purposes. Of course, the latter is by no means as clean as the former. We obviously do not want to do this. But if we have to, we will. Many of our Fortune 100 peers already use third company's addresses as part of their addressing policy. More bluntly, I find it rather peculiar to be an end user saying: we end user's desperately need local address capabilities and then sitting back and hearing non-end-users saying "No you don't". Is it really all *THAT* difficult to understand that we want to ensure that a large class of our most important machines can *NEVER* access the Internet? These are the machines which make us viable as a corporate entity. They are our "crown jewels". We also would like to ensure that these systems can *NEVER* be accessable *FROM* the Internet. However, we simultaneously want them to be readily accessible from most parts of our internal corporate network. [Please note the elusive quality of these goals. Yet this is our desire.] Of course, local addresses are simply one component of a vastly larger security picture. Yet they aide in the total picture. [Note: Local addresses also free us from having to justify our addressing policies to outsiders with different priorities and values than us in order to obtain additional addresses for our internal use. Why should these outsiders be involved on internal corporate networking issues, especially if we have no intention of these nodes ever reaching the Internet? Frankly, it's none of their business.] What I find so difficult to understand is the apparent lack of ability of this group to understand a corporate viewpoint. The IETF attitude is "firewalls are bad because they limit functionalities." Wrong! There are environments where we *WANT* functionalities to be very limited and also environments which we want to be functionality-rich. Only a subset of our users will need WWW and the other very nice Internet-centric technologies. We want to ensure that these users will get these functionalities. A significant majority of our users are doing REAL WORK: They are physically making airplanes. They do not need these functionalities. They do not want these functionalities. Because their work is by-and-large more proprietary than the whiz-bang group, their environments need to better protected from outside interference. It's all a matter of "need to know" and "appropriate use". >From my knot-hole, the saying "if all you have is a hammer, every problem looks like a nail" describes how I view this discussion. That is, this group has a research bent. I see you as trying to foist environments which are good for researchers on everyone. While researchers need good environments to do research -- and they should get it, factory workers should get good environments to do factory work, designers good environments for design, etc. One size simply does not fit all. Within my corporation we have many classes of employees, each with differing needs which we strive to meet. [Yes, we also have researchers and we seek to give them good research environments.] Thus, I would like to re-iterate: Local addresses are a *REQUIREMENT* of the large end user. End of discussion. I realize that my comments are not likely to be appreciated in this forum. However, I will say that I defy any member on this group to find *EVEN ONE* Fortune 100 company which has a different position than what I am/have been outlining. Sincerely yours, --Eric Fleischman From smb@research.att.com Tue Dec 14 22:57:40 1993 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.4/8.6.4) with SMTP id WAA03589 for ; Tue, 14 Dec 1993 22:58:33 -0500 From: smb@research.att.com Message-Id: <199312150358.WAA03589@picard.cmf.nrl.navy.mil> Received: by gryphon; Tue Dec 14 22:57:40 EST 1993 To: Eric Fleischman cc: bound@zk3.dec.com, rcallon@wellfleet.com, ericf@picard.cmf.nrl.navy.mil, ipng@cmf.nrl.navy.mil Subject: Re: Ross Callon's draft Date: Tue, 14 Dec 93 22:57:40 EST More bluntly, I find it rather peculiar to be an end user saying: we end user's desperately need local address capabilities and then sitting back and hearing non-end-users saying "No you don't". Is it really all *THAT* difficult to understand that we want to ensure that a large class of our most important machines can *NEVER* access the Internet? These are the machines which make us viable as a corporate entity. They are our "crown jewels". We also would like to ensure that these systems can *NEVER* be accessable *FROM* the Internet. Me oppose firewalls? Me? I'm writing a book telling folks exactly why they should use firewalls, and how to build them. I agree with you 100% that some machines should never be accessible from the Internet. What I don't agree with is the claim that local addresses do anything significant to achieve that goal. In order to keep the addresses local, you have to install route filtering at your gateway router. That has to be done explicitly; the router has no way of knowning what ``outside'' is. If you can do that correctly, you can do the same for any set of addresses, be they officially local, officially assigned to you to do with as you please, or random. The official designation does nothing whatsoever to help you. At best, the vendor will provide a macro capability to define that standard set of ACL's. (But then how will you configure your internal firewalls? We use them, to isolate really critical things like switching support systems.) I'll even argue that officially-local addresses hinder security. Consider -- I know exactly what IP networks have been assigned to AT&T. Periodically, I ask random internal routers to dump their routing tables at me. It's easy for me to filter out 135.*.*.*, 192.11.*.*, 192.20.*.*, etc. At a glance, I can tell if any outside routes have leaked in. That would be much harder if someone has connected, say, one of your nets with a local address to my internal network. I do advocate firewalls built on a more comprehensible --- and more fail-safe --- technology than router access control lists. And I do advocate using route filtering as well, if you must use ACL's. If you really want to use address confusion as a security feature, reuse net 18 internally. Too many sites have to know the real way to reach MIT for global routing table confusion to happen unnoticed, and MIT's addresses are unlikely ever to be hidden behind a firewall. --Steve Bellovin From bound@zk3.dec.com Tue Dec 14 23:45:16 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA04419 for ; Tue, 14 Dec 1993 23:51:43 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA07625; Tue, 14 Dec 93 20:45:35 -0800 Received: by xirtlu.zk3.dec.com; id AA09078; Tue, 14 Dec 1993 23:45:25 -0500 Message-Id: <9312150445.AA09078@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: bound@zk3.dec.com, rcallon@wellfleet.com, ipng@cmf.nrl.navy.mil Subject: Re: Ross Callon's draft In-Reply-To: Your message of "Tue, 14 Dec 93 15:51:08 PST." <9312142351.AA04282@atc.boeing.com> Date: Tue, 14 Dec 93 23:45:16 -0500 X-Mts: smtp Eric, I don't believe anyone is opposing local addresses. What I think may be happening as a group is we are questioning whether stating this will give the impression that Security should be maintained this way. In addition we may want to allude the other possibilities and options available for nodes not using local addresses. I think firewalls are a good thing too. Is this unreasonable. I agree I cannot think of any end user who would not want local addresses. I have to connect with a lot of large fortune 100 end users often and they all want our firewalls if they find reasons at all to have Internet access. But, I also see what Steve is saying regarding local addresses. I assume your are convinced that local addresses do provide enough security, from a technical perspective? Would you still use firewalls in front of any local address subnet? Anyway that was a good reality sandwich. And I am not a researcher I am an engineer and always open to reality. Would like to be researcher someday in fact a Mad Computer Scientist in New England would be great. /jim From brian@dxcoms.cern.ch Wed Dec 15 17:10:59 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA09190 for ; Fri, 17 Dec 1993 02:21:27 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13359; Fri, 17 Dec 1993 08:21:08 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03181; Fri, 17 Dec 1993 08:21:07 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312170721.AA03181@dxcoms.cern.ch> Subject: Flameproof PINNs To: ipng@cmf.nrl.navy.mil Date: Wed, 15 Dec 1993 17:10:59 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 758 Sender: brian@dxcoms.cern.ch I've seen two attitudes to codifying the idea of PINNs (1) this is evil (2) this is OK, but don't confuse the issue by mentioning security I certainly agree with (2) and with Steve Deering's comment about multiple subnets on one wire being easier than NAT. These are easy fixes to my strawman text. I think I agree with (1) as well, but I think the issue is whether it is a necessary evil. There is no doubt that DECnet hidden areas are evil, and no doubt that they became necessary for many large networks. (I agree with Eric that corporate networks may require absolutely hidden networks, but this does not require PINNs.) I have two choices now: forget it, or update the text into I-D format and expose it to a wider audience. Opinions? - Brian From brian@dxcoms.cern.ch Wed Dec 15 18:04:54 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA02055 for ; Thu, 16 Dec 1993 02:14:28 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05507; Thu, 16 Dec 1993 08:12:53 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01720; Thu, 16 Dec 1993 08:12:52 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312160712.AA01720@dxcoms.cern.ch> Subject: 25K routes in EBONE To: ipng@cmf.nrl.navy.mil Date: Wed, 15 Dec 1993 18:04:54 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 300 Sender: brian@dxcoms.cern.ch IPNGers: FYI (please do not spread this in such a way as to start an unnecessary panic), I am told that the backbone routers in EBONE (the European backbone) are currently carrying about 25K routes and are starting to fall over with table overflows. Daniel, maybe you can add some info? - Brian From brian@dxcoms.cern.ch Wed Dec 15 18:04:54 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA09192 for ; Fri, 17 Dec 1993 02:21:37 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13616; Fri, 17 Dec 1993 08:21:18 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03189; Fri, 17 Dec 1993 08:21:17 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312170721.AA03189@dxcoms.cern.ch> Subject: 25K routes in EBONE To: ipng@cmf.nrl.navy.mil Date: Wed, 15 Dec 1993 18:04:54 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 300 Sender: brian@dxcoms.cern.ch IPNGers: FYI (please do not spread this in such a way as to start an unnecessary panic), I am told that the backbone routers in EBONE (the European backbone) are currently carrying about 25K routes and are starting to fall over with table overflows. Daniel, maybe you can add some info? - Brian From jcurran@nic.near.net Wed Dec 15 20:47:38 1993 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA01115 for ; Wed, 15 Dec 1993 20:47:43 -0500 Message-Id: <199312160147.UAA01115@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa25755; 15 Dec 93 20:47 EST To: ipng@cmf.nrl.navy.mil Subject: Re: Ross Callon's draft In-reply-to: Your message of Tue, 14 Dec 1993 22:57:40 -0500. <199312150358.WAA03589@picard.cmf.nrl.navy.mil> Date: Wed, 15 Dec 1993 20:47:38 -0500 From: John Curran -------- From: smb@research.att.com Subject: Re: Ross Callon's draft Date: Tue, 14 Dec 93 22:57:40 EST ... If you really want to use address confusion as a security feature, reuse net 18 internally. Too many sites have to know the real way to reach MIT for global routing table confusion to happen unnoticed, and MIT's addresses are unlikely ever to be hidden behind a firewall. "...for global routing table confusion to happen unnoticed" As one who notices such things for a living, I humbly ask that you don't use (in particular) net 18. Routing at the MIT border is NEARNET's responsibility, and accidently routing net 18 earns you to a personal visit from myself and Mr. Schiller. Everyone should feel free to use 192.20.225 (MH-INTER-NET) for this purpose. (chuckle) No, don't do that either. Look folks, it's very simple: o Having a reserved private IPv4 address space does _nothing_ to improve security (and may even provide "false security" - Steve B.'s message is pretty clear on the downsides of such) BUT, private Internet network numbers do allow: o It does allow sites to have sufficient address space for internal growth when sufficient IPv4 addresses are not available. I've been involved with over a dozen sites which have had to renumber in the last year or so. All of them felt "we're _never_ going to be connected to the Internet". Surprise, life changes. Despite this experience, I see the need for a reserved portion of the address space so that organizations may "shoot themselves in the foot" as they desire. Anyone on this directorate that feels they know "what's best" for other organizations had better check in with reality real soon now. We CANNOT second guess the priorities of others; all we can do is lay out risks and benefits. Boeing's need for a private-internet-address and the effort that they will go through to later renumber (if it should prove necessary) are both BOEING's business. "We know better than you, and you don't really want this" reflects an amazing amount of nerve by people who don't have to live with the _business_ implications of not having sufficient official addresses. Apologies for length (and tone :-) /John From bound@zk3.dec.com Wed Dec 15 22:04:54 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA01385 for ; Wed, 15 Dec 1993 22:11:03 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA11532; Wed, 15 Dec 93 19:05:02 -0800 Received: by xirtlu.zk3.dec.com; id AA13372; Wed, 15 Dec 1993 22:05:01 -0500 Message-Id: <9312160305.AA13372@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: KISS and Transition to SIPP list Date: Wed, 15 Dec 93 22:04:54 -0500 X-Mts: smtp Not sure your all on the SIPP list and thought this may be worth sending to you for comments. /jim ------- Forwarded Message To: sipp@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: Lets Keep it Simple SIPP (KISS) a Principle Date: Wed, 15 Dec 93 21:26:34 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: sipp-request@sunroof.eng.sun.com Idea for Transition Architecture in a nutshell: [Extending the mail Premises Part II] 1. Use SIN approach because of simplicity: 1) Keep architecture simple. 2) Keep implementation simple. 3) Keep testing simple. 4) Keep installation/operational procedures simple. So an end user can understand it simply. Having had to explain complex network configuration that was simple and hard I know the market appreciates it when its simple. Its worth money to them. 2. On Day X of IPng Begins: Hosts: a) All Hosts that have a requirement to to talk to IPv4 Hosts must support both IPng and IPv4. b) Hosts that do not have a requirement to talk to IPv4 Hosts can support only IPng on Day X or later. Routers: a) Border Routers must support IPng and IPv4 Day X or after to use IPng. b) Border Routers will continue to route IPv4 and IPng via SIN. 3. Conservation of IP Address Space: A) IPv4 Addresses must continue to be conserved through CIDR/ALE activity. B) Need to be able to assign old IPv4 addresses to routers for the forseeable future. C) In the far distant future when we are dead routers can become IPng only except for private networks that run old equipment with old addresses. 4. When no more old hosts addresses are assigned. Old hosts will continue to support existing systems to new IPng systems with Gateways. 5. Host software vendors should continue to have IPng and IPv4 stack capability, even after no more IPv4 Host Addresses are assigned. This is so new existing systems can replace old obsolete systems and retain their addresses. The cost to Hosts is minimal compared to the simplicity all of this brings to the operations procedures and cost of education of a more complex method. Comments ?? /jim ------- End of Forwarded Message From mankin Thu Dec 16 13:12:39 1993 Return-Path: mankin Received: from localhost (mankin@localhost) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) id NAA04902; Thu, 16 Dec 1993 13:12:39 -0500 Date: Thu, 16 Dec 1993 13:12:39 -0500 From: Allison J Mankin Message-Id: <199312161812.NAA04902@picard.cmf.nrl.navy.mil> To: ipng Subject: IPNG TELECHAT Monday + Apology Cc: mankin We agreed at the last telechat to have one (those who missed the telechat, sorry we didn't make sure you got an early notice of this). Apology is: my nutty group decided to move our servers in the last few days and things did not come up well, so the IPng Mailing List has been dysfunctional. I have a list of messages we saw bounce which I'll send to the senders. Things are not 100% yet. AFS has many IP address dependencies, so at least we can add a data point to IPng from this inconvenience. Allison From Robert_Ullmann.LOTUS@CRD.lotus.com Thu Dec 16 13:29:11 1993 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA05010 for ; Thu, 16 Dec 1993 13:24:53 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA07768; Thu, 16 Dec 93 13:26:29 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA13638; Thu, 16 Dec 93 13:29:11 EST Date: Thu, 16 Dec 93 13:29:11 EST Message-Id: <9312161829.AA13638@Mail.Lotus.com> Received: by DniMail (v1.0); Thu Dec 16 13:29:09 1993 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: re "PINN"s [this is one of the notes that bounced; hence it is a little out of sequence] I'd like to concur with Brian's proposal; I floated almost the identical proposal of reserved-to-local-use network numbers about a year ago (on the IETF discussion, you can dig it out if you really want to, but it isn't really any different) IMO, it must NOT be about "security." We have more than enough bogus "security" features already. Another reason for local nets will occur to you if you ever write vendor documentation for a TCP/IP product: what numbers do you use in examples? What numbers do you tell the customer to use if they simply don't care about global numbering? Being able to tell them they can use this class A, these 16 B's, and/or these 256 C's is a big benefit. Just changing the *default* instructions in vendor docs to "use these local numbers; if you want to be connected 'soon', then here's how you get global numbers" should lessen the pressure on the number space. Prohibiting these numbers from being routed across the interconnect networks is then a good *operational* feature, as is simply knowing that they are bogons if you do see them. But it is not "security." Also: using these numbers for some sort of NAT scheme is, IMO, a very bad idea. Don't even think about it. Rob P.S. Ross: > Golly, we just renumbered all of engineering about 6 months ago. It > didn't seem all that bad. This would be much more impressive if it wasn't the engineering department of a router vendor. As it is, I don't think it means much ... ;-) From sob@hsdndev.harvard.edu Mon Dec 20 12:56:27 1993 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA23000 for ; Mon, 20 Dec 1993 12:56:18 -0500 Date: Mon, 20 Dec 93 12:56:27 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312201756.AA16383@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: jim's & john's letters here are Jim's & John's letters Scott ------------- >From ipng-request@cmf.nrl.navy.mil Wed Dec 15 22:17:57 1993 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA15800; Wed, 15 Dec 1993 22:13:33 -0500 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA01385 for ; Wed, 15 Dec 1993 22:11:03 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA11532; Wed, 15 Dec 93 19:05:02 -0800 Received: by xirtlu.zk3.dec.com; id AA13372; Wed, 15 Dec 1993 22:05:01 -0500 Message-Id: <9312160305.AA13372@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: KISS and Transition to SIPP list Date: Wed, 15 Dec 93 22:04:54 -0500 X-Mts: smtp Status: R Not sure your all on the SIPP list and thought this may be worth sending to you for comments. /jim ------- Forwarded Message To: sipp@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: Lets Keep it Simple SIPP (KISS) a Principle Date: Wed, 15 Dec 93 21:26:34 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: sipp-request@sunroof.eng.sun.com Idea for Transition Architecture in a nutshell: [Extending the mail Premises Part II] 1. Use SIN approach because of simplicity: 1) Keep architecture simple. 2) Keep implementation simple. 3) Keep testing simple. 4) Keep installation/operational procedures simple. So an end user can understand it simply. Having had to explain complex network configuration that was simple and hard I know the market appreciates it when its simple. Its worth money to them. 2. On Day X of IPng Begins: Hosts: a) All Hosts that have a requirement to to talk to IPv4 Hosts must support both IPng and IPv4. b) Hosts that do not have a requirement to talk to IPv4 Hosts can support only IPng on Day X or later. Routers: a) Border Routers must support IPng and IPv4 Day X or after to use IPng. b) Border Routers will continue to route IPv4 and IPng via SIN. 3. Conservation of IP Address Space: A) IPv4 Addresses must continue to be conserved through CIDR/ALE activity. B) Need to be able to assign old IPv4 addresses to routers for the forseeable future. C) In the far distant future when we are dead routers can become IPng only except for private networks that run old equipment with old addresses. 4. When no more old hosts addresses are assigned. Old hosts will continue to support existing systems to new IPng systems with Gateways. 5. Host software vendors should continue to have IPng and IPv4 stack capability, even after no more IPv4 Host Addresses are assigned. This is so new existing systems can replace old obsolete systems and retain their addresses. The cost to Hosts is minimal compared to the simplicity all of this brings to the operations procedures and cost of education of a more complex method. Comments ?? /jim ------- End of Forwarded Message >From sipp-request@sunroof2.Eng.Sun.COM Wed Dec 15 23:01:22 1993 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AC26280; Wed, 15 Dec 93 19:59:32 PST Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14859; Wed, 15 Dec 93 19:58:12 PST Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06873; Wed, 15 Dec 93 20:00:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06867; Wed, 15 Dec 93 20:00:40 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA12077; Wed, 15 Dec 93 19:58:12 PST Received: from nic.near.net by Sun.COM (4.1/SMI-4.1) id AA26195; Wed, 15 Dec 93 19:58:26 PST Message-Id: <9312160358.AA26195@Sun.COM> Received: from nic.near.net by nic.near.net id aa05335; 15 Dec 93 22:58 EST To: bound@zk3.dec.com Cc: sipp@sunroof.Eng.Sun.COM Subject: Re: Lets Keep it Simple SIPP (KISS) a Principle In-Reply-To: Your message of Wed, 15 Dec 1993 21:26:34 -0500. <9312160226.AA08139@xirtlu.zk3.dec.com> Date: Wed, 15 Dec 1993 22:58:18 -0500 From: John Curran Sender: sipp-request@sunroof.Eng.Sun.COM Status: R -------- ] From: bound@zk3.dec.com ] Subject: Lets Keep it Simple SIPP (KISS) a Principle ] Date: Wed, 15 Dec 93 21:26:34 -0500 ] ] Idea for Transition Architecture in a nutshell: ] [Extending the mail Premises Part II] ] ] 1. Use SIN approach because of simplicity: ] 1) Keep architecture simple. ] 2) Keep implementation simple. ] 3) Keep testing simple. ] 4) Keep installation/operational procedures simple. ] ] So an end user can understand it simply. Having had to explain ] complex network configuration that was simple and hard I know the ] market appreciates it when its simple. Its worth money to them. I believe that the _architecture_ of IPng transition must be simple. Simple is defined in this context as being able to explain the normal operation and failure modes on a whiteboard with 2 colors in 30 minutes. Note: I don't think that "keeping it simple" mandates a ships-in-the-night transition. I do think that keeping it simple means that we excise failure modes and end-cases whenever possble. I've rewritten your principles below slightly, in order to clarify one possible SIN approach to transition. ] 2. On Day X of IPng Begins: ] Hosts: ] a) All Hosts that have a requirement to to talk to IPv4 ] Hosts must support both IPng and IPv4. "All hosts that have a requirement to talk to IPv4 systems must support IPv4." ] b) Hosts that do not have a requirement to talk to IPv4 ] Hosts can support only IPng on Day X or later. "All hosts that have a requirement to talk to IPng systems must support IPng." ] Routers: ] a) Border Routers must support IPng and IPv4 Day X or after ] to use IPng. ] b) Border Routers will continue to route IPv4 and IPng via ] SIN. "Border routers must support IPv4 if they're serving IPv4 hosts, and must support IPng if they're serving IPng hosts." Serving in this context means providing routing between two IPxx networks, whether two private nets, one private and one public, or two public providers. ] 4. When no more old hosts addresses are assigned. Old hosts will ] continue to support existing systems to new IPng systems with ] Gateways. ] ] 5. Host software vendors should continue to have IPng and IPv4 stack ] capability, even after no more IPv4 Host Addresses are assigned. ] This is so new existing systems can replace old obsolete systems ] and retain their addresses. The cost to Hosts is minimal compared ] to the simplicity all of this brings to the operations procedures ] and cost of education of a more complex method. "Vendors are advised to ship IPng because [see below], and advised to ship IPv4 because many customers require it." Reasons that could be used as "IPng motivation" include: o Because it autoconfigures itself on the network. o Because it autoconfigures itself on the network _by default_. o Because it supports wonderful new resource allocation models. o Because customers can get IPng addresses but can't get IPv4 addresses. o Becuase IPng has strong security. o Because there's an IPng Internet out there, complete with mail, ftp, telnet, gopher, wais, www, and news gateways. /John From ericf@atc.boeing.com Mon Dec 20 12:34:36 1993 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA27088 for ; Mon, 20 Dec 1993 15:35:04 -0500 Received: by atc.boeing.com (5.57) id AA15901; Mon, 20 Dec 93 12:34:36 -0800 Date: Mon, 20 Dec 93 12:34:36 -0800 From: Eric Fleischman Message-Id: <9312202034.AA15901@atc.boeing.com> To: bound@zk3.dec.com Subject: Re: Ross Callon's draft Cc: ericf, ipng@cmf.nrl.navy.mil Jim, I don't know if you are still interested, but here is a response to a query which you sent me last week. (I'm a bit behind just now.) Also, several years ago I wrote a paper entitled "OSI Self-Defining Networks" which emphatically concurs with what you said to the SIPP group about auto-addressing needing auto-registration to be complete. If you are interested, please give me your US postal address and I'll send you a hard-copy. > I don't believe anyone is opposing local addresses. What I think may be > happening as a group is we are questioning whether stating this will > give the impression that Security should be maintained this way. In > addition we may want to allude the other possibilities and options > available for nodes not using local addresses. I think firewalls are a > good thing too. > > Is this unreasonable. It is reasonable. However, I believe that one of the best lifetime extension approaches is the use of Local Addresses and that should be a priority of the ALE group to further. > > I agree I cannot think of any end user who would not want local addresses. > I have to connect with a lot of large fortune 100 end users often and they > all want our firewalls if they find reasons at all to have Internet access. > But, I also see what Steve is saying regarding local addresses. I > assume your are convinced that local addresses do provide enough > security, from a technical perspective? > > Would you still use firewalls in front of any local address subnet? > Local addresses are a part of a much larger security package. Firewalls must still be maintained. Just because one uses addresses which are theoretically not accessible from the Internet does not stop outsiders from compromising Internet available internal nodes and from them accessing any and all locally addressed nodes. One of the best part of local addresses is that it finally gives users an opportunity to do something "legal" without the NIC -- or some other outside "authority" -- looking over our shoulder and criticizing how we are using our allocated addresses-- or threatening us by some of the other schemas the ALE group is chartered to investigate. > Anyway that was a good reality sandwich. And I am not a researcher I > am an engineer and always open to reality. Would like to be researcher > someday in fact a Mad Computer Scientist in New England would be great. > > /jim Sincerely yours, --Eric Fleischman From ericf@atc.boeing.com Mon Dec 20 12:34:36 1993 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA03783 for ; Mon, 20 Dec 1993 16:28:16 -0500 Received: by atc.boeing.com (5.57) id AA15901; Mon, 20 Dec 93 12:34:36 -0800 Date: Mon, 20 Dec 93 12:34:36 -0800 From: Eric Fleischman Message-Id: <9312202034.AA15901@atc.boeing.com> To: bound@zk3.dec.com Subject: Re: Ross Callon's draft Cc: ericf, ipng@cmf.nrl.navy.mil Jim, I don't know if you are still interested, but here is a response to a query which you sent me last week. (I'm a bit behind just now.) Also, several years ago I wrote a paper entitled "OSI Self-Defining Networks" which emphatically concurs with what you said to the SIPP group about auto-addressing needing auto-registration to be complete. If you are interested, please give me your US postal address and I'll send you a hard-copy. > I don't believe anyone is opposing local addresses. What I think may be > happening as a group is we are questioning whether stating this will > give the impression that Security should be maintained this way. In > addition we may want to allude the other possibilities and options > available for nodes not using local addresses. I think firewalls are a > good thing too. > > Is this unreasonable. It is reasonable. However, I believe that one of the best lifetime extension approaches is the use of Local Addresses and that should be a priority of the ALE group to further. > > I agree I cannot think of any end user who would not want local addresses. > I have to connect with a lot of large fortune 100 end users often and they > all want our firewalls if they find reasons at all to have Internet access. > But, I also see what Steve is saying regarding local addresses. I > assume your are convinced that local addresses do provide enough > security, from a technical perspective? > > Would you still use firewalls in front of any local address subnet? > Local addresses are a part of a much larger security package. Firewalls must still be maintained. Just because one uses addresses which are theoretically not accessible from the Internet does not stop outsiders from compromising Internet available internal nodes and from them accessing any and all locally addressed nodes. One of the best part of local addresses is that it finally gives users an opportunity to do something "legal" without the NIC -- or some other outside "authority" -- looking over our shoulder and criticizing how we are using our allocated addresses-- or threatening us by some of the other schemas the ALE group is chartered to investigate. > Anyway that was a good reality sandwich. And I am not a researcher I > am an engineer and always open to reality. Would like to be researcher > someday in fact a Mad Computer Scientist in New England would be great. > > /jim Sincerely yours, --Eric Fleischman From ericf@atc.boeing.com Mon Dec 20 12:34:36 1993 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA28837 for ; Mon, 20 Dec 1993 15:56:24 -0500 Received: by atc.boeing.com (5.57) id AA15901; Mon, 20 Dec 93 12:34:36 -0800 Date: Mon, 20 Dec 93 12:34:36 -0800 From: Eric Fleischman Message-Id: <9312202034.AA15901@atc.boeing.com> To: bound@zk3.dec.com Subject: Re: Ross Callon's draft Cc: ericf, ipng@cmf.nrl.navy.mil Jim, I don't know if you are still interested, but here is a response to a query which you sent me last week. (I'm a bit behind just now.) Also, several years ago I wrote a paper entitled "OSI Self-Defining Networks" which emphatically concurs with what you said to the SIPP group about auto-addressing needing auto-registration to be complete. If you are interested, please give me your US postal address and I'll send you a hard-copy. > I don't believe anyone is opposing local addresses. What I think may be > happening as a group is we are questioning whether stating this will > give the impression that Security should be maintained this way. In > addition we may want to allude the other possibilities and options > available for nodes not using local addresses. I think firewalls are a > good thing too. > > Is this unreasonable. It is reasonable. However, I believe that one of the best lifetime extension approaches is the use of Local Addresses and that should be a priority of the ALE group to further. > > I agree I cannot think of any end user who would not want local addresses. > I have to connect with a lot of large fortune 100 end users often and they > all want our firewalls if they find reasons at all to have Internet access. > But, I also see what Steve is saying regarding local addresses. I > assume your are convinced that local addresses do provide enough > security, from a technical perspective? > > Would you still use firewalls in front of any local address subnet? > Local addresses are a part of a much larger security package. Firewalls must still be maintained. Just because one uses addresses which are theoretically not accessible from the Internet does not stop outsiders from compromising Internet available internal nodes and from them accessing any and all locally addressed nodes. One of the best part of local addresses is that it finally gives users an opportunity to do something "legal" without the NIC -- or some other outside "authority" -- looking over our shoulder and criticizing how we are using our allocated addresses-- or threatening us by some of the other schemas the ALE group is chartered to investigate. > Anyway that was a good reality sandwich. And I am not a researcher I > am an engineer and always open to reality. Would like to be researcher > someday in fact a Mad Computer Scientist in New England would be great. > > /jim Sincerely yours, --Eric Fleischman From ericf@atc.boeing.com Mon Dec 20 12:34:36 1993 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA08413 for ; Mon, 20 Dec 1993 17:00:33 -0500 Received: by atc.boeing.com (5.57) id AA15901; Mon, 20 Dec 93 12:34:36 -0800 Date: Mon, 20 Dec 93 12:34:36 -0800 From: Eric Fleischman Message-Id: <9312202034.AA15901@atc.boeing.com> To: bound@zk3.dec.com Subject: Re: Ross Callon's draft Cc: ericf, ipng@cmf.nrl.navy.mil Jim, I don't know if you are still interested, but here is a response to a query which you sent me last week. (I'm a bit behind just now.) Also, several years ago I wrote a paper entitled "OSI Self-Defining Networks" which emphatically concurs with what you said to the SIPP group about auto-addressing needing auto-registration to be complete. If you are interested, please give me your US postal address and I'll send you a hard-copy. > I don't believe anyone is opposing local addresses. What I think may be > happening as a group is we are questioning whether stating this will > give the impression that Security should be maintained this way. In > addition we may want to allude the other possibilities and options > available for nodes not using local addresses. I think firewalls are a > good thing too. > > Is this unreasonable. It is reasonable. However, I believe that one of the best lifetime extension approaches is the use of Local Addresses and that should be a priority of the ALE group to further. > > I agree I cannot think of any end user who would not want local addresses. > I have to connect with a lot of large fortune 100 end users often and they > all want our firewalls if they find reasons at all to have Internet access. > But, I also see what Steve is saying regarding local addresses. I > assume your are convinced that local addresses do provide enough > security, from a technical perspective? > > Would you still use firewalls in front of any local address subnet? > Local addresses are a part of a much larger security package. Firewalls must still be maintained. Just because one uses addresses which are theoretically not accessible from the Internet does not stop outsiders from compromising Internet available internal nodes and from them accessing any and all locally addressed nodes. One of the best part of local addresses is that it finally gives users an opportunity to do something "legal" without the NIC -- or some other outside "authority" -- looking over our shoulder and criticizing how we are using our allocated addresses-- or threatening us by some of the other schemas the ALE group is chartered to investigate. > Anyway that was a good reality sandwich. And I am not a researcher I > am an engineer and always open to reality. Would like to be researcher > someday in fact a Mad Computer Scientist in New England would be great. > > /jim Sincerely yours, --Eric Fleischman From bound@zk3.dec.com Mon Dec 20 16:10:37 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA07719 for ; Mon, 20 Dec 1993 16:39:33 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA05694; Mon, 20 Dec 93 13:10:51 -0800 Received: by xirtlu.zk3.dec.com; id AA14598; Mon, 20 Dec 1993 16:10:46 -0500 Message-Id: <9312202110.AA14598@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil Subject: Re: Ross Callon's draft In-Reply-To: Your message of "Mon, 20 Dec 93 12:34:36 PST." <9312202034.AA15901@atc.boeing.com> Date: Mon, 20 Dec 93 16:10:37 -0500 X-Mts: smtp Eric, Thanks .. Yes I would like to see that paper. Best to send me snail mail at the following: Jim Bound P.O. Box 570 Hollis, NH 03049 As far as local addresses, your need and mail convinced me, and John Currans follow-up, and another Fortune 100 company I spoke with that if you want them the Internet should make it possible. I am going to go along with the group and Steves consultation on this one. I haven't figured out yet what I am going along with yet, so if someone knows let me know. take care, /jim From bound@zk3.dec.com Mon Dec 20 16:43:30 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA08157 for ; Mon, 20 Dec 1993 16:49:22 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA07462; Mon, 20 Dec 93 13:43:40 -0800 Received: by xirtlu.zk3.dec.com; id AA15516; Mon, 20 Dec 1993 16:43:37 -0500 Message-Id: <9312202143.AA15516@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com Subject: Clearing Up PhIV and PhV as compared to IPng Date: Mon, 20 Dec 93 16:43:30 -0500 X-Mts: smtp Colleagues, Sorry for using this at the roundtable I will keep track of rumors I hear for our next telechat, I certainly hear enough of them. Clearly Phase IV to Phase V had some translation, and if we can learn from that regarding what is painful about network address translation as a body, who needs as much past experience as possible to reach our destiny, this is a positive thing to do. I will work off line with Dino and Ross to determine what that knowledge is and I have access to the architects who had to define it in Digital, whom can perform a second logic check on my end. What I find hard to hear is IPng Transition is like Ph IV to Ph V and then generic comments. As Allison pointed out it is true all pieces of the Host software are effected by IPng, which I had sent out. But, in the case of IPng you can look at the effect to IPv4 Host software as an isosceles triangle. The base of the triangle is the data dependent link layer, like ARP, and the angle opposite the base of the triangle (the point) the application layer like FTP or the new gethostbyname() library call all IPngs' will have to propose. In the case of DECnet to OSI it was more like a rectangle. The changes were mostly equal and complex at each layer of the OSI model. The code changes to TCP/UDP because of IPng are mimimal compared to replacing NSP with TP0-5 (not really all of them). In the case of the application layer for IPng we will just need to add a few options to the sockets and alter a few library routines and we are off and running. The OSI model does not have just an application layer it has a Session, Presenation, and Application layer. These all in most cases have to be absorbed to support an OSI stack, though you can do interesting things at the Session to avoid some pain. As far as embedded IPv4 addresses there is only one culprit and that is FTP, fortuneately for the Internet and those of us who have to build IPng Host Software some day. take care, /jim From dino@cisco.com Mon Dec 20 14:12:23 1993 Return-Path: dino@cisco.com Received: from regal.cisco.com (regal.cisco.com [131.108.13.57]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA08504 for ; Mon, 20 Dec 1993 17:16:26 -0500 Received: by regal.cisco.com id AA20187 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Mon, 20 Dec 1993 14:12:23 -0800 Date: Mon, 20 Dec 1993 14:12:23 -0800 From: Dino Farinacci Message-Id: <199312202212.AA20187@regal.cisco.com> To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Mon, 20 Dec 93 16:43:30 -0500 <9312202143.AA15516@xirtlu.zk3.dec.com> Subject: Clearing Up PhIV and PhV as compared to IPng >> What I find hard to hear is IPng Transition is like Ph IV to Ph V and >> then generic comments. As Allison pointed out it is true all pieces of >> the Host software are effected by IPng, which I had sent out. But, in the >> case of IPng you can look at the effect to IPv4 Host software as an >> isosceles triangle. The base of the triangle is the data dependent link >> layer, like ARP, and the angle opposite the base of the triangle (the >> point) the application layer like FTP or the new gethostbyname() library >> call all IPngs' will have to propose. In the case of DECnet to OSI it was >> more like a rectangle. The changes were mostly equal and complex at each >> layer of the OSI model. The code changes to TCP/UDP because of IPng are >> mimimal compared to replacing NSP with TP0-5 (not really all of them). >> In the case of the application layer for IPng we will just need to add a >> few options to the sockets and alter a few library routines and we are >> off and running. The OSI model does not have just an application layer >> it has a Session, Presenation, and Application layer. These all in >> most cases have to be absorbed to support an OSI stack, though you can >> do interesting things at the Session to avoid some pain. I believe it is is more diffcult to convert a DECNET Phase IV host to DECNET Phase V, than it is to convert an IPv4 host to IPng. I think it will be more difficult for a router to translate an IPv4 packet to an IPng packet than a router to translate a Phase IV packet to a Phase V packet. I see the issue in managing the address mapping. (Not to mention performance :-(). The reason I say the latter is due to the generality of topologies and the smorgasboard of routing protocols we have to deal with in IP. DECNET restricted Phase IV and Phase V clouds to area boundaries, therefore allowing prefix redistribution to be trivial (i.e. a converting router would be required to have an area address which matched the Phase IV area it was translating to). So the redistribution of routing information can from 1) the adjacency database or 2) the level-1 routing table. Due to this restriction we find many customers (in different OSI routing domains) that cannot really do DECNET conversion. This is one of the reasons for having prefix 47.0020 be the *global* DECNET conversion prefix. If Rob or Steve can enlighten me how one can use a single prefix and support a general topology, I am all ears. If it is similar to 47.0020, you have to multi-home all your "newer protocol" systems with a 1) new address and 2) conversion address. Is this what you have in mind? Details please. Dino From mak@merit.edu Mon Dec 20 23:51:48 1993 Return-Path: mak@merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA09662 for ; Mon, 20 Dec 1993 23:50:56 -0500 Received: by merit.edu (5.65/1123-1.0) id AA27796; Mon, 20 Dec 93 23:51:49 -0500 Message-Id: <9312210451.AA27796@merit.edu> To: ipng@cmf.nrl.navy.mil Subject: private IP network numbers (PINNs) Date: Mon, 20 Dec 1993 23:51:48 -0500 From: Mark Knopper Hi. Sorry I couldn't make it for today's call. I've caught up on the ipng list mail (does the list still work--I've gotten a bunch of duplicates). I will send the current list of TUBA docs out tomorrow. I thought you would be interested in this discussion I raised within the Merit routing engineers group. Mark > From: John Scudder > To: "Mark Knopper" > CC: merit-ie@merit.edu > Mark sez: > >Hi. On the IPng Directorate list we have been discussing > >the possibility of having the NIC assign some number of > >class A, B, and C numbers for private use only. These > >numbers should only be used for private nets, i.e. those > >nets which do not wish to have global Internet connectivity. > >For example, a company may have 10 million electric meters > >which need to communicate with a few computers. > > > >Here is my question: Can this scheme have an impact on > >global routing, say if networks "leaked" these private > >nets out on various backbones? Presumably there are things > >that the routing registries can do to help. But what are > >the potential negative effects and how likely are bad > >things to happen as a result of this? > > My knee-jerk answer is that as long as said networks are guaranteed to > never have global significance, this is fine. The worst thing I can > think of is the following scenario: > > 1. Detroit Edison uses net 4.0.0.0 for electric meter telemetry. > 2. Ameritech :-) uses net 4.0.0.0 for telephone pole telemetry. > 3. Detroit Ed starts leaking 4.0.0.0 into the Internet. > 4. Ameritech hears 4.0.0.0 from external routing and prefers it to their > internal 4.0.0.0. > 5. Result: Ameritech loses phone pole telemetry. > > Two things (at least) have to broken for badness to result here: > First, Detroit Ed has to leak 4.0.0.0 out. Second, Ameritech has to > accept it AND prefer it. Also, the intermediate fabric has to accept > it and propagate it. > > I think that we can assume that parties using "reserved" net numbers > are consenting adults who will protect themselves from such a scenario > or accept the consequences. Also, the intermediate providers should > reject all "reserved" nets by default. In fact, it might be good to > update the Router Requirements RFC to say that all routers' > inter-domain routing should reject "reserved" nets by default. (This > could at least be an implementor's agreement.) > > I think that this is a registration issue, but more IANA than RA, since > I assume that the list of "reserved" nets, once selected, will be > static. I guess one thing the RA should do is monitor for and track > down people leaking reserved nets into the global routing. > > --John From brian@dxcoms.cern.ch Tue Dec 21 08:30:03 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA09987 for ; Tue, 21 Dec 1993 02:30:14 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24457; Tue, 21 Dec 1993 08:30:07 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11424; Tue, 21 Dec 1993 08:30:04 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312210730.AA11424@dxcoms.cern.ch> Subject: Re: Clearing Up PhIV and PhV as compared to IPng To: ipng@cmf.nrl.navy.mil Date: Tue, 21 Dec 1993 08:30:03 +0100 (MET) In-Reply-To: <199312202212.AA20187@regal.cisco.com> from "Dino Farinacci" at Dec 20, 93 02:12:23 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 651 >--------- Text sent by Dino Farinacci follows: ... > I believe it is is more diffcult to convert a DECNET Phase IV host > to DECNET Phase V, than it is to convert an IPv4 host to IPng. Why? All you do is install the latest version of DECnet and you get it. The tricky bit is the routing infrastructure and DECdns. > > I think it will be more difficult for a router to translate an IPv4 > packet to an IPng packet than a router to translate a Phase IV packet > to a Phase V packet. I see the issue in managing the address mapping. Yes. But read CATNIP closely - I think that shows there is at least one way to do it. Brian From brian@dxcoms.cern.ch Tue Dec 21 08:34:38 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA09999 for ; Tue, 21 Dec 1993 02:34:45 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27987; Tue, 21 Dec 1993 08:34:39 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11613; Tue, 21 Dec 1993 08:34:38 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312210734.AA11613@dxcoms.cern.ch> Subject: Re: Clearing Up PhIV and PhV as compared to IPng To: ipng@cmf.nrl.navy.mil Date: Tue, 21 Dec 1993 08:34:38 +0100 (MET) In-Reply-To: <9312202143.AA15516@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Dec 20, 93 04:43:30 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 652 >--------- Text sent by bound@zk3.dec.com follows: ... > As far as embedded IPv4 addresses there is only one culprit and that is > FTP, fortuneately for the Internet and those of us who have to build > IPng Host Software some day. > Unfortunately not true. There are lots of applications out here with 32 bit fields containing IPv4 addresses. FTP just tends to show it to you, that's all. I am particularly concerned about X11; I don't know anything about X11 internals but there just have to be problems there. Also Kerberos. I even wonder whether this topic doesn't need a WG, or at least a serious look by Dave Crocker or somebody else. Brian From bound@zk3.dec.com Tue Dec 21 09:57:05 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA02220 for ; Tue, 21 Dec 1993 11:03:42 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA28867; Tue, 21 Dec 93 06:57:18 -0800 Received: by xirtlu.zk3.dec.com; id AA00493; Tue, 21 Dec 1993 09:57:11 -0500 Message-Id: <9312211457.AA00493@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Clearing Up PhIV and PhV as compared to IPng In-Reply-To: Your message of "Tue, 21 Dec 93 08:30:03 +0100." <9312210730.AA11424@dxcoms.cern.ch> Date: Tue, 21 Dec 93 09:57:05 -0500 X-Mts: smtp Brian, **************** >--------- Text sent by Dino Farinacci follows: ... > I believe it is is more diffcult to convert a DECNET Phase IV host > to DECNET Phase V, than it is to convert an IPv4 host to IPng. Why? All you do is install the latest version of DECnet and you get it. The tricky bit is the routing infrastructure and DECdns. ****************** But, the intent of the original message from me was to point out the vast difference in engineering scope between actually engineering a Host (writing the code and algorithms) from PhIV to PhV vs. IPv4 to IPng. My triangle vs rectangle was an engineering effort comparison not an installation comparison. These are two different discussions. I just wanted to make this clear from your response to keep the track of the development side of IPng. **************** > > I think it will be more difficult for a router to translate an IPv4 > packet to an IPng packet than a router to translate a Phase IV packet > to a Phase V packet. I see the issue in managing the address mapping. Yes. But read CATNIP closely - I think that shows there is at least one way to do it. ******************* Could you elaborate on this or Rob in detail I don't see it, nor can I see it from the present document and I have not seen any discussion of this on the CATNIP mailing list? But, this response is to terse for me and I could use a more verbose discussion. thanks /jim From bound@zk3.dec.com Tue Dec 21 10:13:31 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA02211 for ; Tue, 21 Dec 1993 11:01:41 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA29812; Tue, 21 Dec 93 07:13:40 -0800 Received: by xirtlu.zk3.dec.com; id AA00984; Tue, 21 Dec 1993 10:13:37 -0500 Message-Id: <9312211513.AA00984@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Clearing Up PhIV and PhV as compared to IPng In-Reply-To: Your message of "Tue, 21 Dec 93 08:34:38 +0100." <9312210734.AA11613@dxcoms.cern.ch> Date: Tue, 21 Dec 93 10:13:31 -0500 X-Mts: smtp Brian, ********************* >--------- Text sent by bound@zk3.dec.com follows: ... > As far as embedded IPv4 addresses there is only one culprit and that is > FTP, fortuneately for the Internet and those of us who have to build > IPng Host Software some day. > Unfortunately not true. There are lots of applications out here with 32 bit fields containing IPv4 addresses. FTP just tends to show it to you, that's all. *********************** Its true based on a lot of analysis and maybe un-true for kerberos, which is vastly used at least in the U.S. so a concern to that set of folks. We must not confuse applications that use IPv4 addresses and those that embed IPv4 addresses in the actual datagram, which FTP does. Here is a good explanation from the most recent IPAE document on this discussion. Hopefully it will make my previous statement "fortuneately true" again. But I am open to hearing why not? (Other respones to your questions after the IPv4 analysis block of text). ---------------------------------------------------------------------- >From IPAE present doc section 6.6 INTERNET-DRAFT IPAE Specification November 1993 There are many application protocols layered above TCP and UDP. Some of them carry IPv4 addresses as part of their protocol. We have examined the most popular application layer protocols, considering for each how IPAE hosts would interoperate with IPv4 hosts, and with each other, using these protocols. In this section, we specify how IPAE hosts should use existing application protocols. This section addresses only application layer protocols. The internet routing protocols, control protocols, transport protocols, or layering (e.g. IP over appletalk) protocols which carry IPv4 addresses are specific to IPv4 and would not require any change for IPAE. SIPP versions may be developed, but that will be addressed in other documents. The application protocols that we analyzed fell into four categories: 1) Application protocols that do not carry embedded IPv4 addresses. These protocols can be used immediately between IPAE and IPv4 systems and between IPAE systems. They require no change. 2) Application protocols that carry IPv4 addresses, but the protocol or its use of IPv4 addresses is obsolete. These protocols do not need to be changed. They can continue to be used between IPAE and IPv4 systems and between IPAE systems indefinitely. 3) Application protocols that carry IPv4 addresses, but that are used exclusively by IPv4 systems, or the IPv4 parts of IPAE systems. These protocols also do not need to be changed, although new versions of them may be necessary in order to support the same function in SIPP and IPAE systems. 4) Application protocols that carry IPv4 addresses, but that are not IPv4 specific. Only one protocol, FTP, fell into this category. FTP provides its full functionallity when used between IPv4 and IPAE systems, and that provide a subset of that functionallity when used among IPAE systems. It will have to be extended in order to provide its full functionallity among SIPP and IPAE systems. Most of the application layer protocols that we examined fell into the first category. These protocols, which require no change at all to be used between IPAE and IPv4 systems, are: Telnet (RFC 854, RFC 855) SMTP (RFC 821) TFTP (RFC 1350) BSD "rlogin" protocol (RFC 1282) BSD "rsh" protocol (note: passes port number, bug not IP addr) BSD "biff" protocol (in.comsat) BSD "lpr" protocol (RFC 1179) BSD "syslog" protocol ONC RPC protocol (RFC 1057) ONC original "portmap" protocol (documented in RFC 1057) ONC+ new "rpcbind" protocol (replaces portmap) Echo - TCP and UDP (RFC 862) Discard - TCP and UDP (RFC 863) Chargen - TCP and UDP (RFC 864) Quote of the Day - TCP and UDP (RFC 865) Active users - TCP or UDP (RFC 866) Daytime - TCP or UDP (RFC 867) Time - TCP or UDP (RFC 868) Nicname/Whois (RFC 954) Finger (RFC 1288) DNS mail routing (RFC 974) SNMP (RFC 1157) POP3 (RFC 1225) Concise-MIB (RFC 1212) Content type mail header field (RFC 1049) MIME (RFC 1341) NNTP (RFC 977) BSD "rexec" protocol NTP (RFC 1119) NFS A few protocols fell into the second category. These protocols -- which carry IPv4 addresses, but do not need to be changed because their use of IPv4 is obsolete -- are: Mail (RFC 822) BSD "talk" protocol More protocols fell into the third category. They are used only by IPv4 systems, and may need to be revised in order to provide a similar function between SIPP systems: SMI (RFC 1155) MIB-II (RFC 1213) IP Forwarding table MIB (RFC 1354) RARP (RFC 903) BOOTP (RFC 951, RFC 1084) DHCP (RFC 1531) PPP IP address negotiation options ONC "bootparams" RPC protocol DNS (RFC 1034, RFC 1035) The one protocol in the fourth category, which will need to be extended in order to provide full functionallity to SIPP systems, is: FTP (RFC 959) We did not have enough information to evaluate two application protocols: Kerberos (Where are the complete protocol spec?) Telnet options (Is there a complete list of all options?) The remainder of this section discusses how IPAE systems should use the IPv4 address carrying application protocols. --------------------------------------------------------------------- ********************************* I am particularly concerned about X11; I don't know anything about X11 internals but there just have to be problems there. Also Kerberos. ********************************* I will get this into our X11 experts. From my knowledge this should not be happening at the X11 library calls, which developers use to build applications. It might take place at the X11-Server on each machine during connection set up, but that should be transparent to the X11 application interface. The X11-Server may need to manipulate the IPv4 address on entry into the client or server just like an if_fddi or if_ether module would in an OS kernel, which will be handled by any IPng at the link layer as part of an IPngs' code base. I will check and get back to the Directorate. ****************************** I even wonder whether this topic doesn't need a WG, or at least a serious look by Dave Crocker or somebody else. Brian ***************************** Dave Crocker will point to IPAE is my guess, as this has been looked at in depth by the SIPP Working Group. If we can avoid more IPng WGs we should, IPAE has done a lot of work here. /jim From bound@zk3.dec.com Tue Dec 21 11:42:59 1993 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA02909 for ; Tue, 21 Dec 1993 12:39:17 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA04550; Tue, 21 Dec 93 08:43:06 -0800 Received: by xirtlu.zk3.dec.com; id AA03313; Tue, 21 Dec 1993 11:43:04 -0500 Message-Id: <9312211643.AA03313@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com Subject: X11 response Date: Tue, 21 Dec 93 11:42:59 -0500 X-Mts: smtp This is from Jim Gettys one of the orginal authors and engineers of X. I will also contact Bob Scheifler, too as Jim suggested. At this point my analysis to Brian was correct. See attached. I stripped the headers. Jim works for us at our Cambridge Research Lab. /jim ------------------------- Subject: Re: Is X11 effected by IPv4 address change? Date: Tue, 21 Dec 93 11:20:37 -0500 1) I expect no changes will be required for normal X11 programs. 2) I expect minor changes will be required in the X library and server, to deal with larger addresses. But X already deals with multiple address families with differing address lengths, as it runs over multiple transports already; this stuff is pretty well modularized. Most of this stuff is hidden (by design) from X clients; for example: /* * Data structure for host setting; getting routines. * */ typedef struct { int family; /* for example FamilyInternet */ int length; /* length of address, in bytes */ char *address; /* pointer to where to find the bytes */ } XHostAddress; Note that not only the address family is included in the API data structure, but the length of the address; one could distinguish IPv4 addresses strictly by length. I'd be amazed if the changes take more than a few days total, if significant changes are required at all. But you'd be best off talking to Bob Scheifler at 617-374-1227, if you are asking on the behalf of the IETF; Bob is a network wizard as well as a window system wizard, and can give you the definitive word. - Jim GEttys --------------------------------------- From brian@dxcoms.cern.ch Tue Dec 21 17:43:27 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA02562 for ; Tue, 21 Dec 1993 11:43:20 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26450; Tue, 21 Dec 1993 17:43:28 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA25967; Tue, 21 Dec 1993 17:43:27 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312211643.AA25967@dxcoms.cern.ch> Subject: Re: Clearing Up PhIV and PhV as compared to IPng To: ipng@cmf.nrl.navy.mil Date: Tue, 21 Dec 1993 17:43:27 +0100 (MET) In-Reply-To: <9312211457.AA00493@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Dec 21, 93 09:57:05 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2011 >--------- Text sent by bound@zk3.dec.com follows: > > Brian, > > **************** > >--------- Text sent by Dino Farinacci follows: > ... > > I believe it is is more diffcult to convert a DECNET Phase IV host > > to DECNET Phase V, than it is to convert an IPv4 host to IPng. > > Why? All you do is install the latest version of DECnet and you get it. > The tricky bit is the routing infrastructure and DECdns. > ****************** > > But, the intent of the original message from me was to point out the vast > difference in engineering scope between actually engineering a Host (writing > the code and algorithms) from PhIV to PhV vs. IPv4 to IPng. My triangle vs > rectangle was an engineering effort comparison not an installation > comparison. These are two different discussions. I just wanted to make this > clear from your response to keep the track of the development side of IPng. Yes, I was thinking about it from the viewpoint of a user site. > > **************** > > > > I think it will be more difficult for a router to translate an IPv4 > > packet to an IPng packet than a router to translate a Phase IV packet > > to a Phase V packet. I see the issue in managing the address mapping. > > Yes. But read CATNIP closely - I think that shows there is at least > one way to do it. > ******************* > > Could you elaborate on this or Rob in detail I don't see it, nor can I > see it from the present document and I have not seen any discussion of > this on the CATNIP mailing list? But, this response is to terse for me > and I could use a more verbose discussion. > I leave this to the CATNIP expert. However remember that Francis Dupont has already implemented IPv4 to TUBA translation: another proof that such things are possible. BTW: CERN closes for Christmas tomorrow (Wednesday) lunchtime, so I will be off net until January 6th. (IP transit through CERN stays up, we hope, and mail will be queued, we hope.) Season's greetings, etc. Brian From brian@dxcoms.cern.ch Tue Dec 21 18:00:25 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA02672 for ; Tue, 21 Dec 1993 12:00:18 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00791; Tue, 21 Dec 1993 18:00:26 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26491; Tue, 21 Dec 1993 18:00:25 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312211700.AA26491@dxcoms.cern.ch> Subject: Re: Clearing Up PhIV and PhV as compared to IPng To: ipng@cmf.nrl.navy.mil Date: Tue, 21 Dec 1993 18:00:25 +0100 (MET) In-Reply-To: <9312211513.AA00984@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Dec 21, 93 10:13:31 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 728 Jim, The IPAE analysis is very interesting (I kept quiet yesterday, but I am not on the SIPP list: I just don't have time). However: it addresses the question of protocols carrying embedded IPv4 addresses, but not (if I read it right) that of application software handling IPv4 addresses internally. Don't you have to modify every piece of code that calls gethostbyname? This is a potential manpower sink for vendors and users surely? (I hate to say it, but I understood that this was a major issue in the late release of DECnet/OSI. DECnet IV addresses fit in 16 bits and CLNP addresses don't...) Will look forward to any analysis of impact on X11 and Kerberos. And I just thought of AFS, that needs checking too. Brian From bound@zk3.dec.com Tue Dec 21 23:50:26 1993 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 (8.6.4/8.6.4) with SMTP id XAA02116 for ; Tue, 21 Dec 1993 23:54:34 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA07800; Tue, 21 Dec 93 20:50:36 -0800 Received: by xirtlu.zk3.dec.com; id AA15038; Tue, 21 Dec 1993 23:50:33 -0500 Message-Id: <9312220450.AA15038@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Clearing Up PhIV and PhV as compared to IPng In-Reply-To: Your message of "Tue, 21 Dec 93 18:00:25 +0100." <9312211700.AA26491@dxcoms.cern.ch> Date: Tue, 21 Dec 93 23:50:26 -0500 X-Mts: smtp Brian, >The IPAE analysis is very interesting (I kept quiet yesterday, >but I am not on the SIPP list: I just don't have time). > >However: it addresses the question of protocols carrying >embedded IPv4 addresses, but not (if I read it right) >that of application software handling IPv4 addresses internally. >Don't you have to modify every piece of code that calls >gethostbyname? No, because there will be a new gethostbyname for IPng. This will let old IPv4 apps continue on as they do now. When you want to use IPng you use the new gethostbyname. Both SIPP and TUBA have proposed this. There was just a discussion of this on the SIPP list I will send you private copy as it appears all others from the con call are on the SIPP list, except for those not present at the telechat I did not hear a response to that question for in the call. >This is a potential manpower sink for vendors and users >surely? (I hate to say it, but I understood that this >was a major issue in the late release of DECnet/OSI. DECnet IV >addresses fit in 16 bits and CLNP addresses don't...) Not really, but it cannot be totally transparent unfortuneately in IPng. It can be kept to a minimum. The issue with DECdns was completely different it had to do with what is known as Towers protocol approach and is a Digital implementation. But, that did not cause the problem. It was building a complete DECdns for the client and it took time. That was fixed some time ago though. This will add no value for us to understand as BIND DNS is a completely different species so to speak. The Digital APIs for this access are proprietary and the ones for IPng cannot be, cause they exist today and must be extended. >Will look forward to any analysis of impact on X11 and >Kerberos. And I just thought of AFS, that needs checking too. I already have started on AFS too because of OSF DCE fyi. Maybe Steve can add comments regarding kerberos. A point here to be aware of is that what FTP did is an annomaly in the Open Systems arena. I highly doubt I will find that in AFS (incubated at CMU) it was built at the applications layer to take inherent knowledge of IPv4 addresses or UNIX Process IDs or anything that would reduce portability for multivendor distributed computing. As was seen in the X11 response even at the low level interfaces to the X-Server care was taken to remain portable at least at the source level. This is a priori engineering consideration when building Open Systems that also are going to operate as peers with multivendor implementations. /jim From brian@dxcoms.cern.ch Wed Dec 22 08:13:47 1993 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard (8.6.4/8.6.4) with SMTP id CAA02452 for ; Wed, 22 Dec 1993 02:13:22 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10579; Wed, 22 Dec 1993 08:13:48 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09067; Wed, 22 Dec 1993 08:13:47 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312220713.AA09067@dxcoms.cern.ch> Subject: Re: Clearing Up PhIV and PhV as compared to IPng To: ipng@cmf.nrl.navy.mil Date: Wed, 22 Dec 1993 08:13:47 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1349 Jim, ... > >Don't you have to modify every piece of code that calls > >gethostbyname? > > No, because there will be a new gethostbyname for IPng. This will let > old IPv4 apps continue on as they do now. When you want to use IPng you > use the new gethostbyname. Both SIPP and TUBA have proposed this. ... Thanks for all these clarifications. My understanding now is that all applications will (at a minimum) have to be relinked to use the new gethostbyname. It's good news if all the major distributed computing applications are well engineered so that any address type and size can be handled, but at least a new release will be needed. And it must be true that any application foolish enough to manipulate IP addresses in 32 bit integers will have to be modified. And there ARE certainly foolish applications out here in the Internet. (I know there is the trick of using a 32 bit handle for an IPng address but I find it hard to believe this is a universal solution, if people have written code that looks inside an IPv4 address.) What I am getting at is that even with a SIN/dual stack transition (which I agree is the simplest one to engineer), there is a major problem in the transition of getting everybody who ships any kind of application to ship a relinked or modified version at the right time for each particular host. - Brian From minshall@wc.novell.com Wed Dec 22 12:18:29 1993 Return-Path: minshall@wc.novell.com Received: from wc.novell.com (optics.wc.novell.com [130.57.64.11]) by picard (8.6.4/8.6.4) with SMTP id PAA00351 for ; Wed, 22 Dec 1993 15:22:27 -0500 From: minshall@wc.novell.com Received: from [130.57.64.145] by wc.novell.com (4.1/smi4.1.1.v91190) id AA24784; Wed, 22 Dec 93 12:18:32 PST Date: Wed, 22 Dec 93 12:18:29 PST Message-Id: <9312222018.AA24784@wc.novell.com> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil Subject: Re: Clearing Up PhIV and PhV as compared to IPng By the by... At 4:43 PM 12/20/93 -0500, bound@zk3.dec.com wrote: >As far as embedded IPv4 addresses there is only one culprit and that is >FTP, fortuneately for the Internet and those of us who have to build >IPng Host Software some day. I am told that so-called Universal Resource Locators (URLs - Mosaic, www?, etc.) name hosts with either IPv4 addresses or a DNS name. I've only *seen* the latter, but i haven't done much "net surfing". Greg From deering@parc.xerox.com Wed Dec 22 20:04:03 1993 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard (8.6.4/8.6.4) with SMTP id XAA02179 for ; Wed, 22 Dec 1993 23:03:54 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <15201(1)>; Wed, 22 Dec 1993 20:04:32 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 22 Dec 1993 20:04:17 -0800 To: ipng@cmf.nrl.navy.mil Cc: gilligan@eng.sun.com, deering@parc.xerox.com Subject: IPAE spec review Date: Wed, 22 Dec 1993 20:04:03 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Dec22.200417pst.12171@skylark.parc.xerox.com> It turns out that the IPAE spec does not yet include some of the most recent decisions of the SIPP WG, such as the relaxation of the requirement that all translating routers perform prefix mapping. So it seems best to wait until it has been updated (sometime in January) before submitting it for directorate review for clarity and completeness. On the other hand, if people want to get started on doing reviews, the changes to the IPAE spec are expected to be additions, not changes, so any immediate review work would not be wasted. The most recent version of the document can be found in the internet-drafts directories. Steve From deering@parc.xerox.com Wed Dec 22 20:51:24 1993 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard (8.6.4/8.6.4) with SMTP id XAA02280 for ; Wed, 22 Dec 1993 23:50:59 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <15338(2)>; Wed, 22 Dec 1993 20:51:36 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 22 Dec 1993 20:51:29 -0800 To: ipng@cmf.nrl.navy.mil Subject: Re: IPAE spec review In-reply-to: deering's message of Wed, 22 Dec 93 20:04:03 -0800. <93Dec22.200417pst.12171@skylark.parc.xerox.com> Date: Wed, 22 Dec 1993 20:51:24 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Dec22.205129pst.12171@skylark.parc.xerox.com> The name of the IPAE document in the internet-drafts archives is: draft-ietf-sip-ipae-transition-00.txt Steve From bound@zk3.dec.com Thu Dec 23 01:03:45 1993 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 (8.6.4/8.6.4) with SMTP id BAA02486 for ; Thu, 23 Dec 1993 01:03:49 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA03898; Wed, 22 Dec 93 22:03:54 -0800 Received: by xirtlu.zk3.dec.com; id AA09632; Thu, 23 Dec 1993 01:03:51 -0500 Message-Id: <9312230603.AA09632@xirtlu.zk3.dec.com> To: minshall@wc.novell.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Clearing Up PhIV and PhV as compared to IPng In-Reply-To: Your message of "Wed, 22 Dec 93 12:18:29 PST." <9312222018.AA24784@wc.novell.com> Date: Thu, 23 Dec 93 01:03:45 -0500 X-Mts: smtp >At 4:43 PM 12/20/93 -0500, bound@zk3.dec.com wrote: >>As far as embedded IPv4 addresses there is only one culprit and that is >>FTP, fortuneately for the Internet and those of us who have to build >>IPng Host Software some day. >I am told that so-called Universal Resource Locators (URLs - Mosaic, www?, >etc.) name hosts with either IPv4 addresses or a DNS name. I've only >*seen* the latter, but i haven't done much "net surfing". Good heads up.... Well if its names thats OK. Because the routine that does the getname will have to make a decision when getting the address once IPng is in place. But, the address is a hard coded problem and I think different than an embedded address. Its still a problem but a different one. I would like to say that applications that get names are well behaved and an IPng proposal or the IETF needs to make some kind of transition statement for software that operates in this manner. But, when software uses addresses to name things then that is ill-behaved (not meaning bad just it could break for reasons other than IPng). This is a different problem set. Which will need some kind of statement. This is good to know though. I still don't think we need a Working Group for this but this could be one of the deliverables of the Transition Working Group maybe ???? /jim From jcurran@nic.near.net Thu Dec 23 01:34:59 1993 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard (8.6.4/8.6.4) with SMTP id BAA02544 for ; Thu, 23 Dec 1993 01:34:15 -0500 Message-Id: <199312230634.BAA02544@picard> Received: from platinum.near.net by nic.near.net id aa11715; 23 Dec 93 1:35 EST To: ipng@cmf.nrl.navy.mil cc: bound@zk3.dec.com Subject: Re: Clearing Up PhIV and PhV as compared to IPng In-reply-to: Your message of Thu, 23 Dec 1993 01:03:45 -0500. <9312230603.AA09632@xirtlu.zk3.dec.com> Date: Thu, 23 Dec 1993 01:34:59 -0500 From: John Curran -------- ] From: bound@zk3.dec.com ] Subject: Re: Clearing Up PhIV and PhV as compared to IPng ] Date: Thu, 23 Dec 93 01:03:45 -0500 ] ] >I am told that so-called Universal Resource Locators (URLs - Mosaic, www?, ] >etc.) name hosts with either IPv4 addresses or a DNS name. I've only ] >*seen* the latter, but i haven't done much "net surfing". ] ] Good heads up.... ] ] Well if its names thats OK. Because the routine that does the getname ] will have to make a decision when getting the address once IPng is in ] place. But, the address is a hard coded problem and I think different than ] an embedded address. Its still a problem but a different one. ] ] I would like to say that applications that get names are well behaved ] and an IPng proposal or the IETF needs to make some kind of transition ] statement for software that operates in this manner. But, when software ] uses addresses to name things then that is ill-behaved (not meaning bad ] just it could break for reasons other than IPng). This is a different ] problem set. Which will need some kind of statement. I pretty much agree with Jim on this... The URI working group has produced an draft (draft-ietf-uri-url-01.txt) on "Uniform Resource Locators" (URLs). This draft basically provides a simple encoding for the parameters of various access methods (such as ftp, nntp, prospero, etc.) for retrieving information. Uniform Resource locators are a convenient manner by which to pass such information around. As such, the URL draft merely allows IPv4 addresses to be used in URLs as they are used in parameters to the underlying access applications. It might be a good idea for the Transition group to make a statement indicating that any IPng transition will be facilatated by active use of DNS and that increased deployment is encouraged. /John From bound@zk3.dec.com Thu Dec 23 13:46:03 1993 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 (8.6.4/8.6.4) with SMTP id OAA06457 for ; Thu, 23 Dec 1993 14:21:09 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA10921; Thu, 23 Dec 93 10:46:24 -0800 Received: by xirtlu.zk3.dec.com; id AA22331; Thu, 23 Dec 1993 13:46:10 -0500 Message-Id: <9312231846.AA22331@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: X/Open Report on OIW Convegence fyi ... Date: Thu, 23 Dec 93 13:46:03 -0500 X-Mts: smtp One of my other hats I wear is I am the MPTN and network X/Open watcher at Digital too. I thought this would interest the Directorate. Also note the POSIX .12 work which is restructuring essentially the XTI and Sockets API. IPng is priority #1 though. /jim ------- Forwarded Message Return-Path: us2rmc::petja@xopen.co.uk Received: by xirtlu.zk3.dec.com; id AA13446; Thu, 23 Dec 1993 04:40:49 -0500 Date: Thu, 23 Dec 1993 04:40:42 -0500 Message-Id: <9312230940.AA13446@xirtlu.zk3.dec.com> From: us2rmc::petja@xopen.co.uk (Petr Janecek) To: XoTGnet@xopen.co.uk Subject: (XoTGnet 4389) PJ: Notes from OIW Convergence Meeting Notes from OIW OSE-TC Convergence Task Group meeting, Dec. 7-9, 1993, by Magnus Stallknecht, IBM Denmark, EWOS/EGLL chair. -------------------------------------------------------------- Background: ----------- The Convergence Task Group is an ad hoc group under the Open Systems Environment Technical Committee (OSE-TC) of OIW. These notes cover only those activities of OSE-TC that are relevant to the TCP/IP-OSI convergence efforts. Convergence is to be understood in a broad sense, covering Lower Layers, Upper Layers and Applications. The convergence work was initiated during the June 1993 meeting of OIW OSE-TC where the 'Internet 2000' model was presented and liaison statements on the need for convergence were submitted to a number of organizations, including the Regional Workshops (AOW and EWOS), ISOC (Internet Society) and IGOSS (Industry and Government Open Systems Specifications, US/Canada). Further presentations and discussions took place during the September 1993 meeting of OIW OSE-TC, including user views, 'lessons learned' by users and vendors, status on mOSI work, and an Internet perspective (ref. draft OIW OSE-TC report, OSE-TC/93-124). The objective of the December 1993 meeting of OIW OSE-TC and its Convergence Task Group was to develop a more clear understanding of the technical work needed from the Regional Workshops, including convergence taxonomy proposals to be produced during joint meetings of the Convergence Task Group with OIW/LL-SIG and OIW/UL-SIG. The EWOS participants to the December meeting of OIW OSE-TC were: Jon Stranger, representing CCTA, attended the plenary sessions of OIW OSE-TC and all of the Convergence break-out sessions. Bryan Wood, representing EWOS/EG-OSE attended the plenary sessions of OIW OSE-TC and the OSE profiling break-out sessions (work on draft TR 10000-3). Klaus Truoel, representing EWOS/TLG, attended the OIW/UL-SIG meetings and the UL-SIG joint meeting with the Convergence Task Group. Magnus Stallknecht, representing EWOS/EGLL, attended the plenary sessions of OSE-TC and all of the Convergence Task Group meetings, except the joint meeting with UL-SIG. Attended also all of the OIW/LL-SIG meeting. Summary: -------- The convergence work of OSE-TC was conducted on December 7, 8 and 9. Most of the first day was used to present background material and liaison reports in OSE-TC plenary. This included presenta- tions on 1 The state of Internet. Extremely high growth rates (like 10% per month), new and commercial applications are emerging. 2 The NIST convergence research program. Focusing on TUBA implementations and prototyping, needs for CLNP extentions, aspects of security and network management in mixed environments. 3 Status of IEEE POSIX 1003.12. Draft standard for application program interfaces at the transport layer, building on XTI (X/Open Transport Interface) and the BSD Socket Interface. The draft standard needs a number of additional recirculation ballots within IEEE P1003. 4 Liaison report, ISOC/IAB/IETF. Work on IPng (Internet Protocol next generation) continues within the Internet community. CIDR (Classless Interdomain Routing) is a stop-gap measure to preserve scarce Internet addressing space, SIPP (Simple Internet Protocol Plus) and TUBA (TCP and UDP with Bigger Addresses) are essentially competing proposals for IPng. TUBA facilitates convergence with ISO's CLNP (ConnectionLess-mode Network Protocol, ISO 8473). 5 FIRP, Federal Internetworking Requirements Panel. The Panel will offer recommendations for US Federal internetworking requirements and convergence of network protocols (Internet, OSI and (where appropriate) propri- etary). A draft report is expected from the Panel by mid January 1994. The report will be circulated widely (freely and electronically) for a 30 day comments period. 6 X/Open status update. X/Open is progressing work on MPTN, Multi-Protocol Transport Networking, to complement XTI. The first document, X/Open Guide to MPTN Architecture, is expected for publication in January 1994. After the plenary presentations the meeting continued in break- out sessions on Dec. 8 and 9: 7 Break-out meeting of the Convergence Task Group The key words are Coexistence and Convergence (CC). The Regional Workshops should deal with the technical aspects of CC, and not with legal or procurement aspects (e.g. 'legitimizing' TCP/IP). Initially, coexistence is the most important objective. It is the foundation for convergence. Possibly, convergence will grow by itself through market preferences once technical means of coexistence have been established. Technical work, as needed, should be done by SIGs. Much coexistence work has already been done by IETF but may need to be cataloged and structured. Cooperation with IETF to be encouraged. 8 Role of OSE-TC and its Convergence Task Group OSE-TC should enlist and encourage participation from all interested parties but not assume a 'manager' role. OSE-TC and the Convergence Task Group will monitor the work, help establish priorities and target dates, and will report on progress. It will also promote awareness of the CC efforts and the cooperative spirit in which these efforts are performed. 9 Joint meeting with LL SIG A possible Lower Layers taxonomy was discussed, consisting of 'pure OSI' as today, 'pure TCP/IP', and two 'cross overs' (OSI over TCP/IP and TCP/UDP over TUBA). Further study is needed for coexistence routing profiles. Work on 'Integrated Network Layer Security Protocol'. Lower Layers API profiles, based on XTI, may be associated with the various protocol profiles. 10 Joint meeting with UL SIG mOSI, minimum OSI, may play a key role for Upper Layers coexistence and convergence efforts. A possible taxonomy for protocol stacks ('pure' as well as 'mixed') and APIs was discussed. 11 Plenary report A summary report was prepared outlining today's problems of multiple protocols, partial solutions and limited interoperability. The underlying principles of public sector policy (i.e. conditions for technical solutions) were described. The focus on coexistence as a prerequisite for convergence was highlighted. The work on coexistence will not by itself create a global interworking infrastructure but will enable it. Details: -------- 1 State of the Internet (OSE-TC/93-153) Steve Wolff of NSF presented "The State of the Internet", including statistics on growth and usage. Growth rates of attachments are in the order of 10% per month| There are about 20,000 connected internets, about 2 million hosts, and 5-10 million users. Non-US networks growing faster. Commercial use increasing. Security remains an issue for commercial uses. Traffic growing less dramatic than attachments. New types of usage emerging, such as commercial electronic data, application of encryption technology, multimedia, office connectivity, entertainment, and mobile users (wireless as well as travellers). After the presentation a suggestion was raised from the audience that Internet should be run as a commercial service by industry and not 'free' by governments. Further discussion revealed the big advantage of the current Internet not being subject to traffic settlement charges between Internet network operators as is currently prac- ticed among public network operators (X.25, X.400 etc.). Traffic charges between users and operators, and between operators, is potentially a BIG problem for a commercial global internetworking system. 2 NIST Convergence Research Program (OSE-TC/93-154 and -170) Richard Colella of NIST presented the NIST Convergence Research program which addresses CC Technology (Coexistence and Convergence Technology). Focus areas of NIST involve- ment are a. TUBA (TCP and UDP with Bigger Addresses). Looking at mapping of applications to TUBA, needed extensions to CLNP (ISO 8473), and deployment of TUBA-capable systems. b. Integrated Network Layer Security Protocol (I-NLSP), based on the CLNS part of ISO/IEC 11577, the Network Layer Security Protocol. Aiming at "Secure TUBA" service. c. Network Management support over TUBA, demonstrate operation of SNMP over TUBA, generalize MIBs for OSI and IPS (Internet Protocol Suite) resources in TUBA/Mixed Stack environments. d. Prototyping of CC Technology to demonstrate TUBA feasibility and completeness. NIST invites cooperative participation in its CC efforts, including contributions of resources and equipment. 3 Status of POSIX 1003.12 (OSE-TC/93-178) Karen Olsen of NIST presented status of IEEE POSIX 1003.12 standardization on APIs between communication services and applications. P1003.12 provides for application portability over transport services and is therefore an important complement to Lower Layer transport profiles. The 1003.12 Draft 4.0 specifies a low level DNI (Detailed Network Interface) providing access to protocol-specific features of the underlying network. DNI consists of the X/Open Transport Interface (XTI) and the BSD Socket Interface. The first ballot was closed on October 29, 1993. A number of additional ballots on 1003.12 are needed before it can be approved as an IEEE Standard. The 1003.12 is likely to be merged with 1003.1 when approved. Some work is being done on Protocol Profile Sets (CO and CL for OSI and Internet transport profiles). This looks like API profiling. 4 Liaison reports, ISOC/IAB/IETF (OSE-TC/93-151) George Chang of Bellcore reported on status of work on IPng. The PIP and SIP proposals have merged to SIPP (Simple Internet Protocol Plus). CIDR (Classless Interdomain Routing Protocol) gains some support to extend the lifetime of the current IP v4. TUBA marches on and gains interna- tional support. George cited some advantages of TUBA: platform for coexis- tence of TCP/IP and OSI applications, based on stable network layer protocols (CLNP and IP). TUBA prototype implementations are now available on many platforms. Commercial products are expected to be available in the market soon. 5 Federal Internetworking Requirements Panel (FIRP) (OSE-TC/93-162) Walter Houser, US Dept. of Veterans Affairs, chair of OIW OSE-TC, and Richard desJardins of NASA, presented FIRP background, charter, members, schedule, types of recommendations and report outline. FIRP was chartered September 1993 by NIST who needs direc- tion for US GOSIP, noting that US Gov't agencies use Internet although US GOSIP requires OSI. The panel has 9 members, all from US Gov't agencies representing user requirements. Walter Houser of VA, Richard desJardins of NASA, and Stephen Wolff of NSF are among the panel members. They were all active participants to the December 1993 meeting of OSE-TC. Diane Fountaine of DoD is panel chair. The FIRP shall review and provide recommendations to the short term and long term issues of internetworking for US Gov't agencies, convergence of Internet and OSI protocols, role of proprietary and other protocols, source of require- ments for FIPS (Federal Informations Processing Standards), maintenance and testing requirements for FIPS, security requirements, economic impacts of procurement and deploy- ment, protection of Gov't investments, and aspects of international relationships and commitments. FIRP is requested to provide a draft report for comments by mid January 1994. Comments are due within 30 days and a final report will be issued sometime later in 1994. The draft report will be widely distributed electronically, e.g. on Internet, and comments are solicited from all interested parties, including international organizations, the Regional Workshops and the Internet community. The report is expected to be a document of 50-100 pages. The report is expected to be pragmatic in nature, - reflecting sort of bottom-up user view rather than top-down policy view, recognizing that Gov't agencies do meet their needs with a variety of more or less 'open' industry standards. The panel feeling may be that Gov't should not interfere directly with the market and dictate particular technical solutions (e.g. OSI based) but rather be concerned with ensuring that market mechanisms are effective, e.g. fair and effective competition among suppliers exists, and that technical solutions are capable of interworking. Ted Landberg of NIST, chair of OIW, is aware of the EWOS Workshop week, January 17-20, 1994, and will make an attempt to have the report available electronically to EWOS at or prior to its January meeting for discussion and comments. 6 X/Open status update (OSE-TC/93-157) Petr Janecek of X/Open provided a written report on progression of X/Open work on MPTN (Multi-Protocol Trans- port Networking) to complement XTI (X/Open Transport Interface). A document titled 'X/Open Guide to MPTN Archi- tecture' is expected to be published January 1994. The X/Open Interworking Group (XNET, chaired by Petr) has started work on two of the actual MPTN specifications (Access Node Reference and Address Mapper Reference) based on contributions from IBM. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us2rmc.bb.dec.com; id AA10287; Thu, 23 Dec 93 04:37:59 -0500 % Received: by inet-gw-1.pa.dec.com; id AA06939; Thu, 23 Dec 93 01:37:08 -0800 % Received: by xopen.xopen.co.uk (1.36.108.3/15.6) id AA22808; Thu, 23 Dec 93 09:20:16 GM % Message-Id: <9312230920.AA22808@xopen.co.uk> % Received: by xopuk.xopen.co.uk (1.36.108.3/16.2) id AA27143; Thu, 23 Dec 93 09:16:00 GM % Date: Thu, 23 Dec 93 09:16:00 GMT % From: Petr Janecek % To: XoTGnet@xopen.co.uk % Subject: (XoTGnet 4389) PJ: Notes from OIW Convergence Meeting % Sender: XoTGnet-request@xopen.co.uk % Comments: (XoTGnet 4389) ------- End of Forwarded Message From bound@zk3.dec.com Thu Dec 23 14:10:38 1993 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 (8.6.4/8.6.4) with SMTP id OAA06434 for ; Thu, 23 Dec 1993 14:20:09 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA12181; Thu, 23 Dec 93 11:10:45 -0800 Received: by xirtlu.zk3.dec.com; id AA22795; Thu, 23 Dec 1993 14:10:44 -0500 Message-Id: <9312231910.AA22795@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Happy Holidays and have a Great New Year Date: Thu, 23 Dec 93 14:10:38 -0500 X-Mts: smtp Glad to work with all you folks even when we won't see eye to eye next year. I had a boss once who told me Jim if we can't disagree with each other even to the point of emotion and then go fishing together after work then we cannot work together. He was a fun manager. I yelled at him a lot, but we did catch some nice fish together. For what its worth I have been asked and told Sr. Management and Sr. Technical community where I work the IPng Co-Chairs, Directorate, and other interfaces to the IPng area can reach a decision in my opinion. But, it would be a lot of work (in fact a real lot of work), and we are dealing with a multivariable equation and we are still deriving the equation using basic algebra and thus do not know all the unknown variables yet. I will be on vaca most next week but will be checking my IPng mail. p.s. Dino, Ross, and I are working on the Phase IV and Phase V lessons. Just in the analysis stage now. take care, /jim From bound@zk3.dec.com Thu Dec 23 14:39:49 1993 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 (8.6.4/8.6.4) with SMTP id OAA06722 for ; Thu, 23 Dec 1993 14:40:05 -0500 From: bound@zk3.dec.com Received: by inet-gw-2.pa.dec.com; id AA13791; Thu, 23 Dec 93 11:39:58 -0800 Received: by xirtlu.zk3.dec.com; id AA23708; Thu, 23 Dec 1993 14:39:55 -0500 Message-Id: <9312231939.AA23708@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: POSTSCRIPT: CIDR and the Evolution of the Internet Protocol Date: Thu, 23 Dec 93 14:39:49 -0500 X-Mts: smtp Scott suggested I send this out. Its a recent Connexations article on CIDR and has discussion of hidden local addresses too being requested on the Internet if you have not seen it. Authors are Hans-Werner Braun, Peter Ford, and Yakov Rehkter. /jim -------------- cut here ------------ %!PS-Adobe-2.0 %%Creator: dvips 5.47 (RS/6000 1.0) Copyright 1986-91 Radical Eye Software %%Title: cidr-inet93.dvi %%Pages: 5 1 %%BoundingBox: 0 0 612 792 %%EndComments %%BeginProcSet: tex.pro /TeXDict 250 dict def TeXDict begin /N /def load def /B{bind def}N /S /exch load def /X{S N}B /TR /translate load N /isls false N /vsize 10 N /@rigin{ isls{[0 1 -1 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale Resolution VResolution vsize neg mul TR matrix currentmatrix dup dup 4 get round 4 exch put dup dup 5 get round 5 exch put setmatrix}N /@letter{/vsize 10 N}B /@landscape{/isls true N /vsize -1 N}B /@a4{/vsize 10.6929133858 N}B /@a3{ /vsize 15.5531 N}B /@ledger{/vsize 16 N}B /@legal{/vsize 13 N}B /@manualfeed{ statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X array /BitMaps X /BuildChar{CharBuilder} N /Encoding IE N end dup{/foo setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{/sf 1 N /fntrx FMat N df-tail} B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data dup length 5 sub get} B /ch-height{ch-data dup length 4 sub get} B /ch-xoff{128 ch-data dup length 3 sub get sub} B /ch-yoff{ ch-data dup length 2 sub get 127 sub} B /ch-dx{ch-data dup length 1 sub get} B /ch-image{ch-data dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 add]{ch-image} imagemask restore}B /D{/cc X dup type /stringtype ne{]}if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin 0 0 moveto}N /eop{clear SI restore showpage userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook known{start-hook}if /VResolution X /Resolution X 1000 div /DVImag X /IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put} for}N /p /show load N /RMat[1 0 0 -1 0 0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V statusdict begin /product where{pop product dup length 7 ge{0 7 getinterval(Display)eq}{pop false}ifelse}{false}ifelse end{{gsave TR -.1 -.1 TR 1 1 scale rulex ruley false RMat{BDot}imagemask grestore}}{{gsave TR -.1 -.1 TR rulex ruley scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /a{ moveto}B /delta 0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{ S p tail}B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w }B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p a}B /bos{/SS save N}B /eos{clear SS restore}B end %%EndProcSet TeXDict begin 1000 300 300 @start /Fa 1 124 df123 D E /Fb 1 16 df<07E01FF83FFC7FFE7FFEFFFFFFFFFFFFFFFFFFFFFFFF7FFE7FFE3FFC1FF807 E010107E9115>15 D E /Fc 2 51 df<06001E00FE00EE000E000E000E000E000E000E000E000E 000E000E000E000E000E00FFE0FFE00B137D9211>49 D<1F003FC061E0C0E0E070E07000700070 00E000C001C0030006000C30183030707FE0FFE0FFE00C137E9211>I E /Fd 77 124 df<003F0F0000FFBF8003C3F3C00703E3C00703C1800E01C0000E01C0000E01C000 0E01C0000E01C0000E01C000FFFFFC00FFFFFC000E01C0000E01C0000E01C0000E01C0000E01C0 000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0007F87 FC007F87FC001A1D809C18>11 D<003F0000FF8003C1C00703C00703C00E01800E00000E00000E 00000E00000E0000FFFFC0FFFFC00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E 01C00E01C00E01C00E01C00E01C00E01C07F87F87F87F8151D809C17>I<003FC000FFC003C3C0 0703C00701C00E01C00E01C00E01C00E01C00E01C00E01C0FFFFC0FFFFC00E01C00E01C00E01C0 0E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C07FCFF87FCFF8 151D809C17>I<003F03F00000FFCFF80003C0FC1C000701F03C000701F03C000E00E018000E00 E000000E00E000000E00E000000E00E000000E00E00000FFFFFFFC00FFFFFFFC000E00E01C000E 00E01C000E00E01C000E00E01C000E00E01C000E00E01C000E00E01C000E00E01C000E00E01C00 0E00E01C000E00E01C000E00E01C000E00E01C000E00E01C007FC7FCFF807FC7FCFF80211D809C 23>I<7070F8F8FCFCFCFC7C7C0C0C0C0C0C0C181818183030606040400E0D7F9C15>34 D<70F8FCFC7C0C0C0C1818306040060D7D9C0C>39 D<00C00180030006000E000C001C00180038 00300030007000700060006000E000E000E000E000E000E000E000E000E000E000E000E0006000 60007000700030003000380018001C000C000E0006000300018000C00A2A7D9E10>II<70F0F8F8781818183030706040050D7D840C>44 DI<70F8F8F87005057D840C>I<00030003000700060006000E000C001C0018001800380030 003000700060006000E000C000C001C001800380030003000700060006000E000C000C001C0018 00180038003000700060006000E000C000C00010297E9E15>I<03C00FF01C38381C381C700E70 0E700EF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00F700E700E700E381C381C 1C380FF007E0101D7E9B15>I<030007003F00FF00C70007000700070007000700070007000700 0700070007000700070007000700070007000700070007000700FFF8FFF80D1C7C9B15>I<07C0 1FF03878603C601EF01EF80FF80FF80F700F000F000E001E001C003C0078007000E001C0038007 000E030C03180330067FFEFFFEFFFE101C7E9B15>I<07E01FF03838301C781E781E781E381E00 1E003C0038007007E007E00038001C001E000E000F000F700FF80FF80FF80EF01E601C38381FF0 07C0101D7E9B15>I<001C00001C00003C00007C00007C0000DC0001DC00019C00039C00071C00 061C000E1C000C1C00181C00381C00301C00601C00E01C00FFFFC0FFFFC0001C00001C00001C00 001C00001C00001C0001FFC001FFC0121C7F9B15>I<300C3FFC3FF83FE0300030003000300030 00300033E037F03C38381C301E300E000F000F000F000F700FF00FF00FE00E601E601C38781FF0 07C0101D7E9B15>I<00F003FC070C0E0E1C1E381E380C780070007000F3F0F7F8FC1CF81EF80E F00EF00FF00FF00FF00FF00F700F700F700E380E381C1C380FF003E0101D7E9B15>I<6000007F FF807FFF807FFF00600300C00600C00C00C00C0000180000300000300000600000600000C00000 C00001C00001C00003800003800003800003800007800007800007800007800007800007800007 8000030000111D7E9B15>I<03E00FF01C38381C300E700E700E700E780E781C3E1C3FB81FE007 F00FF81CFC387E701E700FE00FE007E007E007E007700E700C3C3C1FF007E0101D7E9B15>I<03 C00FF01C38381C781C700EF00EF00EF00FF00FF00FF00FF00F700F701F781F383F1FEF0FCF000E 000E000E301C781C7838703030F03FC00F80101D7E9B15>I<70F8F8F870000000000000000070 F8F8F87005127D910C>I<00060000000F0000000F0000000F0000001F8000001F8000001F8000 001F80000033C0000033C0000033C0000061E0000061E0000061E00000C0F00000C0F00000C0F0 00018078000180780001FFF80003FFFC0003003C0003003C0006001E0006001E0006001E001F00 1F00FFC0FFF0FFC0FFF01C1D7F9C1F>65 DI<001F808000FFE180 03F0338007801B800F000F801E0007801C0003803C000380780003807800018070000180F00001 80F0000000F0000000F0000000F0000000F0000000F0000000F000000070000180780001807800 01803C0001801C0003001E0003000F00060007800C0003F0380000FFF000001F8000191E7E9C1E >IIII<001F808000FFE18003 F0338007801B800F000F801E0007801C0003803C000380780003807800018070000180F0000180 F0000000F0000000F0000000F0000000F0000000F000FFF0F000FFF07000078078000780780007 803C0007801C0007801E0007800F00078007800F8003F0398000FFF080001FC0001C1E7E9C21> III<1FFF1FFF0078007800780078 0078007800780078007800780078007800780078007800780078007800787078F878F878F87870 F071E03FC00F80101D7F9B15>IIIII<003F800000FFE00003E0F80007803C000E 000E001E000F003C00078038000380780003C0780003C0700001C0F00001E0F00001E0F00001E0 F00001E0F00001E0F00001E0F00001E0F00001E0780003C0780003C0780003C03C0007803C0007 801E000F000F001E0007803C0003E0F80000FFE000003F80001B1E7E9C20>II82 D<07E0801FF9803C1F80700780700380E00380E00180E00180E001 80F00000F000007C00007FC0003FF8001FFE0007FF0000FF80000F800003C00003C00001C0C001 C0C001C0C001C0E00180E00380F00300FC0E00CFFC0083F800121E7E9C17>I<7FFFFFC07FFFFF C0780F03C0700F01C0600F00C0E00F00E0C00F0060C00F0060C00F0060C00F0060000F0000000F 0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F000000 0F0000000F0000000F0000000F0000000F000003FFFC0003FFFC001B1C7F9B1E>I III<7FF0FFC07FF0FFC007C03E0003C0380003E0300001E0700001F0600000F0C0000079C000 007D8000003F0000001F0000001F0000000F0000000F8000001F8000003BC0000033E0000071E0 000061F00000C0F80001C0780001807C0003003C0007001E000F801F00FFE0FFF0FFE0FFF01C1C 7F9B1F>II91 D<08081818303060606060C0C0C0C0C0C0F8F8FCFCFCFC 7C7C38380E0D7B9C15>II<0FE0001FF8003C3C003C1E00180E00000E0000 1E0007FE001FFE003E0E00780E00F00E00F00E60F00E60F01E60783E603FFFC01F878013127F91 15>97 DI<03F00FF81E3C383C78187000F000F000F000F0 00F000F000780078063C061E0C0FF803E00F127F9112>I<001F80001F80000380000380000380 00038000038000038000038000038000038003E3800FFB801E0F80380780780380700380F00380 F00380F00380F00380F00380F003807003807803803807801E1F800FFBF007E3F0141D7F9C17> I<03E00FF01C38381C781E700EFFFEFFFEF000F000F000F000700078063C061E0C0FF803E00F12 7F9112>I<007801FC039E071E0E0C0E000E000E000E000E000E00FFE0FFE00E000E000E000E00 0E000E000E000E000E000E000E000E000E000E007FE07FE00F1D809C0D>I<00038007E7C00FFD C03C3DC0381C00781E00781E00781E00781E00381C003C3C003FF00037E0007000007000003000 003FFC001FFF003FFF80700780E001C0E001C0E001C0E001C07003803C0F001FFE0007F800121C 7F9215>II<18003C007C003C0018000000000000000000 00000000FC00FC001C001C001C001C001C001C001C001C001C001C001C001C001C001C00FF80FF 80091D7F9C0C>I<01C003E003E003E001C00000000000000000000000000FE00FE000E000E000 E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E060E0F1C0F1C0 7F803E000B25839C0D>IIIII<03F0000FFC001E1E00380700780780700380F003C0F003 C0F003C0F003C0F003C0F003C07003807807803807001E1E000FFC0003F00012127F9115>II<03E1800FF9801E1F803C0780780780780380F00380F00380F00380F00380F00380 F003807803807807803C07801E1F800FFB8007E380000380000380000380000380000380000380 001FF0001FF0141A7F9116>II<1F903FF07070E030E030E030F8007F803FE00FF000F8 C038C038E038E038F070DFE08FC00D127F9110>I<0C000C000C000C000C001C001C003C00FFE0 FFE01C001C001C001C001C001C001C001C001C301C301C301C301C301E600FC007800C1A7F9910 >IIII<7F8FF07F8FF00F0780070600038E0001DC0001D80000F00000700000780000 F80001DC00038E00030E000607000F0380FF8FF8FF8FF81512809116>II<7FFC 7FFC7838707060F060E061C063C00380070C0F0C0E0C1C1C3C1838187078FFF8FFF80E127F9112 >II E /Fe 35 123 df<0001F83C0007FC7E000E1ECF001C3DDE00 1C19CC003801C0003803800038038000380380003803800070038007FFFFF807FFFFF800700700 0070070000E0070000E00E0000E00E0000E00E0000E00E0001C00E0001C01C0001C01C0001C01C 0001C01C0003801C0003803800038038000380380003803800070030000700700067306000F678 E000FE79C000FC7F8000783E00002025819C19>11 D<1C3C3C3C3C0C1818383060C080060D7D84 0D>44 DI<70F8F8F0E005057B840D>I<0003000003800007000007 00000700000600000E00000E00000C00001C00001C0000380000380000700000700000E00000C0 0001C000018C00031C00071C00061C000C38001838003038007E3800FFF00081FE00007C000070 0000E00000E00000E00000E00001C00000C00011247D9B15>52 D<01FFE001FFE0003C00003C00 003C00003C0000780000780000780000780000F00000F00000F00000F00001E00001E00001E000 01E00003C00003C00003C00003C000078000078000078000078000FFF000FFF000131C7E9B10> 73 D<01FF0003FE01FF0007FE003F0007C0003F000FC0003F001BC0003F001BC0006F00378000 678037800067806780006780678000C780CF0000C7818F0000C7818F0000C7830F000187831E00 0187861E000187861E0001878C1E000307983C000307983C000307B03C000303F03C000603E078 000603E078000603C078000E03807800FFC38FFF00FFC30FFF00271C7E9B25>77 D<01FFFE0001FFFF80003C03C0003C01E0003C01E0003C01E0007801E0007801E0007801E00078 01C000F003C000F0038000F0070000F01E0001FFFC0001FFF00001E0000001E0000003C0000003 C0000003C0000003C0000007800000078000000780000007800000FFF00000FFF000001B1C7E9B 1C>80 D<000F84003FCC0070FC00C03801C03803803803803807003007003007000007800007C0 0007F80003FF0001FF8000FF80001FC00003C00001C00001C00001C03001C03001C07003807003 80700700780E00FC1C00CFF80083E000161E7D9C17>83 D<1FFFFFC01FFFFFC03C0F03C0300F01 80700F0180600F0180601E0180C01E0180C01E0180C01E0180003C0000003C0000003C0000003C 00000078000000780000007800000078000000F0000000F0000000F0000000F0000001E0000001 E0000001E0000001E000007FFF00007FFF00001A1C799B1E>I<7FE3FF8FF8FFE3FF0FF81E0078 03C01E007801801E007803001E00F803001E00F806001F01F806001F01F80C000F03780C000F03 7818000F067818000F067830000F0C7830000F0C7860000F1878E0000F1878C0000F3079C0000F 307980000F607B00000FE07B00000FC07E00000FC07E00000F807C00000F007C00000F00780000 0E007800000E007000000C00700000251D789B29>87 D<03CC07FC0E7C183C3838303870387038 E070E070E070E071E0E3E0E3E1E363E67E7C3C3810127B9115>97 D<3F007F000F000E000E000E 000E001C001C001C001C0039C03FE03E7038307838703870387038E070E070E070E060E0E0E0C0 E1C063807F003C000D1D7B9C13>I<01F007F80E181C3C3878303070007000E000E000E000E000 E000E010E03870F03FC01F000E127B9113>I<001F80003F800007800007000007000007000007 00000E00000E00000E00000E0003DC0007FC000E7C00183C00383800303800703800703800E070 00E07000E07000E07100E0E300E0E300E1E30063E6007E7C003C3800111D7B9C15>I<01E007F8 0E181C183818701870707FE0FF80E000E000E000E000E010603870F03FC01F000D127B9113>I< 0003C00007E0000CF0001DE0001CC0001C0000380000380000380000380000380003FF8007FF80 00700000700000700000700000E00000E00000E00000E00000E00001C00001C00001C00001C000 01C000038000038000038000038000070000670000F60000FE0000FC00007800001425819C0D> I<00798000FF8001CF800307800707000607000E07000E07001C0E001C0E001C0E001C0E001C1C 001C1C001C3C000C7C000FF80007B800003800003800007000607000F0E000F1E000FF80007F00 00111A7E9113>I<0FC0001FC00003C00003800003800003800003800007000007000007000007 00000E78000FFC000F8E000F0E001E0E001C0E001C0E001C0E00381C00381C00381C0038384070 38C07038C0707180707180E03F00601E00121D7D9C15>I<00C001E001C0018000000000000000 00000000000E003F0033806380C700C70007000E000E000E001C001C4038C038C038C039803F00 1E000B1C7D9B0D>I<1F803F80078007000700070007000E000E000E000E001C001C001C001C00 38003800380038007000700070007200E600E600E600E6007C003800091D7C9C0B>108 D<1E1F07C03F3F8FE06761D87063C1F070C781E070C781E0700701C0700701C0700E0380E00E03 80E00E0380E00E0381C21C0701C61C0701C61C07038C1C07038C380E01F8180600F01F127D9122 >I<1E1E003F7F0067E38063C380C78380C703800703800703800E07000E07000E07000E0E101C 0E301C0E301C1C601C1C60380FC018078014127D9117>I<01E007F80E1C1C1C380C300E700E70 0EE01CE01CE01CE038E038E070E06071C03F801E000F127B9115>I<0787000FDF8019F9C018E0 C031E0E031C0E001C0E001C0E00381C00381C00381C0038180070380070300078700078E000EFC 000E70000E00000E00001C00001C00001C00001C0000FF8000FF8000131A7F9115>I<03C407EC 0E7C183C3838303870387038E070E070E070E070E0E0E0E0E1E063E07FC03DC001C001C0038003 80038003803FF03FF00E1A7B9113>I<1E3C3F7E67C36387C78FC70F070607000E000E000E000E 001C001C001C001C003800180010127D9112>I<01F007F80E180E3C1C781C301E001FC00FE007 F000F020787070F070F070E0E07FC01F000E127D9111>I<00C001C001C001C003800380038003 80FFE0FFE0070007000E000E000E000E001C001C001C001C203860386038C038C01F800F000B1A 7D990E>I<0F01801F8380338380638380638700C387000707000707000E0E000E0E000E0E000E 0E200C1C601C1C600C1C600E3CC00FEF8003C70013127D9116>I<0F031F87338763836383C383 070307030E060E060E060E040E0C1C0C0E180E3007E003C010127D9113>I<0F00C1801F81C380 3381C3806381C18063838180C383818007038180070381800E0703000E0703000E0703000E0702 000E0706000E0E06000E0F0C000E1F180007F3F80003E1E00019127D911C>I<0F1E1FBF31E361 E761CFC1CF01C601C00380038003807381F703F703E706CF8E7DFC70F010127D9113>I<0F0180 1F8380338380638380638700C387000707000707000E0E000E0E000E0E000E0E000C1C001C1C00 0C1C000E3C000FF80003F80000380000380030700078600078E00071C0003F80001E0000111A7D 9114>I<01C307E30FFE0C3C180C00180030006000C00180030006020C0618063E1C7FFC63F8C0 E010127E9111>I E /Ff 40 122 df<70F8FCFC7C0C0C0C0C181830306040060F7C840E>44 DI<70F8F8F87005057C840E>I<000180000003C0000003C0000003 C0000007E0000007E0000007E000000FF000000CF000000CF000001CF800001878000018780000 383C0000303C0000303C0000601E0000601E0000601E0000C00F0000C00F0000C00F0001FFFF80 01FFFF8001800780030003C0030003C0030003C0060001E0060001E0060001E00E0000F01F0001 F0FFC00FFFFFC00FFF20237EA225>65 DI<000FE010003FF83000F81C7001E0067003C003F0078001F00F0000F01E0000F03E0000 703C0000707C0000707C0000307800003078000030F8000030F8000000F8000000F8000000F800 0000F8000000F8000000F800000078000030780000307C0000307C0000303C0000603E0000601E 0000600F0000C0078000C003C0018001E0030000F80E00003FF800000FE0001C247DA223>II70 D72 DI<03FF F003FFF0000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F 00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00700F 00F80F00F80F00F80F00F01E00601C003878001FF00007C00014237EA119>I76 DII80 D82 D<03F0200FFC601C0EE03803E07001E07001E0E000E0E000E0E00060E00060E00060F000 00F000007800007F00003FF0001FFE000FFF0003FF80003FC00007E00001E00000F00000F00000 70C00070C00070C00070C00070E00060E000E0F000C0F801C0EF0380C7FF0081FC0014247DA21B >I<7FFFFFF87FFFFFF87C0780F8700780386007801860078018E007801CC007800CC007800CC0 07800CC007800CC007800C00078000000780000007800000078000000780000007800000078000 000780000007800000078000000780000007800000078000000780000007800000078000000780 0000078000000780000007800003FFFF0003FFFF001E227EA123>I87 D89 D<0FE0001FF8003C1C003C0E00180700000700000700000F0003FF000FFF003F07007C07007807 00F00700F00718F00718F00F18780F187C3FB83FF3F00FC3C015157E9418>97 D<0E0000FE0000FE00001E00000E00000E00000E00000E00000E00000E00000E00000E00000E00 000E00000E1F800E7FE00FC0F00F00780E00380E003C0E001C0E001E0E001E0E001E0E001E0E00 1E0E001E0E001E0E001C0E003C0F00380F80700FC1F00C7FC00C1F0017237FA21B>I<01FE0007 FF000F07801C0780380300780000700000F00000F00000F00000F00000F00000F00000F0000078 00007800C03C00C01E01800F030007FE0001F80012157E9416>I<0000E0000FE0000FE00001E0 0000E00000E00000E00000E00000E00000E00000E00000E00000E00000E003F0E007FEE01F07E0 3C01E03800E07800E07000E0F000E0F000E0F000E0F000E0F000E0F000E0F000E07000E07800E0 3801E03C03E01E0EF00FFCFE03F0FE17237EA21B>I<01FC0007FF000F07801C03C03801C07801 E07000E0FFFFE0FFFFE0F00000F00000F00000F00000F000007800007800603C00601E00C00F83 8007FF0000FC0013157F9416>I<0000F001F1F807FFB80F1F381E0F001C07003C07803C07803C 07803C07803C07801C07001E0F000F1E001FFC0019F0001800001800001C00001FFF000FFFC01F FFE03801F0700070E00038E00038E00038E000387000707800F01E03C00FFF8001FC0015217F95 18>103 D<0E0000FE0000FE00001E00000E00000E00000E00000E00000E00000E00000E00000E 00000E00000E00000E1F800E7FC00FC1E00F80F00F00700E00700E00700E00700E00700E00700E 00700E00700E00700E00700E00700E00700E00700E00700E0070FFE7FFFFE7FF18237FA21B>I< 1C001E003E001E001C00000000000000000000000000000000000E00FE00FE001E000E000E000E 000E000E000E000E000E000E000E000E000E000E000E000E00FFC0FFC00A227FA10E>I<0E0000 FE0000FE00001E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E0000 0E0FFC0E0FFC0E07E00E03800E07000E0E000E18000E30000E78000EF8000F9C000F1E000E0E00 0E07000E07800E03C00E01C00E01E00E01F0FFE3FEFFE3FE17237FA21A>107 D<0E00FE00FE001E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E00 0E000E000E000E000E000E000E000E000E000E000E000E000E000E00FFE0FFE00B237FA20E>I< 0E1FC07F00FE7FE1FF80FEC0F303C01F807E01E00F003C00E00E003800E00E003800E00E003800 E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E0038 00E00E003800E00E003800E00E003800E0FFE3FF8FFEFFE3FF8FFE27157F942A>I<0E1F80FE7F C0FFC1E01F80F00F00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00 700E00700E00700E00700E0070FFE7FFFFE7FF18157F941B>I<01FC0007FF000F07801C01C038 00E07800F0700070F00078F00078F00078F00078F00078F00078F000787000707800F03800E01C 01C00F078007FF0001FC0015157F9418>I<0E1F80FE7FE0FFC1F00F00780E00780E003C0E003C 0E001E0E001E0E001E0E001E0E001E0E001E0E001E0E003C0E003C0F00780F80700FC1F00E7FC0 0E1F000E00000E00000E00000E00000E00000E00000E00000E0000FFE000FFE000171F7F941B> I<0E3CFEFEFFCF1F8F0F060F000E000E000E000E000E000E000E000E000E000E000E000E000E00 FFF0FFF010157F9413>114 D<0F883FF87078E038E018E018E018F0007F003FE01FF001F8003C C01CC01CE01CE01CF018F878DFF08FC00E157E9413>I<060006000600060006000E000E000E00 1E003E00FFF8FFF80E000E000E000E000E000E000E000E000E000E000E0C0E0C0E0C0E0C0E0C0E 08071803F001E00E1F7F9E13>I<0E0070FE07F0FE07F01E00F00E00700E00700E00700E00700E 00700E00700E00700E00700E00700E00700E00700E00700E00F00E01F007037803FE7F01F87F18 157F941B>II121 D E /Fg 37 123 df<0007F80FF000007FFE FFFC0001FC0FF81E0003F00FE01F0007E01FC03F000FC01F803F000FC01F803F000FC01F801E00 0FC01F800C000FC01F8000000FC01F8000000FC01F8000000FC01F800000FFFFFFFFFF00FFFFFF FFFF000FC01F803F000FC01F803F000FC01F803F000FC01F803F000FC01F803F000FC01F803F00 0FC01F803F000FC01F803F000FC01F803F000FC01F803F000FC01F803F000FC01F803F000FC01F 803F000FC01F803F000FC01F803F000FC01F803F000FC01F803F000FC01F803F007FF8FFF1FFE0 7FF8FFF1FFE02B237FA22F>14 D<387CFEFEFE7C3807077C8610>46 D<00007000000000700000 0000F800000000F800000000F800000001FC00000001FC00000003FE00000003FE00000003FE00 000006FF000000067F0000000E7F8000000C3F8000000C3F800000183FC00000181FC00000381F E00000300FE00000300FE00000600FF000006007F00000E007F80000FFFFF80000FFFFF8000180 01FC00018001FC00038001FE00030000FE00030000FE000600007F000600007F00FFE00FFFF8FF E00FFFF825227EA12A>65 D<0003FE0080001FFF818000FF01E38001F8003F8003E0001F8007C0 000F800F800007801F800007803F000003803F000003807F000001807E000001807E00000180FE 00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000 7E000000007E000001807F000001803F000001803F000003801F800003000F8000030007C00006 0003F0000C0001F800380000FF00F000001FFFC0000003FE000021227DA128>67 DII 73 D75 D77 DI80 D82 D86 D<7FFFC1FFF07FFFC1FFF003FC000C0001 FE00180000FE00380000FF007000007F806000003F80C000003FC1C000001FE38000000FE30000 000FF700000007FE00000003FC00000003FC00000001FE00000000FE00000000FF00000000FF80 000001FFC0000001BFC00000031FE00000070FF000000E0FF000000C07F800001803FC00003803 FC00003001FE00006000FF0000E000FF0001C0007F800180003FC0FFFC03FFFEFFFC03FFFE2722 7FA12A>88 D<07FC001FFF803F0FC03F07E03F03E03F03F01E03F00003F00003F000FFF007FFF0 1FC3F03F03F07E03F0FC03F0FC03F0FC03F0FC03F07E07F07E1DF81FF8FF07E07F18167E951B> 97 DI<00FF8007FFE0 0F83F01F03F03E03F07E03F07C01E07C0000FC0000FC0000FC0000FC0000FC0000FC00007C0000 7E00007E00003E00301F00600FC0E007FF8000FE0014167E9519>I<0003FE000003FE0000007E 0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E000000 7E0001FC7E0007FF7E000F81FE001F00FE003E007E007E007E007C007E00FC007E00FC007E00FC 007E00FC007E00FC007E00FC007E00FC007E00FC007E007C007E007C007E003E007E001E00FE00 0F83FE0007FF7FC001FC7FC01A237EA21F>I<00FE0007FF800F87C01E01E03E01F07C00F07C00 F8FC00F8FC00F8FFFFF8FFFFF8FC0000FC0000FC00007C00007C00007E00003E00181F00300FC0 7003FFC000FF0015167E951A>I<003F8000FFC001F3E003E7E007C7E00FC7E00FC3C00FC0000F C0000FC0000FC0000FC0000FC000FFFC00FFFC000FC0000FC0000FC0000FC0000FC0000FC0000F C0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0007FFC007F FC0013237FA211>I<01FE1F0007FFFF800F87E7801F03E7801E01E0003E01F0003E01F0003E01 F0003E01F0003E01F0001E01E0001F03E0000F87C0000FFF800019FE0000180000001C0000001C 0000001FFFE0001FFFF8000FFFFE000FFFFF003FFFFF007C003F80F8001F80F8000F80F8000F80 F8000F807C001F007E003F001F80FC000FFFF80001FFC00019217F951C>II<0E001F003F803F803F801F000E00000000 0000000000000000000000FF80FF801F801F801F801F801F801F801F801F801F801F801F801F80 1F801F801F801F801F801F80FFF0FFF00C247FA30F>I107 DIII<00FE0007FFC00F83E01E00F03E00F87C007C7C007C7C007C FC007EFC007EFC007EFC007EFC007EFC007EFC007E7C007C7C007C3E00F81F01F00F83E007FFC0 00FE0017167E951C>II114 D<07F3001FFF00780F00700700F003 00F00300F80000FF0000FFF0007FFC003FFE001FFF0007FF00003F80C00F80C00780E00780E007 80F00700FC1E00EFFC00C7F00011167E9516>I<00C00000C00000C00000C00001C00001C00003 C00007C0000FC0001FC000FFFF00FFFF000FC0000FC0000FC0000FC0000FC0000FC0000FC0000F C0000FC0000FC0000FC0000FC1800FC1800FC1800FC1800FC18007C18007E30003FE0000FC0011 207F9F16>II I I121 D<7FFFF07FFFF07C07E0700FC0601FC0E01F80 C03F00C07F00C0FE0000FC0001FC0003F80003F03007F0300FE0300FC0701F80703F80603F00E0 7E03E0FFFFE0FFFFE014167E9519>I E /Fh 38 120 df<60F0F8781818183070E040050B7D99 0B>39 D<60F0F0703030306060C040040B7D830B>44 DI<60F0F0 6004047D830B>I<03000700FF00FF000700070007000700070007000700070007000700070007 000700070007000700070007000700FFF0FFF00C197D9813>49 D<0F801FE030F06078F038F83C F83CF81C701C003C003C00380070007000E001C0038007000E0C0C0C180C30187FF8FFF8FFF80E 197E9813>I<0F801FE038F0707078787838787830780070007000E00FC00F8000E00070003800 3C003C703CF83CF83CF038607870F03FE00F800E1A7E9813>I<0070007000F000F001F003F003 70067006700C701C701870307030706070E070FFFFFFFF0070007000700070007007FF07FF1019 7F9813>I<60187FF87FF07FC06000600060006000600067806FE0787070786038003C003C003C 603CF03CF03CF038C038607070E03FC00F800E1A7E9813>I<07801FE0387030306038E018E018 E01CE01CE01CE01CE01C603C703C307C3FDC1F9C00180018003830307870786071C03F801F000E 1A7E9813>57 D<000C0000001E0000001E0000001E0000003F0000003F0000003F0000007F8000 00678000006780000067800000C3C00000C3C00000C3C0000181E0000181E0000181E00003FFF0 0003FFF0000300F0000600780006007800060078000C003C001E003C00FF81FFC0FF81FFC01A1B 7F9A1D>65 DI<003F0201FFC603E0EE07003E0E001E1C001E3C000E38000E7800 06700006F00006F00000F00000F00000F00000F00000F00000F000067000067800063800063C00 0C1C000C0E001807003003E0E001FFC0003F00171C7E9A1C>IIII73 D78 D80 D82 D<7FFFFF007FFFFF00781E0F00601E0300601E0300E0 1E0380C01E0180C01E0180C01E0180001E0000001E0000001E0000001E0000001E0000001E0000 001E0000001E0000001E0000001E0000001E0000001E0000001E0000001E0000001E000003FFF0 0003FFF000191A7F991C>84 D<3F80FFC0F0E0F070607000700FF03FF07870E070E070E073E073 70F37FFE3E3C10107E8F13>97 D<07F00FFC3C3C303C7018E000E000E000E000E000E000700038 0C3C180FF807E00E107F8F11>99 D<007E00007E00000E00000E00000E00000E00000E00000E00 000E00000E0007CE001FFE003C1E00700E00700E00E00E00E00E00E00E00E00E00E00E00E00E00 700E00701E003C3E001FFFC007CFC0121A7F9915>I<07C01FF038387018701CFFFCFFFCE000E0 00E000E0007000300C3C180FF007E00E107F8F11>I<00F801FC03BC073C0E180E000E000E000E 000E00FFC0FFC00E000E000E000E000E000E000E000E000E000E000E000E007FE07FE00E1A8099 0C>I104 D<18003C003C001800000000000000000000000000FC00FC001C001C 001C001C001C001C001C001C001C001C001C001C00FF80FF80091A80990A>I 107 DIII<07E01FF8381C70 0E6006E007E007E007E007E007E007700E700E3C3C1FF807E010107F8F13>I114 D<0C000C000C000C001C001C003C00FFC0FFC01C001C001C001C001C001C001C001C601C601C60 1C601C600FC007800B177F960F>116 DIII E end %%EndProlog %%BeginSetup %%Feature: *Resolution 300 TeXDict begin %%EndSetup %%Page: 1 1 bop 0 50 a Fh(CIDR)13 b(and)h(Ev)o(olution)h(of)e(IP)397 b(Pro)q(c.)17 b(INET)12 b('93)482 b(Braun,)13 b(F)m(ord,)g(Rekh)o(ter)369 220 y Fg(CIDR)18 b(and)i(the)e(Ev)n(olution)h(of)g(the)f(In)n(ternet)g(Proto) r(col)390 340 y Ff(Hans-W)l(erner)e(Braun,)g(San)h(Diego)f(Sup)q(ercomputer)f (Cen)o(ter)466 399 y(P)o(eter)g(S.)h(F)l(ord,)g(Los)i(Alamos)d(National)h (Lab)q(oratory)358 457 y(Y)l(ak)o(o)o(v)f(Rekh)o(ter,)f(T.J.)i(W)l(atson)h (Researc)o(h)f(Cen)o(ter,)f(IBM)g(Corp.)351 642 y Fg(Abstract)22 723 y Fe(The)23 b(tr)n(emendous)f(gr)n(owth)g(of)g(the)h(Internet)f(has)h(r)n (e-)0 773 y(sulte)n(d)c(in)g(sever)n(al)f(e\013orts)h(addr)n(essing)g(the)g (ne)n(e)n(d)h(to)f(b)n(e)0 823 y(able)13 b(to)g(addr)n(ess)g(and)h(r)n(oute)e (the)i(glob)n(al)e(public)h(Internet.)0 873 y(Many)k(of)g(these)f(e\013orts)h (c)n(al)r(l)e(for)h(lar)n(ge)g(changes)h(in)g(the)0 923 y(deploye)n(d)d (Internet)f(infr)n(astructur)n(e.)k(We)d(b)n(elieve)f(a)h(pru-)0 972 y(dent)h(c)n(ourse)f(of)g(action)h(includes)f(extending)h(the)g(usable)0 1022 y(life)i(of)h(IPv4)h(while)e(evaluating)h(the)g(use)h(of)f(these)g(new)0 1072 y(te)n(chnolo)n(gies.)j(This)16 b(r)n(e)n(quir)n(es)e(incr)n(emental)h (changes)i(in)0 1122 y(the)f(IPv4)h(r)n(outing)f(te)n(chnolo)n(gy)h(b)n(ase,) f(but)h(mor)n(e)f(imp)n(or-)0 1172 y(tantly)22 b(it)g(wil)r(l)f(r)n(e)n(quir) n(e)h(additional)g(c)n(o)n(or)n(dination)h(and)0 1222 y(management)15 b(among)g(the)f(Internet)g(servic)n(e)g(pr)n(oviders.)0 1271 y(We)j(also)g(b)n(elieve)f(that)h(extending)g(the)g(life)e(of)i(IPv4)g(in-)0 1321 y(cludes)c(getting)g(higher)f(utilization)g(of)h(the)g(IPv4)g(addr)n (ess)0 1371 y(sp)n(ac)n(e.)25 b(Sever)n(al)17 b(str)n(ate)n(gies,)f(mostly)h (administr)n(ative)f(in)0 1421 y(natur)n(e,)g(ar)n(e)f(pr)n(op)n(ose)n(d)i (to)f(c)n(onserve)g(the)g(use)g(of)g(IP)g(ad-)0 1471 y(dr)n(ess)e(sp)n(ac)n (e.)276 1573 y Fg(I.)k(In)n(tro)r(duction)59 1654 y Fd(The)j(In)o(ternet)g (is)f(facing)f(serious)i(c)o(hallenges)f(with)0 1704 y(distinct)d(\(but)h(in) o(terrelated\))g(tec)o(hnical)f(problems)f(and)0 1754 y(sev)o(eral)11 b(managemen)o(t)d(problems)i(whic)o(h)h(need)g(to)g(b)q(e)g(ad-)0 1804 y(dressed.)59 1876 y(The)k(three)h(tec)o(hnical)f(problems)e(whic)o(h)h (need)i(to)e(b)q(e)0 1926 y(addressed)i(are:)51 2009 y(1.)k(Routing)11 b(table)g(expansion)h(b)q(ey)o(ond)g(router)h(capa-)104 2059 y(bilities.)51 2154 y(2.)20 b(Premature)11 b(exhaustion)g(of)f(assigned)h(IP) g(net)o(w)o(ork)104 2204 y(n)o(um)o(b)q(ers)19 b(due)h(to)f(ine\016cien)o(t)g (allo)q(cation)f(of)g(the)104 2254 y(IPv4)c(address)h(space.)51 2349 y(3.)20 b(IP's)c(inabilit)o(y)e(to)i(address)i(more)d(than)h(4)g (billion)104 2399 y(hosts)e(connected)i(to)e(a)f(single)h(public)f(in)o (ternet.)59 2482 y(Eac)o(h)18 b(of)f(these)j(tec)o(hnical)e(problems)f(has)h (separate)0 2531 y(time)f(horizons)i(and)f(eac)o(h)h(is)f(sub)r(ject)i(to)e (a)h(v)n(ariet)o(y)f(of)0 2581 y(solutions.)59 2654 y(The)23 b(need)h(for)e(global)f(op)q(erational)h(co)q(ordination)0 2704 y(with)15 b(a)g(systems)g(p)q(ersp)q(ectiv)o(e)j(is)d(largely)f (unful\014lled)g(in)1034 642 y(the)f(curren)o(t)h(In)o(ternet.)k(In)o(ternet) c(addressing)f(and)f(rout-)1034 692 y(ing)f(requires)i(signi\014can)o(t)e(m)o (ultilateral)d(managemen)o(t)h(to)1034 742 y(insure)i(e\013ectiv)o(e)i(op)q (eration)d(of)g(the)i(In)o(ternet)g(infrastruc-)1034 791 y(ture.)1093 869 y(Curren)o(t)154 b(\\sa)o(v)o(e)g(the)f(In)o(ter-)1034 919 y(net")21 b(prop)q(osals)g(\(PIP[F)m(rancis)14 b(93)o(],)22 b(SIP[Deering)13 b(93],)1034 969 y(TP/IX[Ullman)e(93],)67 b(TUBA[Callon)13 b(92)o(][Katz)h(93)o(]\))1034 1019 y(attempt)20 b(to)g(solv)o(e)g(all)f(of)h (the)h(ab)q(o)o(v)o(e)f(problems)f(with)1034 1069 y(the)d(application)d(and)i (deplo)o(ymen)o(t)f(of)g(new,)i(imm)o(ature)1034 1118 y(and)k(certainly)g(un) o(tested)i(tec)o(hnology)m(.)36 b(F)m(urthermore,)1034 1168 y(some)16 b(of)h(these)h(prop)q(osals)f(fail)f(to)h(recognize)h(that)f(the) 1034 1218 y(problems)d(of)g(building)f(a)h(large)g(global)f(public)h(in)o (ternet)1034 1268 y(can)19 b(not)f(b)q(e)h(solv)o(ed)f(strictly)h(in)e(the)i (tec)o(hnical)g(realm.)1034 1318 y(Since)i(the)g(problem)e(of)h(routing)g (table)h(size)g(ma)o(y)d(b)q(e-)1034 1368 y(come)c(serious)i(in)e(the)h(near) g(term)g(\(1-2)f(y)o(ears\),)h(there)h(is)1034 1417 y(a)11 b(p)q(erception)h(that)f(it)g(is)f(necessary)j(to)e(adopt)g(one)g(of)f(the) 1034 1467 y(prop)q(osed)15 b(new)f(tec)o(hnologies)g(as)g(so)q(on)g(as)g(p)q (ossible.)1093 1545 y(W)m(e)h(prop)q(ose)g(a)g(t)o(w)o(o-pronged)g(system)f (approac)o(h)h(to)1034 1595 y(impro)o(v)o(e)8 b(and)i(enhance)h(the)f(curren) o(t)i(In)o(ternet.)18 b(This)9 b(ap-)1034 1645 y(proac)o(h)15 b(com)o(bines)f(tec)o(hnical)h(and)f(managerial)e(asp)q(ects)1034 1695 y(in)h(a)f(coheren)o(t)j(fashion,)c(addressing)j(eac)o(h)f(of)g(the)g (ab)q(o)o(v)o(e)1034 1744 y(problems)j(as)g(they)h(arise)g(in)f(an)g (incremen)o(tal)f(manner.)1034 1794 y(This)9 b(greatly)h(minim)o(i)o(zes)e (the)i(risk)g(of)e(service)j(disruption)1034 1844 y(in)j(the)i(op)q (erational)e(In)o(ternet)i(and)f(will)e(allo)o(w)h(time)f(for)1034 1894 y(m)o(uc)o(h)e(greater)h(maturation)e(of)h(the)i(prop)q(osed)f(tec)o (hnolo-)1034 1944 y(gies)e(and)g(a)f(b)q(etter)j(understanding)e(of)f(the)i (requiremen)o(ts)1034 1993 y(to)j(b)q(e)g(met.)1084 2106 y Fg(I)r(I.)k(CIDR)h(as)g(a)g(solution)h(to)e(routing)1378 2164 y(table)h(size)1093 2255 y Fd(The)29 b(routing)e(table)h(size)h(problem)e (has)h(sev)o(eral)1034 2305 y(facets.)63 b(A)29 b(primary)e(concern)j(whic)o (h)f(led)g(to)f(the)1034 2355 y(dev)o(elopmen)o(t)e(of)h(Classless)g(In)o (ter-Domain)e(Routing)1034 2405 y(\(CIDR\)[F)m(uller)12 b(92][F)m(ord)h(93)o (])30 b(is)f(the)i(immi)o(nen)o(t)d(ex-)1034 2455 y(haustion)17 b(of)f(the)h(class)g(B)g(address)h(space.)28 b(In)17 b(the)g(ab-)1034 2504 y(sence)c(of)d(CIDR,)g(sites)i(with)e(more)g(than)h(254)f(hosts)i(need) 1034 2554 y(to)i(adv)o(ertise)h(m)o(ultiple)d(class)j(C)g(net)o(w)o(orks)f (in)o(to)g(the)h(In-)1034 2604 y(ternet)h(routing)f(system.)20 b(By)c(using)e(hierarc)o(hical)h(rout-)1034 2654 y(ing,)g(CIDR)g(allo)o(ws)f (these)j(sites)g(to)e(use)i(a)e(single)g(pre\014x)1034 2704 y(to)20 b(adv)o(ertise)g(reac)o(habilit)o(y)f(of)h(m)o(ultiple)d(class)k(C)f (net-)917 2822 y Fh(BBA-1)p eop %%Page: 2 2 bop 0 50 a Fh(CIDR)13 b(and)h(Ev)o(olution)h(of)e(IP)397 b(Pro)q(c.)17 b(INET)12 b('93)482 b(Braun,)13 b(F)m(ord,)g(Rekh)o(ter)0 195 y Fd(w)o(orks,)h(and)h(subsequen)o(tly)g(p)q(ermits)f(full)g(utilization)f (of)0 245 y(the)g(class)f(C)g(address)i(space)f(with)f(a)g(minim)n(um)c (increase)0 295 y(in)13 b(routing)h(table)g(size.)59 368 y(CIDR)e(can)i(also) f(b)q(e)g(used)i(recursiv)o(ely)f(to)f(hierarc)o(hi-)0 418 y(cally)18 b(summarize)g(routing)h(information)d(for)j(m)o(ultiple)0 467 y(sites[Kleinro)q(c)o(k)14 b(77].)34 b(CIDR)19 b(summarizatio)o(n)e(can)i (b)q(e)0 517 y(done)j(along)e(pro)o(vider)i(based,)h(geographically)d(based)0 567 y(or)i(other)i(hierarc)o(hical)e(lines.)44 b(Th)o(us,)24 b(routing)e(table)0 617 y(gro)o(wth)d(can)f(scale)i(in)e(prop)q(ortion)h(to)f (the)h(n)o(um)o(b)q(er)g(of)0 667 y(elemen)o(ts)13 b(within)g(the)h(c)o (hosen)g(hierarc)o(h)o(y)g(\(e.g.)k(n)o(um)o(b)q(er)0 716 y(of)c(pro)o (viders\))h(instead)f(of)g(to)g(the)h(n)o(um)o(b)q(er)f(of)f(sites.)21 b(T)m(o)0 766 y(ac)o(hiev)o(e)f(suc)o(h)h(scaling)e(with)g(CIDR)h(requires)h (address)0 816 y(assignmen)o(t)h(along)h(hierarc)o(hical)g(b)q(oundaries,)j (whic)o(h)0 866 y(will)13 b(require)j(additional)d(managemen)o(t)f(of)i(the)i (address)0 916 y(space.)52 1019 y Fg(I)r(I)r(I.)h(E\016cien)n(t)h(use)h(of)f (address)h(space)59 1101 y Fd(The)12 b(class-orien)o(ted)h(structure)h(of)e (IP)g(addresses)i(has)0 1151 y(led)g(to)f(fairly)f(ine\016cien)o(t)i(use)g (of)f(the)i(IP)e(address)i(space.)0 1201 y(IP)e(address)g(space)h(has)e(b)q (een)i(freely)e(traded)i(o\013)e(for)g(ease)0 1251 y(in)j(routing)h (administration.)21 b(This)16 b(tradeo\013)g(o)q(ccurs)h(in)0 1301 y(sev)o(eral)d(w)o(a)o(ys:)51 1384 y(1.)20 b(Man)o(y)i(sites)i(receiv)o (e)g(far)f(more)f(address)i(space)104 1434 y(than)17 b(they)h(need.)30 b(Man)o(y)17 b(sites)h(with)f(m)o(uc)o(h)f(less)104 1484 y(than)h(64)f (thousand)h(hosts)h(use)g(a)f(single)f(class)i(B)104 1534 y(address)d(in)e (place)h(of)g(m)o(ultiple)d(Cs.)51 1630 y(2.)20 b(Because)27 b(of)d(limited)f(subnetting)j(capabilities,)104 1680 y(man)o(y)13 b(sites)k(end)e(up)h(needing)g(m)o(ultiple)d(net)o(w)o(ork)104 1730 y(n)o(um)o(b)q(ers)f(\(e.g.)18 b(Man)o(y)12 b(univ)o(ersities)i(ha)o(v)o (e)e(sev)o(eral)104 1780 y(class)19 b(B)f(net)o(w)o(orks)h(where)h(they)f (use)g(8)f(bit)h(sub-)104 1829 y(net)c(masks)f(with)h(v)o(ery)g(lo)o(w)f(o)q (ccupancy)i(on)f(most)104 1879 y(subnets.\))51 1975 y(3.)20 b(Man)o(y)15 b(sites)i(request)h(additional)c(net)o(w)o(ork)j(n)o(um-)104 2025 y(b)q(ers)12 b(simply)d(to)i(reduce)i(the)f(need)g(to)f(administra-)104 2075 y(tiv)o(ely)i(co)q(ordinate)h(within)f(a)h(campus.)51 2171 y(4.)20 b(Man)o(y)12 b(sites)i(using)e(IP)h(are)h(not)e(accessible)j(on) d(the)104 2221 y(public)f(In)o(ternet)j(y)o(et)e(they)h(use)g(a)e (signi\014can)o(t)h(p)q(or-)104 2271 y(tion)k(of)g(the)i(curren)o(t)g (address)g(space.)27 b(\(e.g.)g(out)104 2321 y(of)15 b(44,000)g(assigned)h (net)o(w)o(ork)g(n)o(um)o(b)q(ers)g(only)f(25)104 2371 y(p)q(ercen)o(t)g(are) g(reac)o(hable)f(through)g(the)h(In)o(ternet\).)59 2455 y(Since)h(it)f(is)g (no)o(w)g(clear)g(that)h(IP)f(has)h(b)q(ecome)f(a)g(k)o(ey)0 2504 y(comp)q(onen)o(t)h(of)h(the)g(global)e(In)o(ternet,)k(and)e(the)g(IP)g (ad-)0 2554 y(dress)f(space)g(is)f(an)g(increasingly)f(scarce)j(resource,)g (it)d(is)0 2604 y(necessary)i(to)e(judiciously)f(allo)q(cate)h(and)g(assign)g (the)h(IP)0 2654 y(address)22 b(space.)39 b(The)22 b(v)n(arious)e(addressing) h(registries)0 2704 y(of)14 b(the)i(In)o(ternet)g(m)o(ust)e(no)o(w)g(incorp)q (orate)h(guidance)g(re-)1034 195 y(garding)9 b(In)o(ternet)i(routing)e (issues)i(in)o(to)e(their)h(IP)g(address)1034 245 y(assignmen)o(t)j(p)q (olicies.)k(As)e(part)f(of)f(CIDR)g(deplo)o(ymen)o(t,)1034 295 y(suc)o(h)h(e\013orts)g(ha)o(v)o(e)e(already)h(started)h(at)f(the)g(U.S.) f(NIC)1931 280 y Fc(1)1034 345 y Fd(and)g(the)g(RIPE)g(NCC)1399 329 y Fc(2)1417 345 y Fd(,)f(and)h(CIDR)f(addressing)h(guide-)1034 394 y(lines)i(ha)o(v)o(e)g(b)q(een)h(published[Geric)o(h)e(92].)1279 497 y Fg(IV.)18 b(Ren)n(um)n(b)r(ering)1093 578 y Fd(The)12 b(simplest)e(hierarc)o(h)o(y)h(to)g(use)h(in)f(a)g(CIDR)f(system)1034 628 y(is)19 b(pro)o(vider)f(based)i(addressing)f(whic)o(h)f(allo)o(ws)g (hierar-)1034 677 y(c)o(hical)e(summarization)e(of)i(subscrib)q(er)i (pre\014xes)g(in)o(to)e(a)1034 727 y(small)h(n)o(um)o(b)q(er)i(of)f(routing)h (en)o(tries.)36 b(Pro)o(vider)19 b(based)1034 777 y(addressing)i(is)f(simple) f(to)h(administer)f(since)i(In)o(ternet)1034 827 y(subscrib)q(ers)i(will)c (often)i(get)g(their)g(addresses)i(from)c(a)1034 877 y(net)o(w)o(ork)12 b(service)i(pro)o(vider)e(when)h(they)f(initially)e(attac)o(h)1034 927 y(to)k(the)g(In)o(ternet.)1093 999 y(When)23 b(users)i(switc)o(h)e(pro)o (viders,)i(they)f(will)d(need)1034 1049 y(to)g(ev)o(en)o(tually)f(c)o(hange)h (their)h(addresses)g(so)f(that)g(the)1034 1099 y(routing)e(system)f(do)q(es)i (not)f(rev)o(ert)i(to)d(\\\015at)h(routing".)1034 1149 y(Ren)o(um)o(b)q (ering)12 b(is)i(often)g(p)q(erceiv)o(ed)h(as)f(\\imp)q(ossible")d(to)1034 1198 y(ask)19 b(sites)g(and)f(In)o(ternet)i(users)g(to)e(do.)32 b(Ho)o(w)o(ev)o(er,)20 b(go-)1034 1248 y(ing)f(b)q(ey)o(ond)h(the)g(p)q (erception)h(w)o(e)f(observ)o(e)g(that)g(most)1034 1298 y(In)o(ternet)j (users)f(and)f(systems)h(use)g(In)o(ternet)h(Domain)1034 1348 y(Names)15 b([Mo)q(c)o(k)n(ap)q(etris)f(87])h(instead)i(of)e(addresses,)k (lim-)1034 1398 y(iting)d(the)h(exp)q(osure)i(of)d(host)h(ren)o(um)o(b)q (ering)f(to)h(system)1034 1447 y(and)f(net)o(w)o(ork)f(administrators.)23 b(In)o(ternet)17 b(users)g(w)o(ould)1034 1497 y(certainly)h(prefer)g(name)f (based)h(systems)g(whic)o(h)f(either)1034 1547 y(auto)q(con\014gure)12 b(from)d(a)h(net)o(w)o(ork)i(service)g(or)f(at)f(least)i(are)1034 1597 y(more)d(easily)h(con\014gured)g(than)g(to)q(da)o(y's)g(systems.)17 b(There)1034 1647 y(should)12 b(b)q(e)h(a)f(co)q(ordinated)h(e\013ort)g(to)f (mak)o(e)f(administra-)1034 1696 y(tion)f(of)f(In)o(ternet)j(systems)e (easier)h(and)f(at)g(the)h(same)e(time)1034 1746 y(address)18 b(ren)o(um)o(b)q(ering)f(as)g(a)f(solution)g(to)h(some)f(of)g(the)1034 1796 y(scaling)e(issues)h(of)f(the)h(In)o(ternet)h(within)d(the)i(con)o(text) h(of)1034 1846 y(IPv4.)25 b(These)18 b(activities)e(could)g(tak)o(e)h(place)f (in)g(the)h(In-)1034 1896 y(ternet)i(Engineering)e(T)m(ask)g(F)m(orce)h (\(IETF\))g(within)e(the)1034 1946 y(Dynamic)10 b(Host)h(Con\014guration)g (Proto)q(col\(DHCP\))h(and)1034 1995 y(Domain)f(Name)i(Service)i(\(DNS\))f(w) o(orking)f(groups.)1093 2068 y(Ren)o(um)o(b)q(ering)23 b(of)h(the)h(curren)o (t)h(set)g(of)d(allo)q(cated)1034 2118 y(class)17 b(A,)g(B)g(and)f(C)h(net)o (w)o(ork)g(addresses)i(will)c(o)q(ccur)j(as)1034 2167 y(necessary)c(to)e (increase)h(the)f(actual)g(aggregation)e(of)i(net-)1034 2217 y(w)o(ork)i(announcemen)o(ts.)k(This)13 b(will)g(maxim)o(ize)e(the)k(util-) 1034 2267 y(it)o(y)20 b(of)h(the)g(CIDR)f(routing)g(and)h(addressing)h (system.)1034 2317 y(Ren)o(um)o(b)q(ering)14 b(will)f(also)i(reco)o(v)o(er)h (signi\014can)o(t)e(amoun)o(ts)1034 2367 y(of)20 b(un)o(used)i(IP)f(address)h (space,)h(th)o(us)f(alleviating)c(the)1034 2417 y(problem)9 b(of)i(exhaustion)f(of)h(assigned)g(IP)g(net)o(w)o(ork)g(n)o(um-)1034 2466 y(b)q(ers.)24 b(The)16 b(com)o(bination)d(of)i(CIDR)f(and)i(ren)o(um)o (b)q(ering)1034 2516 y(mak)o(es)e(it)g(p)q(ossible)i(to)e(use)i(IPv4)f(un)o (til)f(the)h(total)g(n)o(um-)1034 2566 y(b)q(er)h(of)f(hosts)h(approac)o(hes) h(the)f(practical)f(limits)e(of)i(the)p 1034 2608 367 2 v 1060 2643 a Fh(1)1092 2655 y(Net)o(w)o(ork)d(Information)j(Cen)o(ter)1060 2692 y(2)1092 2704 y(Net)o(w)o(ork)d(Co)q(ordination)k(Cen)o(ter)917 2822 y(BBA-2)p eop %%Page: 3 3 bop 0 50 a Fh(CIDR)13 b(and)h(Ev)o(olution)h(of)e(IP)397 b(Pro)q(c.)17 b(INET)12 b('93)482 b(Braun,)13 b(F)m(ord,)g(Rekh)o(ter)0 195 y Fd(32)g(bit)h(address)h(\014eld.)53 298 y Fg(V.)j(Net)n(w)n(ork)h(Num)n(b)r (ers)f(for)h(Priv)m(ate)347 356 y(In)n(ternets)59 437 y Fd(Hosts)11 b(within)e(sites)i(that)f(use)g(IP)h(can)f(b)q(e)g(partitioned)0 487 y(in)o(to)j(3)h(three)h(distinct)f(categories:)51 570 y(1.)20 b(Hosts)14 b(that)g(do)g(not)g(require)h(In)o(ternet)g(access)51 666 y(2.)20 b(Hosts)14 b(that)g(need)h(access)g(to)f(a)f(limited)e(set)k(of)e (In-)104 716 y(ternet)k(services)h(\(e.g.)23 b(E-mail\))14 b(whic)o(h)h(can)h(han-)104 765 y(dled)e(b)o(y)f(application)g(la)o(y)o(er)g (rela)o(ys.)51 861 y(3.)20 b(Hosts)e(that)g(need)h(unlimited)d(access)j(to)f (the)g(In-)104 911 y(ternet.)0 994 y(Only)10 b(hosts)i(in)e(the)i(last)e (category)h(require)h(IP)f(addresses)0 1044 y(that)21 b(are)g(globally)e (unique.)39 b(Hosts)21 b(within)g(the)g(\014rst)0 1094 y(and)d(second)i (categories)f(ma)o(y)d(use)k(IP)e(addresses)j(that)0 1143 y(are)14 b(unique)g(within)g(a)f(site,)h(but)h(ma)o(y)d(b)q(e)i(globally)e(non-)0 1193 y(unique.)17 b(It)10 b(is)g(common)e(for)h(organizations)h(to)g(build)f (pri-)0 1243 y(v)n(ate)16 b(in)o(ternets)h(whic)o(h)e(ha)o(v)o(e)h(little)f (or)g(no)h(hosts)g(falling)0 1293 y(in)o(to)f(the)h(third)g(category)m(.)23 b(Therefore,)17 b(to)f(conserv)o(e)h(IP)0 1343 y(net)o(w)o(ork)c(address)g (space)g(utilization)e(for)h(the)h(public)f(In-)0 1392 y(ternet,)h(w)o(e)g (prop)q(ose)f(the)h(allo)q(cation)d(of)i(sp)q(eci\014c)h(IP)f(net-)0 1442 y(w)o(ork)19 b(address)h(blo)q(c)o(ks)f(to)g(b)q(e)h(used)g(b)o(y)f (sites)h(to)f(iden-)0 1492 y(tify)d(hosts)i(of)f(t)o(yp)q(e)h(1)e(or)i(2)e (within)h(their)h(priv)n(ate)e(net-)0 1542 y(w)o(orks.)32 b(These)20 b(IP)f(addresses)h(will)d(not)i(b)q(e)g(routed)g(in)0 1592 y(the)f(public)e(In)o(ternet.)29 b(Th)o(us)17 b(a)g(site)g(could)g(assign)f (t)o(w)o(o)0 1641 y(subnet)21 b(addresses)g(to)f(eac)o(h)g(ph)o(ysical)f(net) o(w)o(ork.)36 b(Sys-)0 1691 y(tems)13 b(either)g(get)h(a)f(global)e(address)j (or)f(a)g(lo)q(cal-only)e(ad-)0 1741 y(dress,)i(dep)q(ending)g(up)q(on)f (what)g(sort)h(of)e(access)j(it)e(needs.)0 1791 y(With)19 b(the)g(prop)q (osed)h(sc)o(heme)g(man)o(y)d(large)i(corp)q(orate)0 1841 y(sites)14 b(\(BBN,)g(DEC,)e(GE,)h(IBM\))h(can)f(use)h(a)f(few)g(class)h(C)0 1891 y(net)o(w)o(ork)e(n)o(um)o(b)q(ers)f(from)f(the)i(global)e(IP)i(address) h(space.)135 1993 y Fg(VI.)19 b(Managemen)n(t)g(as)g(a)f(Key)316 2051 y(Comp)r(onen)n(t)59 2133 y Fd(Routing)12 b(of)h(the)h(In)o(ternet)h (used)f(to)g(b)q(e)g(quite)f(simple)0 2183 y(when)19 b(the)g(In)o(ternet)g(w) o(as)g(a)f(single)g(comm)o(unit)o(y)d(of)j(in-)0 2232 y(terest)f(net)o(w)o (ork)e(administered)f(b)o(y)g(a)h(single)f(en)o(tit)o(y)m(.)20 b(As)0 2282 y(the)d(In)o(ternet)i(has)e(gro)o(wn)f(to)h(serv)o(e)h(man)o(y)d (other)i(com-)0 2332 y(m)o(unities)h(in)h(a)g(pro)q(duction)h(mo)q(de)e(of)h (op)q(eration,)h(the)0 2382 y(problems)11 b(of)g(administering)f(the)i(In)o (ternet)h(routing)e(and)0 2432 y(addressing)k(has)f(b)q(ecome)f(more)g (di\016cult.)59 2504 y(As)29 b(noted)g(ab)q(o)o(v)o(e,)j(man)o(y)26 b(of)i(the)i(problems)d(in)0 2554 y(deplo)o(ying)h(CIDR)g(and)h(securing)h (maxim)o(al)c(use)k(of)0 2604 y(IPv4)19 b(tec)o(hnology)g(are)h(related)g(to) g(administrativ)o(e)d(is-)0 2654 y(sues,)f(suc)o(h)g(as)f(hierarc)o(hical)g (assignmen)o(t)f(of)g(addresses,)0 2704 y(ren)o(um)o(b)q(ering)c(sites)i(as)e (necessary)m(,)j(and)d(managemen)o(t)f(of)1034 195 y(routing)14 b(databases[Adams)f(93][Bates)h(93)o(])g(whic)o(h)h(con-)1034 245 y(tain)20 b(route)i(aggregation)d(information.)36 b(Multilateral)1034 295 y(co)q(ordination)20 b(is)h(just)f(getting)h(started)h(in)e(the)h(In)o (ter-)1034 345 y(net)e(and)f(the)h(establishmen)o(t)f(of)g(in)o(ter-pro)o (vider)g(op)q(er-)1034 394 y(ational)e(pro)q(cedures)k(is)d(underw)o(a)o(y)m (.)29 b(The)18 b(problems)f(of)1034 444 y(m)o(ultilateral)10 b(co)q(ordination)j(will)e(b)q(e)j(presen)o(t)h(for)e(an)o(y)g(of)1034 494 y(the)18 b(prop)q(osed)h(IP)e(\\next)h(generation")g(prop)q(osals)f(and) 1034 544 y(w)o(e)d(need)h(to)f(carefully)g(observ)o(e)h(and)f(learn)g(from)e (CIDR)1034 594 y(deplo)o(ymen)o(t)h(and)i(op)q(eration)f(to)h(help)g (facilitate)e(future)1034 643 y(deplo)o(ymen)o(ts)g(of)g(new)i(tec)o(hnology) m(.)1093 723 y(Problems)e(in)h(large)g(scale)g(in)o(ternet)o(w)o(orking)g (require)1034 773 y(a)19 b(t)o(w)o(o-pronged)g(systems)g(orien)o(ted)g (approac)o(h)g(includ-)1034 823 y(ing)13 b(b)q(oth)h(tec)o(hnical)h(and)e (managemen)o(t)f(elemen)o(ts.)18 b(Ex-)1034 872 y(p)q(erience)e(with)f(the)g (curren)o(t)h(In)o(ternet,)g(sp)q(eci\014cally)e(the)1034 922 y(in)o(terdomain)g(routing)h(system)g(engineering)h(and)g(man-)1034 972 y(agemen)o(t,)11 b(sho)o(ws)i(that)f(suc)o(h)h(an)f(approac)o(h)g(is)g (necessary)1034 1022 y(to)j(deliv)o(er)h(a)f(w)o(ork)n(able)g(solution.)22 b(System-lev)o(el)15 b(in)o(ter-)1034 1072 y(action)f(b)q(et)o(w)o(een)h(tec) o(hnical)f(and)g(managemen)o(t)d(comp)q(o-)1034 1122 y(nen)o(ts)j(is)f (required)h(for)e(a)h(successful)i(deplo)o(ymen)o(t)d(of)g(In-)1034 1171 y(ternet)18 b(tec)o(hnology)m(.)26 b(Curren)o(tly)m(,)17 b(tec)o(hnical)g(groups)g(of-)1034 1221 y(ten)c(kno)o(w)f(to)q(o)g(little)g (ab)q(out)g(actual)g(op)q(erational)f(issues,)1034 1271 y(while)20 b(the)g(op)q(erational)g(groups)g(in)g(turn)g(often)g(kno)o(w)1034 1321 y(to)q(o)c(little)f(ab)q(out)h(the)h(feasibilit)o(y)d(of)h(certain)i (tec)o(hnolo-)1034 1371 y(gies.)g(This)10 b(state)h(of)f(a\013airs)g(can)h(b) q(e)g(impro)o(v)o(ed)d(with)i(b)q(et-)1034 1420 y(ter)19 b(comm)o(unicati)o (on)c(and)j(in)o(teraction)f(b)q(et)o(w)o(een)j(these)1034 1470 y(groups)15 b(in)e(a)h(join)o(t)g(e\013ort)h(to)f(reduce)i(the)f(risk)f (of)g(ma)r(jor)1034 1520 y(op)q(erational)f(problems)g(in)g(the)i(In)o (ternet.)1093 1600 y(W)m(e)j(observ)o(e)h(that)g(a)f(k)o(ey)g(elemen)o(t)g (to)g(the)g(success)1034 1649 y(of)c(an)o(y)h(new)g(strategy)h(for)e(the)i (ev)o(olution)e(of)g(the)h(In)o(ter-)1034 1699 y(net)h(m)o(ust)e(address)j (the)f(issue)g(of)f(distributed)h(manage-)1034 1749 y(men)o(t)9 b(of)g(the)i(In)o(ternet)g(system)f(b)q(ey)o(ond)g(simple)e(addition)1034 1799 y(of)16 b(new)h(tec)o(hnology)f(to)g(b)q(e)h(deplo)o(y)o(ed)f(in)g(the)h (In)o(ternet.)1034 1849 y(The)k(In)o(ternet)h(is)e(b)q(eginning)g(to)g(mo)o (v)o(e)f(from)g(cen)o(tral-)1034 1899 y(ized)e(\(e.g.)27 b(NSFNET/MERIT\))17 b(to)o(w)o(ards)f(distributed)1034 1948 y(managemen)o(t)j(\(e.g.)40 b(an)21 b(op)q(en)h(Net)o(w)o(ork)f(Op)q(erations)1034 1998 y(F)m(orum)e(\(NOF\)\),)i(with)f(an)g(according)h(redistribution)1034 2048 y(of)e(resp)q(onsibilit)o(y)g(among)f(m)o(ultiple)f(participan)o(ts.)35 b(A)1034 2098 y(small)16 b(n)o(um)o(b)q(er)h(of)h(en)o(tities)g(con)o (trolling)f(the)i(future)g(of)1034 2148 y(the)12 b(In)o(ternet)h(is)f(anac)o (hronistic)f(and)h(reminiscen)o(t)f(of)g(the)1034 2197 y(concept)k(of)f(a)f (single)h(global)e(telephone)j(compan)o(y)m(.)1132 2313 y Fg(VI)r(I.)j(CIDR)h (Rollout)g(Activities)1093 2407 y Fd(The)c(In)o(ternet)h(comm)o(unit)o(y)11 b(has)j(already)g(made)g(sig-)1034 2457 y(ni\014can)o(t)26 b(plans)f(for)h(CIDR)f(deplo)o(ymen)o(t)f(la)o(ying)g(the)1034 2507 y(foundation)12 b(for)g(a)h(successful)i(roll)d(out)g(of)h(BGP-4)f(when) 1034 2557 y(it)i(b)q(ecomes)g(a)o(v)n(ailable)d(during)j(the)g(summer)f(of)g (1993.)1096 2654 y Fb(\017)21 b Fd(BGP-4)28 b(sp)q(eci\014cation)i(\(IETF)f (BGP)g(w)o(orking)1138 2704 y(group\))917 2822 y Fh(BBA-3)p eop %%Page: 4 4 bop 0 50 a Fh(CIDR)13 b(and)h(Ev)o(olution)h(of)e(IP)397 b(Pro)q(c.)17 b(INET)12 b('93)482 b(Braun,)13 b(F)m(ord,)g(Rekh)o(ter)62 195 y Fb(\017)21 b Fd(Commi)o(tm)o(en)o(t)h(to)i(implemen)o(t)e(BGP-4:)39 b(ANS,)104 245 y(Cisco,)18 b(Proteon,)g(W)m(ell\015eet,)g(3Com,)e(BBN.)i (\(All)104 295 y(of)c(these)i(companies)e(participate)h(in)f(BGP-4)h(de-)104 345 y(plo)o(ymen)o(t)d(co)q(ordination)h(meetings.\))62 442 y Fb(\017)21 b Fd(Co)q(ordination)i(and)g(planning)g(for)h(BGP-4)g(de-)104 492 y(plo)o(ymen)o(t)150 565 y Fa({)d Fd(U.S.)13 b(Regionals)g(w)o(orkshop)h (on)f(CIDR)150 662 y Fa({)21 b Fd(Sp)q(ecial)491 b(meet-)195 712 y(ing)17 b(b)o(y)h(\\bac)o(kb)q(one")g(pro)o(viders)g(\(In)o(terOP)m(,) 195 762 y(DC)c(93\))150 859 y Fa({)21 b Fd(IETF)14 b(BGP)g(deplo)o(ymen)o(t)f (W)o(G)g(meetings)62 956 y Fb(\017)21 b Fd(Routing)i(Database)i(w)o(ork:)40 b(RIPE)24 b(NCC)h(and)104 1006 y(Merit.)62 1103 y Fb(\017)c Fd(Routing)13 b(Database)i(Deplo)o(ymen)o(t:)j(RIPE)d(NCC,)104 1153 y(Merit,)f(and)f(CIX.)62 1250 y Fb(\017)21 b Fd(Address)k(assignmen)o(t) e(plans:)38 b(U.S.)23 b(Regionals)104 1300 y(and)14 b(the)h(U.S.)f(NIC,)g (RIPE)h(NCC)g(and)f(EBONE,)104 1350 y(CIX,)f(Japan,)h(etc.)62 1447 y Fb(\017)21 b Fd(Initial)13 b(hierarc)o(hical)h(allo)q(cation)f(of)g (IP)i(addresses)104 1497 y(as)21 b(blo)q(c)o(ks)g(of)f(class)h(Cs)g(is)g(b)q (eing)g(done)g(b)o(y)f(the)104 1546 y(RIPE)12 b(NCC,)f(and)h(the)h(U.S.)e (NIC)h(in)g(conjunction)104 1596 y(with)h(the)i(IP)f(net)o(w)o(ork)g(pro)o (viders)g(in)g(the)g(U.S.)253 1700 y Fg(VI)r(I)r(I.)j(Conclusion)59 1783 y Fd(The)22 b(In)o(ternet)h(can)e(ev)o(olv)o(e)g(incremen)o(tally)f(to)h (ad-)0 1833 y(dress)15 b(t)o(w)o(o)f(of)f(the)i(ma)r(jor)d(problems,)g (routing)i(table)g(ex-)0 1883 y(pansion)i(and)h(premature)g(exhaustion)g(of)f (assigned)i(IP)0 1933 y(net)o(w)o(ork)f(n)o(um)o(b)q(ers.)28 b(Small)14 b(tec)o(hnological)j(c)o(hanges)g(in)0 1983 y(the)h(routing)f(tec) o(hnology)g(are)h(b)q(eing)f(implemen)o(ted)e(b)o(y)0 2032 y(router)23 b(v)o(endors)h(making)c(BGP-4[Rekh)o(ter)14 b(92)o(])22 b(a)o(v)n(ail-)0 2082 y(able)11 b(during)g(Summer)e(1993)h(for)h(deplo)o (ymen)o(t)f(in)g(the)i(In-)0 2132 y(ternet)k(in)o(ter-domain)d(routing)i (system.)21 b(T)m(o)14 b(e\013ectiv)o(ely)0 2182 y(use)21 b(BGP-4)f(will)e (require)j(additional)d(administrativ)o(e)0 2232 y(e\013ort)f(within)e(the)i (In)o(ternet.)26 b(Most)17 b(of)e(this)h(e\013ort)h(will)0 2281 y(b)q(e)e(b)o(y)f(In)o(ternet)h(service)h(pro)o(viders,)e(but)g(the)h (abilit)o(y)d(to)0 2331 y(reduce)17 b(sites')f(e\013orts)g(in)f(c)o(hanging)g (addresses)i(ma)o(y)c(re-)0 2381 y(quire)h(additional)e(e\013ort)j(within)e (the)h(IETF.)59 2455 y(CIDR)24 b(and)g(ren)o(um)o(b)q(ering)f(sites)j (according)e(to)g(a)0 2504 y(CIDR)c(managemen)o(t)f(plan)h(needs)i(to)f(b)q (e)h(articulated)0 2554 y(to)16 b(the)g(In)o(ternet)h(comm)o(unit)o(y)c(as)j (the)g(most)f(cost)i(e\013ec-)0 2604 y(tiv)o(e)f(and)f(risk)h(adv)o(erse)h (in)e(con)o(trast)i(to)e(installing)f(new)0 2654 y(host)k(and)f(router)i(tec) o(hnology)e(throughout)h(the)g(In)o(ter-)0 2704 y(net.)k(The)15 b(latter)h(will)d(b)q(e)j(necessary)h(only)d(as)h(the)h(total)1034 195 y(n)o(um)o(b)q(er)10 b(of)g(hosts)i(in)e(the)h(In)o(ternet)i(approac)o (hes)e(the)h(lim-)1034 245 y(its)i(of)f(the)i(32)e(bit)h(address)h(\014eld.) 1093 320 y(F)m(rom)f(the)i(outset)g(\\sa)o(ving)f(the)h(In)o(ternet")h (requires)1034 370 y(m)o(uc)o(h)8 b(more)h(than)g(a)g(tec)o(hnical)h(mec)o (hanism)d({)i(it)g(requires)1034 419 y(e\013ectiv)o(e)14 b(managemen)o(t.)i (Deplo)o(ying)11 b(new)j(or)f(enhanced)1034 469 y(proto)q(cols)19 b(to)f(address)i(the)f(shortcomings)e(of)h(existing)1034 519 y(proto)q(cols)10 b(is)f(an)h(imp)q(ortan)o(t)d(subset)k(of)e(the)i(o)o(v)o (erall)d(prob-)1034 569 y(lem.)26 b(Ho)o(w)o(ev)o(er,)18 b(suc)o(h)g(deplo)o (ymen)o(t)e(can)h(not)g(o)q(ccur)h(in)1034 619 y(isolation)13 b(and)i(without)f(prop)q(er)h(dev)o(elopmen)o(t)f(and)h(de-)1034 668 y(plo)o(ymen)o(t)d(planning)h(and)g(managemen)o(t.)1093 743 y(What)e(b)q(egan)g(as)g(an)g(Arpanet)h(researc)o(h)h(testb)q(ed)g(has) 1034 793 y(gro)o(wn)j(in)o(to)g(a)g(v)n(ast)g(in)o(ternational)f(fabric)h (whic)o(h)g(m)o(ust)1034 843 y(rely)g(on)f(stable,)h(soundly-managed,)d (underlying)i(tec)o(h-)1034 893 y(nology)m(.)g(Therefore,)e(w)o(e)e(need)h (to)f(fo)q(cus)g(on)g(the)g(stabilit)o(y)1034 942 y(of)i(the)i(op)q (erational)e(en)o(vironmen)o(t)g(of)h(the)g(existing)g(and)1034 992 y(ev)o(olving)c(In)o(ternet)j(fabric.)k(The)12 b(curren)o(t)h(h)o(yp)q(e) f(o)o(v)o(er)f(the)1034 1042 y(next)i(generation)f(of)f(IP)h(as)g(an)g (immedia)o(te)e(requiremen)o(t)1034 1092 y(for)19 b(a)g(graceful)g (infrastructural)h(ev)o(olution)e(is)i(at)f(b)q(est)1034 1142 y(unnecessary)m(,)k(at)c(w)o(orst)i(dangerous,)g(since)g(it)e(creates)1034 1192 y(a)d(p)q(o)q(or)h(public)f(p)q(erception)i(of)e(the)h(In)o(ternet)h (and)e(ma)o(y)1034 1241 y(lead)e(to)f(degraded)i(In)o(ternet)g(service.)20 b(The)14 b(next)g(gener-)1034 1291 y(ation)d(of)h(IP)g(is)g(not)g(really)f (needed)j(as)e(urgen)o(tly)g(as)g(some)1034 1341 y(w)o(ould)j(lik)o(e)f(us)i (to)f(think.)22 b(There)17 b(is)e(no)g(reason)h(to)f(pre-)1034 1391 y(maturely)9 b(abandon)h(the)h(use)h(of)d(IPv4)i(un)o(til)e(w)o(e)i(can) g(gain)1034 1441 y(su\016cien)o(t)18 b(dev)o(elopmen)o(t)e(and)h(op)q (erational)f(exp)q(erience)1034 1490 y(and)c(dev)o(elop)g(consensus)i(on)e(a) g(new)g(net)o(w)o(ork)g(la)o(y)o(er)g(pro-)1034 1540 y(to)q(col,)17 b(so)h(as)f(to)g(address)i(the)f(problem)e(of)g(iden)o(tifying)1034 1590 y(more)d(than)h(4)f(billion)f(hosts)j(in)e(the)i(public)e(In)o(ternet.) 1093 1665 y(The)f(IAB/IESG/ISOC)f(w)o(ould)g(err)h(in)f(making)e(rash)1034 1715 y(decisions)23 b(regarding)e(crucial)h(c)o(hanges)h(in)f(the)g(In)o (ter-)1034 1764 y(net)g(tec)o(hnology)f(base)h(without)e(the)i(dev)o(elopmen) o(t)f(of)1034 1814 y(adequate)c(consensus)i(from)14 b(all)i(a\013ected)i (comm)o(uniti)o(es)1034 1864 y(\(User,)d(Op)q(erator,)h(Dev)o(elop)q(er\).)k (W)m(e)14 b(m)o(ust)f(accept)j(and)1034 1914 y(cultiv)n(ate)h(the)h(realit)o (y)f(of)f(the)i(In)o(ternet)h(as)e(a)g(co)q(op)q(era-)1034 1964 y(tiv)o(e)f(en)o(terprise)h(and)f(encourage)g(co)q(ordination)f(among) 1034 2013 y(en)o(tities)i(participating)f(in)h(the)g(gro)o(wth)g(and)g(ev)o (olution)1034 2063 y(of)c(the)i(In)o(ternet.)1211 2170 y Fg(IX.)j(Ac)n(kno)n (wledgemen)n(ts)1093 2255 y Fd(The)i(authors)g(w)o(ould)f(lik)o(e)f(to)i (thank)f(Ross)g(Callon)1034 2305 y(\(W)m(ell\015eet\))11 b(and)f(Elise)g (Geric)o(h)h(\(Merit\))g(for)f(helpful)g(con-)1034 2355 y(v)o(ersations.)20 b(P)o(eter)c(F)m(ord)f(ac)o(kno)o(wledges)f(supp)q(ort)i(from)1034 2405 y(the)g(U.S.)f(Departmen)o(t)g(of)f(Energy's)i(O\016ce)h(of)d(Energy) 1034 2455 y(Researc)o(h)h(\(Con)o(tract)g(No.)j(K)o(C0702\))c(and)g(Los)g (Alamos)1034 2504 y(National)e(Lab)q(oratory)h(\(Con)o(tract)g(No.)18 b(W-7405-ENG-)1034 2554 y(36\).)24 b(The)16 b(authors)g(also)g(thank)f(the)i (National)e(Science)1034 2604 y(F)m(oundation)i(for)h(con)o(tin)o(ued)g(supp) q(ort)h(for)f(w)o(orking)f(on)1034 2654 y(the)d(NSFNET)h(pro)r(ject.)k(The)14 b(w)o(ork)g(of)f(Y)m(ak)o(o)o(v)f(Rekh)o(ter)1034 2704 y(w)o(as)e(supp)q (orted)i(b)o(y)f(the)g(National)e(Science)j(F)m(oundation,)917 2822 y Fh(BBA-4)p eop %%Page: 5 5 bop 0 50 a Fh(CIDR)13 b(and)h(Ev)o(olution)h(of)e(IP)397 b(Pro)q(c.)17 b(INET)12 b('93)482 b(Braun,)13 b(F)m(ord,)g(Rekh)o(ter)0 195 y Fd(under)j(con)o(tract)g(NCR-92-19216.)k(Views)c(and)f(conclu-)0 245 y(sions)20 b(expressed)j(in)d(this)h(pap)q(er)g(are)f(not)h(necessarily)0 295 y(those)15 b(of)e(the)h(National)f(Science)i(F)m(oundation.)327 398 y Fg(References)195 481 y Fd([Adams)d(93])20 b(Adams,)37 b(A.,)h(\\The)d(Merit)420 531 y(P)o(olicy-Routing)c(Con\014gura-)420 581 y(tion)15 b(System",)g(ConneXions,)420 631 y(F)m(eb)f(93.)219 728 y([Bates)h(93])20 b(Bates,)33 b(T.,)e(Jouanigot,)g(J.,)420 777 y(Karren)o(b)q(erg,)25 b(D.,)e(Loth)o(b)q(erg,)420 827 y(P)m(.,)37 b(T)m(erpstra,)i(M.,)e(\\Rep-)420 877 y(resen)o(tation)25 b(of)f(IP)h(Routing)420 927 y(P)o(olicies)15 b(in)h(the)g(RIPE)g(Data-)420 977 y(base",)h(rip)q(e-81)f(via)f(anon)h(ftp)420 1026 y(from)c(ftp.rip)q (e.net,)h(F)m(eb)h(93)203 1123 y([Callon)e(92])20 b(Callon,)46 b(R.,)h(\\TCP)41 b(and)420 1173 y(UDP)9 b(with)g(Bigger)g(Addresses)420 1223 y(\(TUBA\),)33 b(A)g(Simple)e(Pro-)420 1273 y(p)q(osal)16 b(for)g(In)o(ternet)h(Address-)420 1323 y(ing)34 b(and)g(Routing",)k(RF)o(C) 420 1372 y(1347,)12 b(Jun)i(1992.)180 1469 y([Deering)g(93])20 b(Deering,)26 b(S.,)g(\\SIP:)e(Simple)420 1519 y(In)o(ternet)31 b(Proto)q(col",)j(IEEE)420 1569 y(Net)o(w)o(ork,)13 b(Ma)o(y)h(93.)237 1666 y([F)m(ord)f(93])20 b(F)m(ord)42 b(,)50 b(P)m(.)42 b(Braun,)51 b(H.,)420 1716 y(Rekh)o(ter,)40 b(Y.,)f(\\Impro)o(ving)420 1765 y(the)23 b(Routing)e(and)h(Address-)420 1815 y(ing)16 b(of)h(IP",)f(IEEE)i(Net)o(w)o(ork,)420 1865 y(Ma)o(y)13 b(93.)190 1962 y([F)m(rancis)h(93])20 b(F)m(rancis,)k(P)m(.)e(\\A)h(Near-T)m(erm)420 2012 y(Arc)o(hitecture)e(for)e(Deplo)o(ying)420 2062 y(Pip",)g(IEEE)g(Net)o (w)o(ork,)g(Ma)o(y)420 2111 y(93.)216 2208 y([F)m(uller)13 b(92])20 b(F)m(uller,)39 b(V.,)h(Li,)f(T.,)h(Y)m(u,)420 2258 y(J.,)22 b(V)m(aradhan,)h(K.,)f(\\Sup)q(er-)420 2308 y(netting:)48 b(an)28 b(Address)j(As-)420 2358 y(signmen)o(t)22 b(and)h(Aggregation)420 2407 y(Strategy",)e(RF)o(C)e(1338,)g(Jun)420 2457 y(92.)201 2554 y([Geric)o(h)14 b(92])20 b(Geric)o(h,)d(E.)f(P)m(.,)g(\\)g(Guidelines) 420 2604 y(for)h(Managemen)o(t)f(of)g(IP)i(Ad-)420 2654 y(dress)30 b(Space",)i(RF)o(C)27 b(1366,)420 2704 y(Oct)14 b(92.)1267 195 y([Katz)g(93])20 b(Katz,)129 b(D.,)f(F)m(ord)1454 245 y(,)15 b(P)m(.,)f(\\TUBA:)h(Replacing)g(IP)1454 295 y(with)29 b(CLNP",)g(IEEE)h (Net-)1454 345 y(w)o(ork)13 b(Magazine,)h(Ma)o(y)f(93.)1180 436 y([Kleinro)q(c)o(k)h(77])20 b(Kleinro)q(c)o(k,)i(L.,)g(F)m(arouk,)g(K.,) 1454 486 y(\\Hierarc)o(hical)31 b(Routing)f(for)1454 535 y(Large)43 b(Net)o(w)o(orks,")51 b(Com-)1454 585 y(puter)28 b(Net)o(w)o(orks)h(1)e (\(1977\),)1454 635 y(North-Holland)40 b(Publishing)1454 685 y(Compan)o(y)m(.)1134 776 y([Mo)q(c)o(k)n(ap)q(etris)14 b(87])20 b(Mo)q(c)o(k)n(ap)q(etris,)43 b(P)m(.V.,)f(\\Do-)1454 826 y(main)28 b(names)h(-)h(implemen-)1454 876 y(tation)i(and)h(sp)q(eci\014cation",)1454 926 y(RF)o(C)13 b(1035,)f(No)o(v)i(87.)1211 1017 y([Rekh)o(ter)g(92])20 b(ed.)j(Rekh)o(ter,)j(Y.,)e(Li,)h(T.)d(\\)1454 1067 y(A)g(Border)i(Gatew)o(a) o(y)d(Proto-)1454 1117 y(col)28 b(4)h(\(BGP-4\)",)j(In)o(ternet)1454 1166 y(Draft\(will)11 b(b)q(ecome)h(an)g(In)o(ter-)1454 1216 y(net)i(RF)o(C\),)f(Dec)i(1992.)1211 1308 y([Rekh)o(ter)f(93])20 b(Rekh)o(ter,)25 b(Y.,)g(Li,)f(T.)e(\\)h(An)1454 1357 y(Arc)o(hitecture)13 b(for)d(IP)h(Address)1454 1407 y(Allo)q(cation)g(with)h(CIDR",)f(In-)1454 1457 y(ternet)h(Draft\(will)c(b)q(ecome)i(an)1454 1507 y(In)o(ternet)15 b(RF)o(C\),)e(F)m(eb)h(1993.)1222 1598 y([Ullman)d(93])20 b(Ullman,)35 b(R.L.,)i(\\TCP/IP:)1454 1648 y(In)o(ternet)26 b(V)m(ersion)f(7",)i(RF)o(C) 1454 1698 y(1475,)12 b(Jun)i(1993.)1211 1796 y Fg(X.)k(Author)h(Information) 1093 1874 y Fd(Hans-W)m(erner)f(Braun)g(is)f(a)g(Principal)g(Scien)o(tist)h (at)1034 1924 y(the)e(San)f(Diego)g(Sup)q(ercomputer)h(Cen)o(ter.)24 b(P)o(eter)16 b(F)m(ord)1034 1974 y(is)f(a)g(Mem)o(b)q(er)g(of)g(the)h(T)m (ec)o(hnical)f(Sta\013)g(at)h(Los)f(Alamos)1034 2023 y(National)c(Lab)q (oratory)m(.)16 b(Y)m(ak)o(o)o(v)11 b(Rekh)o(ter)i(is)f(manager)f(of)1034 2073 y(high)17 b(p)q(erformance)g(net)o(w)o(orking)g(at)g(T.J.)g(W)m(atson)f (Re-)1034 2123 y(searc)o(h)f(Cen)o(ter,)g(IBM)f(Corp)q(oration.)917 2822 y Fh(BBA-5)p eop %%Trailer end userdict /end-hook known{end-hook}if %%EOF From mak@merit.edu Tue Dec 28 14:13:11 1993 Return-Path: mak@merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by picard (8.6.4/8.6.4) with SMTP id OAA00804 for ; Tue, 28 Dec 1993 14:12:41 -0500 Received: by merit.edu (5.65/1123-1.0) id AA01930; Tue, 28 Dec 93 14:13:12 -0500 Message-Id: <9312281913.AA01930@merit.edu> To: Steve Coya Cc: ipng@cmf.nrl.navy.mil, lkeiper@cnri.reston.va.us Subject: Re: Next teleconference will be January 17, 1993 In-Reply-To: Your message of "Tue, 28 Dec 1993 13:26:27 EST." <9312281326.aa07469@IETF.CNRI.Reston.VA.US> Date: Tue, 28 Dec 1993 14:13:11 -0500 From: Mark Knopper I will be able to attend this one. My new phone number doesn't exist yet but I'll forward it once it does. Meanwhile the folks at Merit know how to find me. Mark > From: Steve Coya > To: ipng@cmf.nrl.navy.mil > CC: lkeiper@CNRI.Reston.VA.US > Lois will send out the standard note with phone numbers. PLEASE respond > as soon as possible, even if only to send regrets, but certainly if a > different phone number should be used. > > Thanks. > > > Steve From rcallon@wellfleet.com Tue Dec 28 15:23:15 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard (8.6.4/8.6.4) with SMTP id PAA00351 for ; Tue, 28 Dec 1993 15:19:12 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04524; Tue, 28 Dec 93 15:05:55 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA17879; Tue, 28 Dec 93 15:14:43 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA07600; Tue, 28 Dec 93 15:23:15 EST Date: Tue, 28 Dec 93 15:23:15 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312282023.AA07600@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil, scoya@CNRI.Reston.VA.US Subject: Regrets, Re: Next teleconference will be January 17, 1993 Cc: lkeiper@CNRI.Reston.VA.US Subject: Next teleconference will be January 17, 1993 Lois will send out the standard note with phone numbers. PLEASE respond as soon as possible, even if only to send regrets, but certainly if a different phone number should be used. I will not be able to attend the meeting via Phone on January 17th, due to being in Tahoe at the ATM forum meeting (hopefully with both legs still intact, since I will be downhill skiing the previous day for the first time since 1974). Ross From smb@research.att.com Tue Dec 28 16:37:45 1993 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard (8.6.4/8.6.4) with SMTP id QAA00566 for ; Tue, 28 Dec 1993 16:44:00 -0500 From: smb@research.att.com Message-Id: <199312282144.QAA00566@picard> Received: by gryphon; Tue Dec 28 16:37:46 EST 1993 To: ipng@cmf.nrl.navy.mil Subject: lots of addresses per host Date: Tue, 28 Dec 93 16:37:45 EST During the roundtable part of the conference call a few weeks ago, I tossed out the idea of designing for lots of addresses per host. I thought it would be useful for me to write down some of the reasons why I think this is important. If there's enough interest, I'll even polish it up into a white paper. First, the community is already encoding services in the host name. I pick up files from ftp.foo.bar, find DNS resolvers on ns.org, etc. This may or may not be a good idea -- but it's very real. Should/will this be generalized to separate IP addresses for these services? ftp.research.att.com might always be bound to 192.20.225.123 -- but the physical machine could change. There's a stronger case for separate addresses if you want to offer a different flavor of service on a standard port. It's annoying to have to log in as archie on archie.foo.net, or to have to use a different port number, but in general, port 23 offers a login service, not an archie service. Similarly, we offer two different anonymous ftp archives; it would be nice to have them both live on port 21 on the same physical machine. I won't argue if you claim that what we really need is an enhanced DNS, one that generalized the concept of MX records to (a) work for other services than mail, and (b) supplied port numbers as well. But that would be a change comparable in magnitude to IPng -- not because the transport and network layers would change, but because all of the applications would have to. (Even today, there are some non-MX mailers around, I believe.) Unless and until that happens, people will continue to encode service names in the DNS. Permitting many addresses per host will make that much easier. We may also want to encode billing type information in the address. It's useful to know, in as fundamental a way as possible -- the IP address -- that you're going to pay for the conversation. Or maybe you'll even pay a premium to the service provider, as with ``900 numbers'' in the U.S. phone system. On the other hand, a service provider on a pay-per-packet net might prefer collect calls, so that you pay to download files from the ftp archive graciously provided. There are already models for this -- UUNET has a 900 number for anonymous uucp access. The phone company does the billing, UUNET gets its money, and no prearrangement is needed. Again, I'm not claiming that this is the best, or only, way to do billing. I am saying that it's easy, and demands very little in the way of changes to anything else, which makes it attractive. Of course, if a host is going to be billed for the packets it sends or receives, the owners may want to bill the individual users. You can either add complicated real-time accounting goo to the kernel -- or you can give each user or each login session a separate IP address. Why not, if addresses are very cheap? There are lots of other benefits to this notion, such as the ability to use a network-layer encryption protocol to provide fine-grain security, solely at the whim of an individual site. My user foo might share a key with your gateway encryptor, giving me the degree of accountability I need, while not burdening you with the expense of a transport-layer encryption gadget. I could go on ad nauseum; I have several more examples I could describe, and I'm sure there are many more I haven't thought of. My basic premise, though, is that we want to make sure we're very liberal in our calculations of the proper size for an address field, *after* all of the administrative hierarchies swallow up the high-order bits. At a very rough guess, we want to allow for ~2^6 IP addresses per host -- more, if the IPng chosen uses an analog to fixed-length subnet masks, since the distribution of IP addresses among hosts on a subnet is likely to be very uneven. --Steve Bellovin From ariel@world.std.com Wed Dec 29 22:01:51 1993 Return-Path: ariel@world.std.com Received: from world.std.com (ariel@world.std.com [192.74.137.5]) by picard (8.6.4/8.6.4) with SMTP id WAA05567 for ; Wed, 29 Dec 1993 22:01:36 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA17966; Wed, 29 Dec 1993 22:01:51 -0500 Date: Wed, 29 Dec 1993 22:01:51 -0500 From: ariel@world.std.com (Robert L Ullmann) Message-Id: <199312300301.AA17966@world.std.com> To: ipng@cmf.nrl.navy.mil To: ipng@cmf.nrl.navy.mil Subject: Info Highway - 28 Companies Newsgroups: comp.dcom.telecom Organization: The World in Boston Xref: world comp.dcom.telecom:39240 Path: world!news.kei.com!sol.ctr.columbia.edu!spool.mu.edu!telecom-request Date: 22 Dec 1993 14:28:14 GMT From: JIM BURKITT Newsgroups: comp.dcom.telecom Subject: Info Highway - 28 Companies Message-ID: Organization: TELECOM Digest Sender: telecom@eecs.nwu.edu Approved: telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 13, Issue 836, Message 2 of 17 Lines: 13 Bob Rosenberg asked about 28 companies supporting a Info Super Highway. The December 20, 1993 issue of {Telephony} on page eight talks about the Cross Industry Working Team (XIWT). This group plans to issue a white paper early next year on architectural and technical requirements for the super highway. The members of the team are: Apple, AT&T, Bellcore, BellSouth, Cable Television Laboratories, Citicorp, DEC, GTE Labs, H-P, IBM, Intel, MCI, McCaw, Motorola, NYNEX, Pac Bell, Silicon Graphics, Sun, Southwestern Bell, CBEMA, Cisco, Financial Services Consortium, Hughes Network Systems, Science Applications International, Sprint, 3Com,West Publishing and Xerox. -- Robert Ullmann Ariel@World.STD.COM +1 617 693 1315 Quand Maigret poussa la porte du Tabac Fontaine, vers une heure et demie, le patron du bar, qui venait de se lever, descendait lentement un escalier en colima gon qui s'amor gait dans l'arri hre-salle. ... Arriv i derri hre le comptoir, il repousa le gar gon d'un geste n igligent de la main, saisit une bouteille de vin blanc, un verre, m ilangea au vin de l'eau min irale et, la t jte renvers ie en arri hre, se gargarisa. -- Simenon [text is ISO 10646 UTF-1 universal character set] From sob@hsdndev.harvard.edu Wed Dec 29 23:12:16 1993 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard (8.6.4/8.6.4) with SMTP id XAA05699 for ; Wed, 29 Dec 1993 23:12:01 -0500 Date: Wed, 29 Dec 93 23:12:16 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312300412.AA12267@hsdndev.harvard.edu> To: ariel@world.std.com, ipng@cmf.nrl.navy.mil Subject: Cross Industry Working Team I had heard in passing a note about this on the news, thanks for the info. I wonder how much they will think about data, mostly these groups have seen the Info Hwy as an automagic video store. Scott From bound@zk3.dec.com Sun Jan 2 11:53:02 1994 Return-Path: bound@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com [16.140.0.3]) by picard (8.6.4/8.6.4) with SMTP id LAA19770 for ; Sun, 2 Jan 1994 11:52:52 -0500 From: bound@zk3.dec.com Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA04130; Sun, 2 Jan 1994 11:53:05 -0500 Received: by abyss.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91); id AA24889; Sun, 2 Jan 1994 11:53:03 -0500 Message-Id: <9401021653.AA24889@abyss.zk3.dec.com> To: smb@research.att.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: lots of addresses per host In-Reply-To: Your message of "Tue, 28 Dec 93 16:37:45 EST." <199312282144.QAA00566@picard> Date: Sun, 02 Jan 94 11:53:02 -0500 X-Mts: smtp Steve, >During the roundtable part of the conference call a few weeks ago, >I tossed out the idea of designing for lots of addresses per host. >I thought it would be useful for me to write down some of the reasons >why I think this is important. If there's enough interest, I'll >even polish it up into a white paper. I think this is a good idea. /jim