From scoya@CNRI.Reston.VA.US Mon Jan 24 17:43:46 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA01156 for ; Mon, 24 Jan 1994 19:25:46 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17726; 24 Jan 94 17:43 EST To: ipng@cmf.nrl.navy.mil cc: lkeiper@CNRI.Reston.VA.US Subject: IPNG Telechat schedule Date: Mon, 24 Jan 94 17:43:46 -0500 From: Steve Coya Message-ID: <9401241743.aa17726@IETF.CNRI.Reston.VA.US> Greetings, Due to the IAB Retreat and the ISOC Board of Trustee meeting the second week of February, the IPNG telechat schedule for the next few weeks is as follows: Feb 14 Feb 28 Mar 14 If needed, I can accommodate a teleconference on March 21. This is the week just before the IETF meeting in Seattle, and we'll be very busy here. But, since it's for you all :-), we can set up something if needed. I imagine the final decision will be made at the March 14 telechat. Steve From ipng-request@nic.near.net Mon Jan 24 19:38:51 1994 Return-Path: ipng-request@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 WAA02218 for ; Mon, 24 Jan 1994 22:42:47 -0500 Received: from nic.near.net by nic.near.net id aa20024; 24 Jan 94 22:43 EST Received: from netmail2.microsoft.com by nic.near.net id aa20018; 24 Jan 94 22:43 EST Received: by netmail2.microsoft.com (5.65/25-eef) id AA02233; Mon, 24 Jan 94 19:43:00 -0800 From: jallard@microsoft.com Message-Id: <9401250343.AA02233@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 24 Jan 94 19:43:00 PST To: ipng@nic.near.net, jcurran@nic.near.net Cc: bound@zk3.dec.com Subject: Re: Interoperation, Encapsulation, Translation, and Dual Stacks Date: Mon, 24 Jan 94 19:38:51 >>Now, of course, there's a big difference between supporting two different >>application suites over two different protocol stacks (e.g. TCP over IP >>and NetWare over IPX), and supporting a single API for applications which >>works over two distinctly different network layer protocols. I would guess >>that if you already have a tightly integrated processing stack, addng a new >>network protcol would represent changes to a majority of the existing code. >>Jim, do you feel that most other vendors handle multiple protocols in the >>same manner? > >>From what I learned here is how it works: > >TCP/IP : Sockets or derivative on Servers. For PCs WINsockets. > over Netbios RFC 1001/1002 needed, >OSI: XTI or TLI (these can do TCP/IP well too). > over Netbios you need MAP/TOP interface. >Others are usually proprietary or derivations of sockets or xti in >semantics only. in windows nt, and soon in chicago (next major version of windows), we support the "windows sockets" api over multiple transports as our primary transport interface. windows sockets is a subset of the bsd stuff with some windows-centric enhancements (e.g., sock_raw and some ioctls() not supported, async notification added). under nt, we've defined an extensible mechanism by which any xport provider can leverage our sockets code by adding in a "helper DLL" (DLL==share library in windows-speak) which takes care of addressing issues and some other xport-specific stuff. in nt we ship stacks and winsock support for tcp/ip, ipx/spx, and appletalk. decnet and osi have been developed by third parties and work with windows sockets in nt as well. in chicago we will deliver tcp/ip and ipx/spx support. in the next release of nt, we'll probably add support for any netbios compatible transport in addition to what i've covered above (pls don't quote me on this)... windows sockets ("winsock") is a collaboration of over 30 vendors in an open process to define a binary compatible interface so that any winsock app can run over any winsock stack. we'll be addressing some outstanding issues starting rsn on the mailing list, including a better mechanism to handle xport independence (ala sun's netdir routines perhaps). the current spec (v1.1) can be found on file://ftp.microsoft.com/advsys/ winsock in a number of formats. for those interested i can provide the helper dll spec as well as nt centric issues like socket inheritance, etc.. as necessary. i don't know how much we want to get into api's in the ipng proposals and so forth, but we (msft) would be happy to assist the various groups to "prove" that windows sockets could handle ipng with minor modifications to the existing windows transport interface standard if you like. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 From mankin Mon Jan 24 21:08:05 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id VAA01767; Mon, 24 Jan 1994 21:07:58 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA06581; Mon, 24 Jan 94 21:08:05 EST Date: Mon, 24 Jan 94 21:08:05 EST Message-Id: <9401250208.AA06581@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: re: MBONE logistics Cc: mankin I have answered Paul's private mail on this. We're going to up the ttl to overcome the high threshold on the NTT link. I don't know if the link will sustain the whiteboard load, so unless we get a chance to test that, I'm not going to up the wb ttl. Allison / mankin@cmf.nrl.navy.mil From bound@zk3.dec.com Mon Jan 24 22:28:37 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA02152 for ; Mon, 24 Jan 1994 22:28:15 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA01017; Mon, 24 Jan 94 19:28:45 -0800 Received: by xirtlu.zk3.dec.com; id AA16929; Mon, 24 Jan 1994 22:28:44 -0500 Message-Id: <9401250328.AA16929@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: CLNP is it good enough for the future Date: Mon, 24 Jan 94 22:28:37 -0500 X-Mts: smtp Just a question I have been asked a few times now we should probably ask ourselves. Is CLNP good enough for the future IPng regarding new technology requirements. It is very much just like IP. /jim From bound@zk3.dec.com Mon Jan 24 22:31:15 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA02161 for ; Mon, 24 Jan 1994 22:33:12 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA01206; Mon, 24 Jan 94 19:31:23 -0800 Received: by xirtlu.zk3.dec.com; id AA16982; Mon, 24 Jan 1994 22:31:22 -0500 Message-Id: <9401250331.AA16982@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: PhV as a Transition Date: Mon, 24 Jan 94 22:31:15 -0500 X-Mts: smtp Can I now ask after about 40 man hours working with our transition gurus that any comments stating PhV transition did not work that we please say where and what were the technical problems in detail. Stating that it does not work or that someone stated it broke will not help me answer the questions. thanks /jim From Robert_Ullmann.LOTUS@CRD.lotus.com Mon Jan 24 23:13:16 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA02306 for ; Mon, 24 Jan 1994 23:07:01 -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 AA02475; Mon, 24 Jan 94 23:10:38 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA09609; Mon, 24 Jan 94 23:13:16 EST Date: Mon, 24 Jan 94 23:13:16 EST Message-Id: <9401250413.AA09609@Mail.Lotus.com> Received: by DniMail (v1.0); Mon Jan 24 23:13:14 1994 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Brian's paper/Translation Brian (et al :-) In section B you state that translation is impratical, and state two reasons, each of which sharply highlight differences between IPAE and CATNIP (or TUBA); while your objections and conclusions may be true of IPAE, both TUBA and CATNIP were designed not to raise these problems. (re B1) CATNIP for example defines IPv7 to be as near as possible to being the functional equivalent of IPv4, while TUBA observes that CLNP is also (which should not surprise *anyone* familiar with the origin of CLNP :-) Please distinguish address translation from packet format translation. The former is an unmitigated disaster, while the latter is very nearly trivial (except for all the details.) No proposal is going to magically invest IPv4 with a larger address space. It may hand wave and obfuscate, but it won't actually be able to do it. The IPv4 systems will only ever be able to operate with a subset of the global network that is approximately the same size and dimensionality as the IPv4 space itself. Anything else is snake oil. (re B2) the C bit reflects an implicit premise in SIPP/IPAE that a host must know what "flavor" the remote host is. This is bogus; not only does it not need to know; we in fact do not want it to know. The only thing a host need know (and that only at the interface to the attached subnetwork) is what packet format(s) its adjacent router knows, so that the datagrams will not be lost. IMHO, the objection in B2 applies only to IPAE; to its attempt to create a mechanism (C bit) to solve a problem that doesn't exist in the first place. TUBA (and CATNIP) invoke no such mechanism. ---- In short, please separate address translation from "packet translation". They are entirely different things. With my best regards, Robert From sob@hsdndev.harvard.edu Mon Jan 24 23:25:47 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA02394 for ; Mon, 24 Jan 1994 23:24:01 -0500 Date: Mon, 24 Jan 94 23:25:47 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9401250425.AA05736@hsdndev.harvard.edu> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future Well, it would sorta depend on the agreed requirements I'd guess. Scott From jcurran@nic.near.net Mon Jan 24 23:34:53 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA02728 for ; Tue, 25 Jan 1994 01:00:49 -0500 Message-Id: <199401250600.BAA02728@picard.cmf.nrl.navy.mil> Received: from foo.near.net by nic.near.net id aa23285; 24 Jan 94 23:36 EST To: Robert_Ullmann.LOTUS@crd.lotus.com, Greg_Minshall@novell.com, bound@zk3.dec.com, rcallon@wellfleet.com cc: ipng@cmf.nrl.navy.mil Subject: Directions to BBN Date: Mon, 24 Jan 1994 23:34:53 -0500 From: John Curran For those folks coming to BBN tomorrow, here's directions: Follow Route 128/95 to exit 46A (Route 2 East - Cambridge/Arlington). Take Route 2 East toward Cambridge about 6 miles. The expressway portion of Route 2 ends at the Fresh Pond Parkway (Routes 2, 3, and 16). You will see the Alewife MBTA station on your right. Turn right on Fresh Pond Parkway -- southbound. Proceed down route 2 & 3 over the bridge and into the Fresh Pond Rotary. Leave the rotary at your first right (Concord Ave.). Proceed to the first set of lights and turn right onto Moulton Street. BBN is on the corner of Moulton and Concord Streets. (10 Moulton St.) Turn right into the visitor parking area and enter the building. Tell the receptionist that you're attending the "IPng Meeting". The conference starts at 12:30 EST, although we'll be ready from 11:30 onward. There will be refreshments served. /John From dino@cisco.com Mon Jan 24 20:49:32 1994 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 XAA02469 for ; Mon, 24 Jan 1994 23:52:05 -0500 Received: by regal.cisco.com id AA24477 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Mon, 24 Jan 1994 20:49:32 -0800 Date: Mon, 24 Jan 1994 20:49:32 -0800 From: Dino Farinacci Message-Id: <199401250449.AA24477@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 Sun, 23 Jan 94 15:02:10 -0500 <9401232002.AA10061@xirtlu.zk3.dec.com> Subject: Interoperation, Encapsulation, Translation, and Dual Stacks >> A misnomer I THINK (not sure) is that vendors who have OSI stacks just >> move the network layer (CLNP) and below to the IPv4 code base and fix >> the transport and BIND DNS. WRONG it won't work this way, and thats all >> I will say for now. This is all we did (cisco) to support TCP and UDP over CLNP. And it seems to be working (for almost a year now) pretty well. In fact, it turns out to be a very good managment tool for OSI networks (that is using TELNET over a CLNP based infrastructure). Dino From bound@zk3.dec.com Mon Jan 24 23:51:11 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA02475 for ; Mon, 24 Jan 1994 23:54:16 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA05628; Mon, 24 Jan 94 20:51:18 -0800 Received: by xirtlu.zk3.dec.com; id AA18026; Mon, 24 Jan 1994 23:51:17 -0500 Message-Id: <9401250451.AA18026@xirtlu.zk3.dec.com> To: Robert_Ullmann.LOTUS@CRD.lotus.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Brian's paper/Translation In-Reply-To: Your message of "Mon, 24 Jan 94 23:13:16 EST." <9401250413.AA09609@Mail.Lotus.com> Date: Mon, 24 Jan 94 23:51:11 -0500 X-Mts: smtp Rob, It does no good to call things bogus. It takes away from the effect and is not professional. Some engineers spent a lot of time on IPAE and I think we need to be gracious and professional. I never heard anyone say TP-IX or CATNIP is bogus but only praise it from all camps as a comment, you should know. >From a Bill Cosby show. A guy came to dinner with Bills daughter and he was never known by the family and they were sneaking around and hiding out. The first time they met the family was at dinner and they find out that this guy and his daughter were seeing each other behind the scenes for 6 months and trust was broken. The guy sitting at the table asks Bill gee do you all not like me. And Bill replied. Its not that. He asks the guy if I presented you with a wonderful steak dinner, baked potatoe, veggies, and a glass of fine wine with my best dinnerware you'd love it right. But if I put all that food on top of my garbage can lid and your wine in an old milk carton you may reject this great meal because of the presentation. My friend its not that we don't like you its the way you have been presented to the family. /jim From bound@zk3.dec.com Tue Jan 25 00:17:55 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA02598 for ; Tue, 25 Jan 1994 00:18:35 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA07161; Mon, 24 Jan 94 21:18:03 -0800 Received: by xirtlu.zk3.dec.com; id AA18275; Tue, 25 Jan 1994 00:18:01 -0500 Message-Id: <9401250518.AA18275@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Interoperation, Encapsulation, Translation, and Dual Stacks In-Reply-To: Your message of "Mon, 24 Jan 94 20:49:32 PST." <199401250449.AA24477@regal.cisco.com> Date: Tue, 25 Jan 94 00:17:55 -0500 X-Mts: smtp >>> A misnomer I THINK (not sure) is that vendors who have OSI stacks just >>> move the network layer (CLNP) and below to the IPv4 code base and fix >>> the transport and BIND DNS. WRONG it won't work this way, and thats all >>> I will say for now. > This is all we did (cisco) to support TCP and UDP over CLNP. And it > seems to be working (for almost a year now) pretty well. In fact, > it turns out to be a very good managment tool for OSI networks (that > is using TELNET over a CLNP based infrastructure). In this case it appears you have a true dual stack. I was speaking of Hosts but thats OK. On a Host most OSI implementations are under the AF_ISO comm domain. The IP is under the AF_INET domain. I figure the best way right now is to implement IPng under AF_INET domain where the infrastructure will change the least. Which domain is this code running under AF_INET or AF_ISO or OSI, et al? /jim From bound@zk3.dec.com Tue Jan 25 00:28:31 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA02631 for ; Tue, 25 Jan 1994 00:29:49 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA07807; Mon, 24 Jan 94 21:28:38 -0800 Received: by xirtlu.zk3.dec.com; id AA18361; Tue, 25 Jan 1994 00:28:37 -0500 Message-Id: <9401250528.AA18361@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu Cc: ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-Reply-To: Your message of "Mon, 24 Jan 94 22:28:37 EST." <9401250328.AA16929@xirtlu.zk3.dec.com> Date: Tue, 25 Jan 94 00:28:31 -0500 X-Mts: smtp Scott, Well there are a few of us who feel these are requirements: 1. PMTU discovery with backwards compatibility only for fragmenation. 2. Flow IDs. 3. Multicast. 4. Continued support for Host Gateway Servers for LANs. 5. Backwards compatibility with DHCP and BOOTP. The other point is if the IETF is going to change CLNP to support the above how will this also get changed in ISO and how quick. Or will CLNP be the same at all so why call it CLNP? I am sure Host vendors will not absorb the cost to support both ISO CLNP and the associated routing and discovery protocols and an IETF IPng version of those protocols, and an old IPv4 stack. The other question asked previously applies. Would the Host vendors stop charging for CLNP if it was now IPng. I doubt it. So in addition to transition IPng will cost more maybe too. Better do something pretty good for the customers to also pay for the carrot. And this may have to be more than vanilla CLNP. /jim From dino@cisco.com Mon Jan 24 22:07:02 1994 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 BAA02761 for ; Tue, 25 Jan 1994 01:09:20 -0500 Received: by regal.cisco.com id AA05697 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Mon, 24 Jan 1994 22:07:02 -0800 Date: Mon, 24 Jan 1994 22:07:02 -0800 From: Dino Farinacci Message-Id: <199401250607.AA05697@regal.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil In-Reply-To: bound@zk3.dec.com's message of Tue, 25 Jan 94 00:17:55 -0500 <9401250518.AA18275@xirtlu.zk3.dec.com> Subject: Interoperation, Encapsulation, Translation, and Dual Stacks >> Which domain is this code running under AF_INET or AF_ISO or OSI, et al? If your asking me this question, there is no concept of AF_*. It is a dual stack and TCP and UDP can handle variable length addresses. Dino From jcurran@nic.near.net Tue Jan 25 02:24:55 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA02882 for ; Fri, 28 Jan 1994 16:34:16 -0500 Message-Id: <199401282134.QAA02882@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa10595; 25 Jan 94 2:24 EST To: bound@zk3.dec.com cc: sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-reply-to: Your message of Tue, 25 Jan 1994 00:28:31 -0500. <9401250528.AA18361@xirtlu.zk3.dec.com> Date: Tue, 25 Jan 1994 02:24:55 -0500 From: John Curran -------- CLNP addresses the immediate problem faced by IPv4 (address depletion). SIPP also addresses this immediate problem. As it turns out, we are driven to consider an IPng because of this pressing need, but the chance to deploy a new network-layer Internet protocol will only come once, so we should seriously consider exactly what additional capabilities should be included. Note that IPng is not simply about the _network_ layer, but it is about the architecture of the entire Internet service suite. This will be the only chance we have to adopt new TCP, service location, authentication, or other capabilities into the _base_ set of IPng requirements. Capabilities such as multicasting or authentication do not succeed unless the support becomes an inherent aspect of IPng. Some of these "future requirements" you've already mentioned: Flows, PMTU, multicasting, etc. There are other capabilities that you have not mentioned, which I will add: security, autoconfiguration and autoregistration, transport-layer adaptability to new network protocols, a formal service registration and location system, and more. If, when we get done, applications are still directly selecting their own port numbers and finding each other via hacks (such as "ftp.foo.com"), we will have actually failed, and the deployment of many production services on the Internet will be greatly delayed or prevented altogether. The need for common "client-server" functionality is great, and the result of not standardizing what we've learned from multiple DNS and SMTP servers is that each new application protocol (from telnet to gopher to WWW) is developing independent approaches to load leveling and redundancy. The same retracing is being done in each application protocol with respect to user authentication because of a lack of common application architecture. If we're going to tell the entire Internet applications community to "just migrate to this new address format", it would be in our best interest to provide them new interfaces to the network which result in needed capabilities being deployed. Sorry to rave, /John From jcurran@nic.near.net Tue Jan 25 02:57:14 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id GAA03560 for ; Tue, 25 Jan 1994 06:52:14 -0500 Message-Id: <199401251152.GAA03560@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa15081; 25 Jan 94 2:57 EST To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: PhV as a Transition In-reply-to: Your message of Mon, 24 Jan 1994 22:31:15 -0500. <9401250331.AA16982@xirtlu.zk3.dec.com> Date: Tue, 25 Jan 1994 02:57:14 -0500 From: John Curran -------- ] From: bound@zk3.dec.com ] Subject: PhV as a Transition ] Date: Mon, 24 Jan 94 22:31:15 -0500 ] ] Can I now ask after about 40 man hours working with our transition gurus ] that any comments stating PhV transition did not work that we please say ] where and what were the technical problems in detail. Stating that it ] does not work or that someone stated it broke will not help me answer ] the questions. The major deployment hurdle for PhaseV was the requirement to bring up _new_ software (in this case, Phase V routing) in an existing production environment (Phase IV) where both PhaseV and PhaseIV directly interacted with one another. The result of PhaseIV/PhaseV interaction was an extremely high level of coordination required for successful deployment, and elimination of the ability to safely experiment with the new protocol. My basis for this statement is discussion with the existing NEARNET base which would rather undergo a controlled transition to a totally independent protocol (IPv4) than have to debug interactions between interrelated network protocols. The fact that IPv4 does not interfere or even try to "help them" by interoperating with their PhaseIV base is a big plus in this scenario. Sorry, but this has to be said... anyone who causes two different systems to interact increases the level of knowledge required to perform problem analysis by a factor of two. Having two two _distinct_ systems allows problems to be handle by people with non-overlapping skill bases. Personally, in an age where the complexity of systems is going up dramatically, I cannot conceive of intentionally causing additional complexities and failure modes by having network protocols directly interact with one another. /John From brian@dxcoms.cern.ch Tue Jan 25 09:01:46 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA03042 for ; Tue, 25 Jan 1994 03:00:17 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27887; Tue, 25 Jan 1994 09:01:47 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA04644; Tue, 25 Jan 1994 09:01:47 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401250801.AA04644@dxcoms.cern.ch> Subject: Yesterday's discussion in Amsterdam To: ipng@cmf.nrl.navy.mil Date: Tue, 25 Jan 1994 09:01:46 +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: 841 Just a few words on the IPng session in the RIPE meeting in Amsterdam yesterday. The audience (~50 people I guess) were essentially all from European IP operators in many countries. I gave a short intro and opened the floor, with able assistance from Daniel. It was very difficult to get people to talk about technical issues rather than process. The messages I noted were- On process: We don't believe the July 1994 date for a recommendation. Set a cutoff date for "final" proposals It is urgent to decide You can't guess the future, decide now on today's evidence On issues: A flat address space is bad. Need for extensible addresses (operators seem to feel this strongly). Allow for many local providers in one area Policy routing is key Go for simplicity Slim pickings I am afraid. Brian From francis@cactus.ntt.jp Tue Jan 25 10:04:15 1994 Return-Path: francis@cactus.ntt.jp Received: from ntt-sh.ntt.jp (nttta.NTT.JP [129.60.57.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA01441 for ; Mon, 24 Jan 1994 20:00:55 -0500 Received: by ntt-sh.ntt.jp (5.59/ntt-sh-04h) with TCP; Tue, 25 Jan 94 10:01:45 JST Received: from cactus.ntt.jp by ntt-twins.ntt.jp (8.5/NTTcs02b) id KAA00487; Tue, 25 Jan 1994 10:01:43 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Tue, 25 Jan 94 10:04:15 JST Date: Tue, 25 Jan 94 10:04:15 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9401250104.AA29281@cactus.ntt.jp> To: ipng@cmf.nrl.navy.mil Subject: MBONE conference logistics Sorry to bother the whole list with this, but I wasn't sure who to talk to about it. I'm wondering if whoever is going to manage the mbone conference could set the TTL to something greater than 127. If it is 127, then every video thing will come over NTT's small (56kbps) link, and I won't be able to receive the IPng conference..... Thanks, PF From bound@zk3.dec.com Tue Jan 25 08:27:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA04926 for ; Tue, 25 Jan 1994 10:00:41 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA19846; Tue, 25 Jan 94 05:27:39 -0800 Received: by xirtlu.zk3.dec.com; id AA02145; Tue, 25 Jan 1994 08:27:29 -0500 Message-Id: <9401251327.AA02145@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Interoperation, Encapsulation, Translation, and Dual Stacks In-Reply-To: Your message of "Mon, 24 Jan 94 22:07:02 PST." <199401250607.AA05697@regal.cisco.com> Date: Tue, 25 Jan 94 08:27:23 -0500 X-Mts: smtp Dino, Sorry yes I was asking you. Well on a UNIX Host when you configure the network kernel (and in other OSs too) you select a commuications domain to support that infrastructure within the contextsof the operating system The BSD 4.X derivative does this by specifying a communications domain which relates directly back to the creation of a socket has the handle for the application. One of the parameters is the communications doma (e.g. AF_PUP, AF_XNS, AF_ISO,F_INET). For the Internet protocol family the comm domain is AF_INET. For products that also support an OSI stack on the Host they open the socket with AF_ISO (or the ISO family of protocols). What I am pointing to here (and this is just the beginning) is that I believe that IPng should run under the AF_INET comm domain on a Host implementation. Hence, its not a dual stack but an integrated network layer. The network layer will provide services to the transport layer (or the transport layer to the network layer) depending on whether IPng or IPv4 is being used. Its not two separate comm domains in my mind. I would not build two separate code paths to perform fragmentation and reassembly, as an example. I would have a module that checks the protocol state and make the decision in that manner (most likely based on the header of IPng or IPv4 version number). Is this clear? thanks /jim From bound@zk3.dec.com Tue Jan 25 08:47:56 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA05123 for ; Tue, 25 Jan 1994 10:23:21 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA20611; Tue, 25 Jan 94 05:48:04 -0800 Received: by xirtlu.zk3.dec.com; id AA02819; Tue, 25 Jan 1994 08:48:02 -0500 Message-Id: <9401251348.AA02819@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-Reply-To: Your message of "Tue, 25 Jan 94 02:24:55 EST." <9401251236.AA07509@decvax.dec.com> Date: Tue, 25 Jan 94 08:47:56 -0500 X-Mts: smtp John, Just want to reinforce your comments on ports. >If, when we get done, applications are still directly selecting their >own port numbers and finding each other via hacks (such as "ftp.foo.com"), >we will have actually failed, and the deployment of many production services >on the Internet will be greatly delayed or prevented altogether. The need >for common "client-server" functionality is great, and the result of not >standardizing what we've learned from multiple DNS and SMTP servers is that >each new application protocol (from telnet to gopher to WWW) is developing >independent approaches to load leveling and redundancy. The same retracing >is being done in each application protocol with respect to user authentication >because of a lack of common application architecture. I have wracked my brain on avoiding ports and even looked at TP4 but its the model. Each time I come up with a solution it won't work. But I would like this to be dynamic. Another reason is a busines capitalistic reason (being a die hard anti-socialist) in that if I build a great client/server application on the street as a small business person. I don't like the idea of having to ask for a port assignment from some authority. On all your points I want to say I completely agree with all the statements at my end. Lets get ready for the future. /jim From brian@dxcoms.cern.ch Tue Jan 25 16:14:00 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA05016 for ; Tue, 25 Jan 1994 10:12:30 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20863; Tue, 25 Jan 1994 16:14:00 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28413; Tue, 25 Jan 1994 16:14:00 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401251514.AA28413@dxcoms.cern.ch> Subject: Re: what do you all think? To: ipng@cmf.nrl.navy.mil Date: Tue, 25 Jan 1994 16:14:00 +0100 (MET) In-Reply-To: <9401242106.AA16247@cabernet.wellfleet> from "Ross Callon" at Jan 24, 94 04:06:58 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: 761 >--------- Text sent by Ross Callon follows: > > > > > Is everybody aware that somebody just submitted a paper to the ATM > Forum saying that a new bulk transport protocol is needed for ATM, > since TCP and XTP are known to be no good? I didn't read the paper > in detail, but I diagreed strongly with what I did read. I can't > cc it because ATM Forum papers are limited to Forum members. > > I noticed that it had been submitted, but was too busy last week to > look at it. Do you have the contribution number? (I have a complete > stack of the contributions to last week's ATM forum in hardcopy, I > deleted the on-line copies). > Sorry, deleted mine too. There is an ftp archive somewhere. The origin was in Canada (the Post Office?) Brian From brian@dxcoms.cern.ch Tue Jan 25 16:28:53 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA05160 for ; Tue, 25 Jan 1994 10:27:21 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22805; Tue, 25 Jan 1994 16:28:53 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29156; Tue, 25 Jan 1994 16:28:53 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401251528.AA29156@dxcoms.cern.ch> Subject: Re: PhV as a Transition To: ipng@cmf.nrl.navy.mil Date: Tue, 25 Jan 1994 16:28:53 +0100 (MET) In-Reply-To: <199401251152.GAA03560@picard.cmf.nrl.navy.mil> from "John Curran" at Jan 25, 94 02:57:14 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: 2654 >--------- Text sent by John Curran follows: > > -------- > ] From: bound@zk3.dec.com > ] Subject: PhV as a Transition > ] Date: Mon, 24 Jan 94 22:31:15 -0500 > ] > ] Can I now ask after about 40 man hours working with our transition gurus > ] that any comments stating PhV transition did not work that we please say > ] where and what were the technical problems in detail. Stating that it > ] does not work or that someone stated it broke will not help me answer > ] the questions. > > The major deployment hurdle for PhaseV was the requirement to bring up > _new_ software (in this case, Phase V routing) in an existing production > environment (Phase IV) where both PhaseV and PhaseIV directly interacted > with one another. > In the European HEP DECnet transition we ran Phase V routing on separate routers and separate circuits for a looong time, until we were confident. Then we migrated our backbone routes and routers, over a few very intense days. Then we started migrating on-site routing for the sites that wanted to do it. When it becomes the right time, we will migrate hosts, but this comes last. > The result of PhaseIV/PhaseV interaction was an extremely high level of > coordination required for successful deployment, Yes! > and elimination of the > ability to safely experiment with the new protocol. No, not if you are prepared to dedicate some routers and circuits to experimentation. > My basis for this > statement is discussion with the existing NEARNET base which would rather > undergo a controlled transition to a totally independent protocol (IPv4) > than have to debug interactions between interrelated network protocols. > The fact that IPv4 does not interfere or even try to "help them" by > interoperating with their PhaseIV base is a big plus in this scenario. > We have not seen this in Euro HEP DECnet. (But we have seen a massive move into IP, mainly triggered by Unix growth.) > Sorry, but this has to be said... anyone who causes two different systems > to interact increases the level of knowledge required to perform problem > analysis by a factor of two. I think this is the basis of my anti-translation bias. But (crash helmet on) the DECnet inter-phase routing translation does not depend on a magic C-bit in the address. > Having two two _distinct_ systems allows > problems to be handle by people with non-overlapping skill bases. Personally, > in an age where the complexity of systems is going up dramatically, I cannot > conceive of intentionally causing additional complexities and failure modes > by having network protocols directly interact with one another. > > /John > Brian From jcurran@nic.near.net Tue Jan 25 11:08:32 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA05582 for ; Tue, 25 Jan 1994 11:07:00 -0500 Message-Id: <199401251607.LAA05582@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa11258; 25 Jan 94 11:08 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: PhV as a Transition In-reply-to: Your message of Tue, 25 Jan 1994 16:28:53 +0100. <9401251528.AA29156@dxcoms.cern.ch> Date: Tue, 25 Jan 1994 11:08:32 -0500 From: John Curran -------- ] From: Brian Carpenter CERN-CN ] Subject: Re: PhV as a Transition ] Date: Tue, 25 Jan 1994 16:28:53 +0100 (MET) ] ... ] > The result of PhaseIV/PhaseV interaction was an extremely high level of ] > coordination required for successful deployment, ] ] Yes! ] ] > and elimination of the ] > ability to safely experiment with the new protocol. ] ] No, not if you are prepared to dedicate some routers and circuits ] to experimentation. Ah... I agree. (Some deployment problems can be resolved through the application of sufficient funds.) Mind you, I'm not certain that the average 4 node corporate LAN is going to be happy about establishing a "Transition testing center" so that they can safely migrate. /John From brian@dxcoms.cern.ch Tue Jan 25 17:52:45 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA06116 for ; Tue, 25 Jan 1994 11:51:28 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12139; Tue, 25 Jan 1994 17:52:47 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03907; Tue, 25 Jan 1994 17:52:46 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401251652.AA03907@dxcoms.cern.ch> Subject: EWOS To: ipng@cmf.nrl.navy.mil, vcerf@cnri.reston.va.us (Vint Cerf) Date: Tue, 25 Jan 1994 17:52: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: 667 IPng Directorate, and Vint, Following the FIRP discussion in the last IPng telechat, I took the initiative of contacting the chair of the EWOS steering committee. [EWOS = European Workshop on Open Systems, which has European Union support.] He is Paul Van Binst who happens to be an ex-physicist. It turns out he will be at CERN this Thursday for another meeting, so I will have a short discussion with him. Unless anybody tells me to stop, I will suggest to him that a recognition by EWOS of the value of the Internet suite as an open protocol suite would be in everybody's interests and would take some of the political aspects out of the IPng process. Brian From deering@parc.xerox.com Tue Jan 25 09:35:46 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA06695 for ; Tue, 25 Jan 1994 12:34:46 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14977(6)>; Tue, 25 Jan 1994 09:36:13 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 25 Jan 1994 09:36:01 -0800 To: Robert_Ullmann.LOTUS@crd.lotus.com Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: Brian's paper/Translation In-reply-to: Robert_Ullmann.LOTUS's message of Mon, 24 Jan 94 20:13:16 -0800. <9401250413.AA09609@Mail.Lotus.com> Date: Tue, 25 Jan 1994 09:35:46 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan25.093601pst.12171@skylark.parc.xerox.com> > No proposal is going to magically invest IPv4 with a larger > address space. It may hand wave and obfuscate, but it won't > actually be able to do it. The IPv4 systems will only ever be > able to operate with a subset of the global network that is > approximately the same size and dimensionality as the > IPv4 space itself. Anything else is snake oil. That's precious: Robert "we-don't-need-no-steenkin'-transition-plan" Ullman accusing someone *else* of being a snake oil salesman! Just for the record: the IPAE folks have never claimed any of the magical powers that are implied by the above passage. We've always said that IPAE will allow a SIP[P] system to communicate with an IPv4 system anywhere in the Internet *until* the IPv4 address space effectively runs out. After that, a SIP[P] system will be able to communicate indefinitely with IPv4 systems within a sub-region of the Internet in which IPv4 addresses can still be guaranteed unique. If you can produce evidence that any of the IPAE developers have ever claimed otherwise, please produce it; otherwise, please curb your insults. Steve From jcurran@nic.near.net Wed Jan 26 01:40:09 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA12059 for ; Wed, 26 Jan 1994 01:38:41 -0500 Message-Id: <199401260638.BAA12059@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa20523; 26 Jan 94 1:40 EST To: Steve Deering cc: Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Tue, 25 Jan 1994 09:35:46 -0800. <94Jan25.093601pst.12171@skylark.parc.xerox.com> Date: Wed, 26 Jan 1994 01:40:09 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Brian's paper/Translation ] Date: Tue, 25 Jan 1994 09:35:46 PST ] ... ] Just for the record: the IPAE folks have never claimed any of the magical ] powers that are implied by the above passage. We've always said that IPAE ] will allow a SIP[P] system to communicate with an IPv4 system anywhere in ] the Internet *until* the IPv4 address space effectively runs out. ] ] After that, a SIP[P] system will be able to communicate indefinitely with ] IPv4 systems within a sub-region of the Internet in which IPv4 addresses can ] still be guaranteed unique. If you can produce evidence that any of the ] IPAE developers have ever claimed otherwise, please produce it; otherwise, ] please curb your insults. Aside from tone, I pretty much agree with Steve D. on this... I don't know any IPAE developers who have misrepresented IPAE. A few may have gotten "caught up in spirit" of IPAE, and overstated its potential for usefulness, but that's generally been the result of different base assumptions rather than anything intentional. I would like to raise a very delicate subject with the IPng directorate regarding our current IPng proposals. Several of my basic assumptions regarding IPng requirements have changed over the past 18 months, and I suspect that the same has occured for other directorate members. I'd like to briefly discuss the underlying assumptions that we're all using for IPng development, on the presumption that some of us now have different IPng assumptions than when we started, and we would (I postulate) design a rather different IPng solution if we were to start over today. Here's some of my recently acquired wisdom: 1. Hierarchical prefix-based routing with aggregation (as recommended in CIDR, SIPP, and TUBA) has the potential for routing scaling if adaquate backpressure mechanisms exist. As a result of CIDR, IPng does not have to "solve" the routing scaling problem for IPv4. 2. IPng has only one absolute requirement: Dramatically increase the address space of IP without sacrificing existing IPv4 functionality. In particular, IPng must include multicasting capabilities just as IPv4. 3. IPng systems deployed during the period of time when IPv4 addresses are available _must_ be able to interoperate with the existing IPv4 base. Once IPv4 addresses are no longer available, it is desirable (but not required) to allow interoperability between new IPng systems and IPv4. 4. IPng must provide additional functionality in the base software to be considered by the marketplace. Autoconfiguration, flow identifiers, mobility and provider selection are _some_ desirable features for IPng base software. 5. IPng performance should be comparable IPv4 performance. 6. The IETF must control the future evolution of IPng. Does anyone have any serious concerns about these generalizations? I don't believe that they're particularly contentious, but some of the implications are rather interesting: o CLNP, "out of the box", _must_ be modified to meet IPng requirements. (At a minimum, it needs multicasting and IPv4 interoperability specs.) Additionally, IPng could be _based upon_ CLNP, it cannot not _be_ CLNP until IETF change control is assured. o The network address length issue which was debated at length at the beginning of the IPng development has turned into a non-issue; SIPP has 64, 128, 192, etc. bit lengths, whereas CLNP has 160, 168, etc. bit lengths. Presumably, the additional bits (when needed) do not represent an unreasonable performance burden. Likewise, the cost of variable length addressing is not actually a performance burden. o IPAE was designed originally as a method for improving route scaling and providing IPng-IPv4 interoperability within IPv4 commonwealths. Given that hierarchical prefix-based aggregation resolves the routing scaling issue, IPAE's signficant difference over other transition schemes remains its ability to support multiple IPv4 uniqueness regions once IPv4 addresses are no longer globally unique. o Interoperability between IPng and IPv4 either involves dual-stacks on the the IPng systems or requires some form of translation. The translation can occur in the IPng systems (i.e. "Internet Protocol address extensions") or can be done via a seperate translation unit which performs the function. o Some common technologies (such as an active "ES-IS"-like protocol for end system interaction, and an SPF protocol for intra-AS routing) were adopted by both TUBA and SIPP as the right way to handle particular problem spaces. Given the above observations, I cannot help but think that there is much more common ground between the various proposals than previously believed. If the goal of the IETF is to produce the _best_ internetworking standards possible, we may be doing a disservice by accepting any of the IPng proposals before us. /John From jcurran@nic.near.net Wed Jan 26 03:52:22 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA12460 for ; Wed, 26 Jan 1994 03:50:41 -0500 Message-Id: <199401260850.DAA12460@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa01578; 26 Jan 94 3:52 EST To: Paul Francis cc: deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Wed, 26 Jan 1994 16:08:53 +0200. <9401260708.AA09457@cactus.ntt.jp> Date: Wed, 26 Jan 1994 03:52:22 -0500 From: John Curran -------- ] From: Paul Francis ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Wed, 26 Jan 94 16:08:53 JST ] ... ] I think the goal of the IETF is to produce the best internetworking standards ] possible in a very short time frame--in other words, the goal is *not* to ] produce the best internetworking standards possible, but to produce a good ] one, and soon. ] ... ] Whatever IPng is chosen, it is going to evolve, probably a lot at first ] as it gets nailed down and built, and perhaps less fast over time. ] Therefore, we should make our decision now, based on fairly high-level ] criteria (design, architecture, functionality, standards process, etc.), ] and sweat the details in the usual way (by building it.....) Do you feel that we can make a decision between the proposals based on high-level criteria?? At a high level, all of the proposals look viable to me, and yet the problems are present. If the goal of deciding is to close down work on the other IPng proposals, then I'm dead against it until we're all confortable that the chosen IPng will actually work. I believe that we need to move quickly on IPng. I do not think we can just "make a decision" until we've gotten feedback from limited deployment, as I have serious doubts about the ability to deploy the current proposals. Dual-stack deployment _cannot_ work in some circumstances (once IPv4 addresses are not readily available, sites will be unable to deploy new systems which can communicate with important IPv4 legacy systems, due to lack of a IPv4 address). Thanks to the directorate for reminding me about glacial equipment replacement schedules. IPAE's mapping tables are simply inconceivable from an operational viewpoint and the odds of all border routers being correctly configured in the 100 or so world-wide providers is nil. The described mechanism for table distribution (ftp) does not meet the needs of Internet operation, and folks familiar with the current failure of keeping the 7 root DNS servers in sync via FTP would not advocate attempting to keep several hundred router under different authorities up to date with this mechanism. The addition of new sites to the Internet will require a level of coordination which simply cannot be obtained. When there are problems, the problem determination process for SIP/IPAE/IPv4 is so complicated that I do not expect most IETF members to diagnose their own difficulties. (The IETF terminal room should become quite entertaining.) If this group needs to make a quick decision, let it be NAT. /John p.s. I'm actually quite pleased with the IPng working group output, and as my last message indicates, I feel that a great deal of consensus was actually reached without anyone noticing. (so much consensus, that it may be possible to define an IPng proposal which looks like SIP, has variable CLNPish addressing made up of little 16-bit elements with PIP-like processing, and local IPAE-like IPv4->IPng translation for new IPng-only hosts communicating with local legacy IPv4 systems; IPng/IPv4 dual for those IPng hosts that speak IPv4 to the IPv4 Internet.) From vcerf@CNRI.Reston.VA.US Wed Jan 26 05:31:16 1994 Return-Path: vcerf@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 FAA12745 for ; Wed, 26 Jan 1994 05:31:45 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01806; 26 Jan 94 5:31 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: EWOS In-reply-to: Your message of "Tue, 25 Jan 94 17:52:45 +0100." <9401251652.AA03907@dxcoms.cern.ch> Date: Wed, 26 Jan 94 05:31:16 -0500 From: "Vinton G. Cerf" Message-ID: <9401260531.aa01806@IETF.CNRI.Reston.VA.US> Brian, it would certainly be helpful if EWOS were to take the view that a broader range of options would be practical for many network users. I haven't followed closely the scope of EWOS efforts in the recent past although its counterpart here in the US (OIW) has recently seemed to re-examine its charter with an eye to expanding on the meaning of "Open Systems." If the EWOS community is still largely focused on getting the OSI protocol suite whipped into shape, you may find it a difficult matter to broaden their charter, but I am sure all of us will be interested to learn how your discussion goes. vint From francis@cactus.ntt.jp Wed Jan 26 16:08:53 1994 Return-Path: francis@cactus.ntt.jp Received: from koudai.cs.titech.ac.jp (koudai.cs.titech.ac.jp [131.112.176.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with ESMTP id CAA12241 for ; Wed, 26 Jan 1994 02:28:21 -0500 Received: by koudai.cs.titech.ac.jp (2.3W/koudai); Wed, 26 Jan 1994 16:29:33 +0900 Received: by lab.ntt.jp (8.6.4/GATENTTMX0.91); Wed, 26 Jan 1994 16:06:23 +0900 Received: from cactus.ntt.jp by ntt-twins.ntt.jp (8.5/NTTcs02b) id QAA13237; Wed, 26 Jan 1994 16:06:21 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Wed, 26 Jan 94 16:08:53 JST Date: Wed, 26 Jan 94 16:08:53 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9401260708.AA09457@cactus.ntt.jp> To: deering@parc.xerox.com, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil I could hardly agree more with John's statements.... (Hmmmm, I wonder if that question will be hard to parse by my Japanese colleagues.....) > If the goal of the IETF is to produce the _best_ internetworking standards > possible, we may be doing a disservice by accepting any of the IPng proposals > before us. I think the goal of the IETF is to produce the best internetworking standards possible in a very short time frame--in other words, the goal is *not* to produce the best internetworking standards possible, but to produce a good one, and soon. Also, I meant to reply to Brian Carpenter's summary of the IPng portion of the RIPE meeting. At the end, he said the points were "slim pickings", but I thought that an incredibly important point was made. That is, that the IETF has all the information it needs to make a decision *now* (or, put another way, waiting 6 months or 1 year or 2 years isn't going to give them/us qualitatively more information with which to make a decision). Whatever IPng is chosen, it is going to evolve, probably a lot at first as it gets nailed down and built, and perhaps less fast over time. Therefore, we should make our decision now, based on fairly high-level criteria (design, architecture, functionality, standards process, etc.), and sweat the details in the usual way (by building it.....) (I also found the last two items Brian listed as ironic. They were, to the best of my memory, that decent policy routing is very important, and that simplicity is key.....we all would like to have our tofu and eat it too.....) Cheers, PF From brian@dxcoms.cern.ch Wed Jan 26 16:51:37 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA14559 for ; Wed, 26 Jan 1994 10:49:59 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03058; Wed, 26 Jan 1994 16:51:38 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09114; Wed, 26 Jan 1994 16:51:37 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401261551.AA09114@dxcoms.cern.ch> Subject: Some IPng input To: ipng@cmf.nrl.navy.mil Date: Wed, 26 Jan 1994 16:51:37 +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: 2184 I solicited IPng input from the European HEPnet committees but so far I have had no collective response. I did receive the attached personal comment from the chair of the HEPnet Requirements Committee. He makes a specific request for more fine-grained support for policy routing and another for better multicast support. [He actually says there is no multicast support today: not strictly true of course, but not far from the truth as a user perception of the MBONE.] Brian >--------- Text sent by J. F. RENARDY follows: > From renardy@dphvx2.saclay.cea.fr Fri Jan 7 17:47:40 1994 > X-Delivered: at request of brian on dxcoms.cern.ch > X-Rerouted-To: Brian@dxcoms.cern.ch by the CERN Automatic Mail Router (v.2.0, July 1993). > X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; > Relayed; 07 Jan 94 17:47:21+0100 > X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; > Relayed; 07 Jan 94 17:47:13+0100 > Date: 07 Jan 94 17:47:13+0100 > From: J. F. RENARDY > Message-Id: <9401071647.AA09716@hep.saclay.cea.fr> > To: @hx > Cc: RENARDY@dphdsi.saclay.cea.fr > Subject: IPng suggestion > > IETF IP: next generation area > > > (This is a personal view of the > question and not an official > position of the HRC) > > > The proposals for the next generation > of IP mostly concern features where > HEP is not seriously disturbed by the > current state (i.e. address space, > support for mobile users, security...) > > I see two areas where HEP may have > specific requests: > 1- Support for group policy. > In the current internet, each autonomous > system has its own policy, but only one. > HEP sites are usualy subset of autonomous > systems, so it is impossible to define > an "HEPnet policy". A new version of IP > with support for specific policy at a > level below the current autonomous system > will be usefull for HEP. > 2- Support for work group. > The current IP has no support for > multicast. An efficient multicast suuport > will allow HEP to implement distributed > video-conferences, to perform efficiently > distributed software development, to > access centralized data bases... > > J.F.R. > > From ericf@atc.boeing.com Wed Jan 26 08:52:48 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA15061 for ; Wed, 26 Jan 1994 11:50:03 -0500 Received: by atc.boeing.com (5.57) id AA15307; Wed, 26 Jan 94 08:52:48 -0800 Date: Wed, 26 Jan 94 08:52:48 -0800 From: Eric Fleischman Message-Id: <9401261652.AA15307@atc.boeing.com> To: francis@cactus.ntt.jp, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: Robert_Ullmann.LOTUS@crd.lotus.com, deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Dear Group, I appreciate the dialog between Paul and Dave. I like the theme of proposing a master solution not in the current solution set. However, I doubt its practicality unless a merger (e.g., like IPAE + SIP and then like PIP and SIP) occurs. Yet is this necessarily wise? John's last comment about being sure that the identified solution must work is the key point I wish to highlight. John's concluding statement that the best solution of all would probably be NAT is almost right: in my perspective the best solution of all would be application layer gateways at the security island coupled with local addressing. Of course, neither of these options could stand should our computing algorithm (toasternet) radically shift as predicted by Dave Crocker. For example, if one assumes ubiquitous personal data/ voice devices like Dick Tracy's wrist-watch (except with computer like functions as well) then we would perhaps have several tens of millions of new mobile devices whose addressing really doesn't have the concept of a "network number" imbedded within it (i.e., what network number would these use since each would be unique to that person with no obvious hierarchical element joining them all). Thus, what I'm saying is that my proposed "ideal" solution (above) is too myopic to be viable long-term. Thus, I've now come full circle. I therefore propose that until we have bona fide requirements we can not decide on an IPng and we can not identify the solution. Our requirements identification is occurring far too late in the process. I propose that the IPng Directorate expeditiously propose recommended requirements during February and then have the Requirements WG tune and modify them at the Seattle IETF. The WG results then would be evaluated by the IPng Directorate in April and potentially messaged. The result will then be decreed to be the IPng requirements. In any case, we can not afford to proceed without requirements and we need them now. Sincerely yours, --Eric Fleischman From dino@cisco.com Wed Jan 26 09:50:50 1994 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 NAA00329 for ; Wed, 26 Jan 1994 13:59:31 -0500 Received: by regal.cisco.com id AA15343 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Wed, 26 Jan 1994 09:50:50 -0800 Date: Wed, 26 Jan 1994 09:50:50 -0800 From: Dino Farinacci Message-Id: <199401261750.AA15343@regal.cisco.com> To: jcurran@nic.near.net Cc: francis@cactus.ntt.jp, deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil In-Reply-To: John Curran's message of Wed, 26 Jan 1994 03:52:22 -0500 <199401260850.DAA12460@picard.cmf.nrl.navy.mil> Subject: Proposal history (was: Re: Brian's paper/Translation) >> p.s. I'm actually quite pleased with the IPng working group output, >> and as my last message indicates, I feel that a great deal >> of consensus was actually reached without anyone noticing. >> (so much consensus, that it may be possible to define an IPng >> proposal which looks like SIP, has variable CLNPish addressing >> made up of little 16-bit elements with PIP-like processing, and >> local IPAE-like IPv4->IPng translation for new IPng-only hosts >> communicating with local legacy IPv4 systems; IPng/IPv4 dual >> for those IPng hosts that speak IPv4 to the IPv4 Internet.) This sounds vaguely familiar to how ISO defined the network layer, trying to make all camps happy. This will definitely lead to major interoperability problems. We need to define a single protocol/architecture that has the above features, and is required day-1 to implement all the features, there are no optional options. SIPP is taking this stance with respect to Routing Header. I think this is a very important mandate. Dino From bound@zk3.dec.com Wed Jan 26 13:52:31 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA00480 for ; Wed, 26 Jan 1994 14:13:15 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA03262; Wed, 26 Jan 94 10:52:38 -0800 Received: by xirtlu.zk3.dec.com; id AA12710; Wed, 26 Jan 1994 13:52:37 -0500 Message-Id: <9401261852.AA12710@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Response to John C. and Eric F. mail on Ipng Date: Wed, 26 Jan 94 13:52:31 -0500 X-Mts: smtp I completely agree with John's assesment and we really have much consensus in the consciousness of our group. I also agree with Eric that we need to move into the requirements now. I would like to ask the Directorate two things: 1. When we make a decision or recommend a master solution with detailed plans, then we need to be very careful that time is given to complete all the needed specs. And make it clear to the market IPng has been selected but not ready to be deployed per the IETF. Comments welcome ... 2. I think we need to make IPng better than IPv4 datagram regarding functionality. We need to have new pieces as John pointed out. thanks /jim From jcurran@nic.near.net Wed Jan 26 13:55:32 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA00276 for ; Wed, 26 Jan 1994 13:54:31 -0500 Message-Id: <199401261854.NAA00276@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa27865; 26 Jan 94 13:56 EST To: Dino Farinacci cc: francis@cactus.ntt.jp, deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Wed, 26 Jan 1994 09:50:50 -0800. <199401261750.AA15343@regal.cisco.com> Date: Wed, 26 Jan 1994 13:55:32 -0500 From: John Curran -------- ] From: Dino Farinacci ] Subject: Proposal history (was: Re: Brian's paper/Translation) ] Date: Wed, 26 Jan 1994 09:50:50 -0800 ] ] This sounds vaguely familiar to how ISO defined the network layer, trying ] to make all camps happy. This will definitely lead to major ] interoperability problems. ] ] We need to define a single protocol/architecture that has the above ] features, and is required day-1 to implement all the features, there ] are no optional options. SIPP is taking this stance with respect to ] Routing Header. I think this is a very important mandate. Hold on... I'm not advocating multiple methods for accomplishing the same goal (i.e. the CONS/CLNP problem); I also believe we need a _single_ architecture to satisfy IPng requirements. I just don't happen to believe that any of the proposals on the table are going to satisfy the requirements until such time as the working groups express a willingness to do the best protocol possible, regardless of previous political or personal investments. SIPP's approach to the straightening out the routing header is a great idea; it might be better if we actually designed for the future without IPv4 header legacy. SIP started as close to IPv4 as possible (quite a reasonable starting point) but now that variable length addresses have actually become accepted, simply retrofitting them into SIP via a routing option may not yield the same results as if the WG had used variable length addressing as an initial condition. Forwarding across SIP extended address spaces requires a circular rewrite to get the next address element into the header, and this is not going to pipeline easily in anyone's hardware. TUBA has also gone through some learning experiences, and several of the early decisions were based entirely on the assumption that CLNP could not/ should not be changed to make TUBA a success. At this point, it's recognized that CLNP must be changed to add multicasting, perhaps some flows, etc. TUBA could easily become a more capable proposal, complete with IPv4 address mapping, if one were to revisit the past decisions in the current light. Dino, I'm not advocating merger-mania... I'm calling for reconsideration of the current assumptions behind the proposals. We're going to have to live with IPng output for a century or more; I have no qualms about asking for technical review of the decisions made. This is particularly true when the the proposals have basic transition and/or operational flaws. Again: the proposals on the table have each solved pieces of the problem, and if there is not a willingness on the working groups to test basic assumptions and potentially learn from the other work, we might as well disband now. Paul Francis indicated that we should decide on a proposal, and then refine as needed. I ask that the directorate members put aside their differences and go through the exercise of constructively improving each others work _before_ we do anything as rash as selecting one particular approach to the problem. John "All I have to do is support this fine technology for a living" Curran From smb@research.att.com Wed Jan 26 14:23:38 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA00578 for ; Wed, 26 Jan 1994 14:23:10 -0500 From: smb@research.att.com Message-Id: <199401261923.OAA00578@picard.cmf.nrl.navy.mil> Received: by gryphon; Wed Jan 26 14:23:39 EST 1994 To: ipng@cmf.nrl.navy.mil Subject: Path MTU Date: Wed, 26 Jan 94 14:23:38 EST A number of recent messages have indicated that support for Path MTU is necessary. At the risk of sounding like a heretic, I'm not even convinced that it's a good idea, let alone necessary. The problem with Path MTU is that the current Internet relies on routers that are store-and-forward on a per-packet basis. Given the number of hops a packet typically makes on a long-haul net, and given the comparatively small window sizes, there's a significant amount of starvation due to TCP window size exhaustion. With smaller packets, each router has less waiting time before it can resend the packet; the net effect is that each link can be kept busy, and some data will arrive promptly. To make things quantitative, at DS1 speeds a 1500 byte packet takes about 7.7 milliseconds to be received. If the receiving host uses 8K byte windows, which are hardly atypical, only 5 and a fraction packets can be outstanding at any one time. Each router will take those 7.7 ms to send each packet; if there are more than 6 hops, the sending host will be idle till 7.7ms times the number of hops goes by, and the ack comes back the same number of hops. If smaller packets were used, the 7.7ms multiplier will be much reduced. Based on my comments, Rich Stevens wrote up a much clearer explanation of this phenomenon in his new book ``TCP/IP Illustrated''. Now -- bulk transfer protocols might use great gronking huge windows, and really be able to take advantage of every small increment in throughput from fewer instances of per-packet overhead. But a lot of the other traffic -- mail, ftp, etc. -- is in messages too short for that to matter much. I've done a few tests, btw, that seemed to demonstrate this effect in practice, not theory. The tests involved ttcp over a frame relay link running at DS1 speeds. Cutting the MTU increased througput. (On the other hand, Jeff Mogul thinks I was seeing an artifact of the ACK scheduling in SunOS. One of these days, I'll find or build a TCP simulator.) --Steve Bellovin From dino@cisco.com Wed Jan 26 11:26:19 1994 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 OAA00591 for ; Wed, 26 Jan 1994 14:24:43 -0500 Received: by regal.cisco.com id AA27458 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Wed, 26 Jan 1994 11:26:19 -0800 Date: Wed, 26 Jan 1994 11:26:19 -0800 From: Dino Farinacci Message-Id: <199401261926.AA27458@regal.cisco.com> To: jcurran@nic.near.net Cc: francis@cactus.ntt.jp, deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil In-Reply-To: John Curran's message of Wed, 26 Jan 1994 13:55:32 -0500 <199401261856.AA28024@hubbub.cisco.com> Subject: Proposal history (was: Re: Brian's paper/Translation) >> SIPP's approach to the straightening out the routing header is a great idea; >> it might be better if we actually designed for the future without IPv4 header >> legacy. SIP started as close to IPv4 as possible (quite a reasonable starting >> point) but now that variable length addresses have actually become accepted, >> simply retrofitting them into SIP via a routing option may not yield the same >> results as if the WG had used variable length addressing as an initial >> condition. Forwarding across SIP extended address spaces requires a circular >> rewrite to get the next address element into the header, and this is not going >> to pipeline easily in anyone's hardware. I don't believe variable length addresses have actually become accepted. Yes, the Routing Header is a great idea, however I was commenting on the mandatory implementation of it. We don't want to fall into the IPv4 trap, that everyone can do option processing at an order of magnitude slower than a packet without options. >> Dino, I'm not advocating merger-mania... I'm calling for reconsideration of >> the current assumptions behind the proposals. We're going to have to live >> with IPng output for a century or more; I have no qualms about asking for >> technical review of the decisions made. This is particularly true when the >> the proposals have basic transition and/or operational flaws. Good, I just wanted to make it clear to the list that you were not making minestrone and mixing it with my recipe for minestrone. >> Again: the proposals on the table have each solved pieces of the problem, >> and if there is not a willingness on the working groups to test basic >> assumptions and potentially learn from the other work, we might as well >> disband now. Paul Francis indicated that we should decide on a proposal, >> and then refine as needed. I ask that the directorate members put aside >> their differences and go through the exercise of constructively improving >> each others work _before_ we do anything as rash as selecting one particular >> approach to the problem. So, do we start a new working group to build a single and final IPng proposal. The working group satisfies all requirements that this directorate puts forth and takes ideas from SIP/IPAE/PIP/TUBA/CATNIP/IPv4. >> John "All I have to do is support this fine technology for a living" Curran And so will your kids. Let's leave them something to be proud of. Soups up, Dino From rcallon@wellfleet.com Wed Jan 26 19:39:49 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA01142 for ; Wed, 26 Jan 1994 19:33:19 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03499; Wed, 26 Jan 94 19:20:26 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA14902; Wed, 26 Jan 94 19:29:58 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA17418; Wed, 26 Jan 94 19:39:49 EST Date: Wed, 26 Jan 94 19:39:49 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401270039.AA17418@cabernet.wellfleet> To: jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: ipng@cmf.nrl.navy.mil .... If the goal of deciding is to close down work on the other IPng proposals, then I'm dead against it until we're all comfortable that the chosen IPng will actually work. I agree with this. I can't imagine that any other result will come out of the selection of one particular IPng, except possibly for the roasting at the stake of the selecters :-(. I doubt that the selection of one proposal will make folks more willing to fix that proposal. I believe that we need to move quickly on IPng. I do not think we can just "make a decision" until we've gotten feedback from limited deployment, as I have serious doubts about the ability to deploy the current proposals. I think that it is possible to learn a lot about the deployability of proposals by looking at the specifications, if only there were complete specifications (for *any* of the proposals). However a substantial deployment will also be necessary. Dual-stack deployment _cannot_ work in some circumstances (once IPv4 addresses are not readily available, sites will be unable to deploy new systems which can communicate with important IPv4 legacy systems, due to lack of a IPv4 address). Thanks to the directorate for reminding me about glacial equipment replacement schedules. This seems to imply a misunderstanding of Dual Stack. One of the main points of Dual Stack is that the development of the two network layers continues, pretty much independently (with the understanding that there may be use of encapsulation in some cases). Thus IP will continue to be used and deployed. My expectation is that when there are too many systems for IP addresses to be globally unique, then folks will continue to use and deploy IP systems, but the bulk of the systems will have local IP addresses (only a few systems will have globally unique IP addresses -- I think that it is more believable that some global IP connectivity will continue to be useful for a long while for some systems, rather than that *all* IP use will become local). This implies that after IP ceases to have globally-sufficient addresses, new sytems, in most cases, will have globally unique IPng addresses, and local IPv4 addresses. This implies that such new systems will talk globally with all IPng systems, and talk locally with local IPv4 systems. A few systems will be able to have globally significant IPv4 and IPng addresses. I don't think that this is much different from the case with IPAE. I think that the difference between dual stack and IPAE is more in the dual- stack requirement that the system support multiple network layer packet formats, including host to router protocols (ARP, ICMP, ES-IS), as well as end to end data packet formats (IP, IPng). I will try to (i) find time to work on the dual stack paper, and (ii) make sure that this is explained clearly in it. IPAE's mapping tables are simply inconceivable from an operational viewpoint and the odds of all border routers being correctly configured in the 100 or so world-wide providers is nil. The described mechanism for table distribution (ftp) does not meet the needs of Internet operation, and folks familiar with the current failure of keeping the 7 root DNS servers in sync via FTP would not advocate attempting to keep several hundred routers under different authorities up to date with this mechanism. The addition of new sites to the Internet will require a level of coordination which simply cannot be obtained. When there are problems, the problem determination process for SIP/IPAE/IPv4 is so complicated that I do not expect most IETF members to diagnose their own difficulties. (The IETF terminal room should become quite entertaining.) Absolutely. I have heard rumors that these tables are being removed from IPAE, but have no idea what they might be replaced with. If this group needs to make a quick decision, let it be NAT. Ugh. Working out how NAT should work may be a good idea (if it is going to happen, then we might as well have some idea *how* it will happen). Ross From rcallon@wellfleet.com Wed Jan 26 19:53:03 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA01185 for ; Wed, 26 Jan 1994 19:46:32 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03552; Wed, 26 Jan 94 19:33:40 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA15016; Wed, 26 Jan 94 19:43:12 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA17428; Wed, 26 Jan 94 19:53:03 EST Date: Wed, 26 Jan 94 19:53:03 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401270053.AA17428@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ...TUBA has also gone through some learning experiences, and several of the early decisions were based entirely on the assumption that CLNP could not/ should not be changed to make TUBA a success. Strangely, if I had realized that folks were going to be so resistant to updating CLNP, I would not have proposed using CLNP in the original TUBA RFC. My reason for choosing CLNP was that I thought that it was a sound protocol which is very close to what we actually need, and we could easily update it where needed to make it into a technically excellent protocol. Thus, I never thought that the fact that it already existed was particularly important. However, I soon discovered both (i) my previous company didn't want me to work on it; and (ii) the working group was resistant to changing it, even in compatible ways (ie, in ways that were compatible with existing equipment). ... At this point, it's recognized that CLNP must be changed to add multicasting, perhaps some flows, etc. TUBA could easily become a more capable proposal, complete with IPv4 address mapping, if one were to revisit the past decisions in the current light. Dino, I'm not advocating merger-mania... I'm calling for reconsideration of the current assumptions behind the proposals. We're going to have to live with IPng output for a century or more; I have no qualms about asking for technical review of the decisions made. This is particularly true when the the proposals have basic transition and/or operational flaws. I have wondered if we should throw out all existing proposals, lock about 5 or 6 of the directorate in a room, and not let them out until they come out with a solution (presumeably after sending the correct colored smoke up the chimney). Perhaps we could send them in with one case of very good wine, one case of lousy wine, enough food for three weeks, and enough water for 6 months. If they couldn't agree quickly, then they might come out very thin :-). ...if there is not a willingness on the working groups to test basic assumptions and potentially learn from the other work, we might as well disband now. Strongly agree. ... Paul Francis indicated that we should decide on a proposal, and then refine as needed. But how can we agree to a proposal unless we think that it is at least marginally workable as it stands? It has been suggested that some of the directorate discussions have been a bit too negative. I am actually concerned about almost the opposite: In private numerous folks seem to be willing to admit to technical concerns that they are not willing to say to the list, possibly for fear of insulting each other. If we see serious problems with a proposal then I think that we need to be able to admit this, or we run the risk of ending up with an unworkable solution. ...I ask that the directorate members put aside their differences and go through the exercise of constructively improving each others work _before_ we do anything as rash as selecting one particular approach to the problem. Yes! Ross From jcurran@nic.near.net Wed Jan 26 23:41:41 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA04506 for ; Fri, 28 Jan 1994 23:07:45 -0500 Message-Id: <199401290407.XAA04506@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id ab13416; 26 Jan 94 23:41 EST To: Ross Callon cc: ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Wed, 26 Jan 1994 19:39:49 -0500. <9401270039.AA17418@cabernet.wellfleet> Date: Wed, 26 Jan 1994 23:41:41 -0500 From: John Curran -------- ] From: Ross Callon ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Wed, 26 Jan 94 19:39:49 EST ] ... ] My expectation is that when there are too many systems for IP addresses ] to be globally unique, then folks will continue to use and deploy IP ] systems, but the bulk of the systems will have local IP addresses (only ] a few systems will have globally unique IP addresses -- I think that it ] is more believable that some global IP connectivity will continue to be ] useful for a long while for some systems, rather than that *all* IP use ] will become local). ] ] This implies that after IP ceases to have globally-sufficient addresses, ] new sytems, in most cases, will have globally unique IPng addresses, and ] local IPv4 addresses. This implies that such new systems will talk globally ] with all IPng systems, and talk locally with local IPv4 systems. A few ] systems will be able to have globally significant IPv4 and IPng addresses. One sites' "local IPv4 address" is another sites "globally-unique" address?? In the absence of clear guidance from the transition documentation, this is clearly the case. In 2003, the system administrator for foo.com unpacks 2 new computer systems. Host A is assigned the last address in foo.com's address range. The admin calls and says: "I need one more, what should I do?" I tell him: "You should start using LOCALLY-unique IP addresses." He then assigns his new system the address "192.32.180.26" (picked totally out of thin air) and begins telling his 1000 hosts abut this new address space for routing purposes. Such fun. Meanwhile, down the hall in foo.com, someone starts swearing at the network. His communication with Ross Callon (the "true owner" of 192.32.180.26) has suddenly stopped. Ross, working at ABC Corp., suddenly finds that he can no longer talk to anyone at FOO, due to their address selection. The entire thing takes about 2 weeks realtime to resolve, and the estimate for lost time for all involved comes to slightly under $35K. Ross, when you write the dual-stack paper, would you specify where these local addresses come from? If there is going to be a reserved address space for this purpose, we need to document such interesting topics as how sites handle DNS for the local address space and the use of overlapping IPv4 netowrks on the local network. Perhaps dual-stack is viable, under the right administrative circumstances. We need documentation on this as soon as possible. If you're advocating something other than a reserved set of networks for this purpose (i.e. IPv4 uniqueness within scopes shared between sites) then how we get from one unique space to _one space with multiple uniqueness scopes_ needs to be described. Needless to say, the same type of information is desperately needed in order to evaluate transition ala IPAE. Scott Bradner: How would Harvard (hypothetically) adapt to the situation of having to add new systems on a local-use-only IPv4 net? Would "local" mean "local for Harvard" or "local for Harvard and affiliates"? Would it be a matter of weeks or years before you had to go buy a translator box with dynamic addr mapping to a small number of valid IPv4 addresses for global communication? Should NEARNET attempt to coordinate use of "locally-assigned" address space so that functionality is maintained for folks on such addresses within most of NE? Anyone else who is involved in local area network service care to comment on the above issues? This is real; think about how having local-use only systems would impact your organization. I would normally apologize for taking everyone's time, but I'm afraid that the time for open, content-full dialogue is upon us. Ross, I appreciate your notes on dual-stack transition: now I can conceive of using dual-stack as a transition mechanism, and would just like to see the details on these local address assignments on paper. Steve Deering: Ross indicated that the IPAE mapping tables may be replaced by something else. (This shouldn't be too surprising, given that they contain what is effectively routing information.) Can you supply any details as to what the replacement will be? It would also be useful to know how the actual transition from one uniqueness scope to multiple will be administratively handled; is there a forthcoming document on this? /John p.s. Paul Francis: It took over 18 months of planning and dialogue to get CIDR/BGP4 to the point where we knew it was operationally viable. Until the same type of dialogue occurs for the IPng proposals, there is no way of knowing whether they, in fact, can be deployed. I don't see any particular reason to declare "The" IPng proposal until we know that it _should_ work. Do you see some other value in making a selection prior everyone having confidence in the solution? From brian@dxcoms.cern.ch Thu Jan 27 08:34:10 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA02401 for ; Thu, 27 Jan 1994 02:32:31 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08600; Thu, 27 Jan 1994 08:34:11 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18532; Thu, 27 Jan 1994 08:34:10 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401270734.AA18532@dxcoms.cern.ch> Subject: Re: Path MTU To: ipng@cmf.nrl.navy.mil Date: Thu, 27 Jan 1994 08:34:10 +0100 (MET) In-Reply-To: <199401261923.OAA00578@picard.cmf.nrl.navy.mil> from "smb@research.att.com" at Jan 26, 94 02:23:38 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: 3155 Steve, Van Jacobson has made the same point in his tutorials on long fat networks: for a given route with N routers and a given (bulk) transfer scenario there is an optimum MTU which is less than infinity and may be surprisingly small. He also points out, however, that if you can make a cut-through router (i.e. output starts as soon as the header has been read in) the parameters of the problem change by several orders of magnitude. The point is, the optimum MTU is strongly dependent on the scenario. If we are talking about a client/server scenario on a campus there may be only one router in the path and the optimum MTU will be large, maybe 4k in our experience here with FDDI. If we are talking about ftp between research.att.com and dxcoms.cern.ch the optimum MTU may be 576 bytes. So MTU discovery is only the first step; it should be followed by MTU tuning, but that is another story. There has been violent argument on this topic in the IPoverATM WG for many months. Brian >--------- Text sent by smb@research.att.com follows: > > A number of recent messages have indicated that support for Path MTU > is necessary. At the risk of sounding like a heretic, I'm not even > convinced that it's a good idea, let alone necessary. > > The problem with Path MTU is that the current Internet relies on routers > that are store-and-forward on a per-packet basis. Given the number of > hops a packet typically makes on a long-haul net, and given the comparatively > small window sizes, there's a significant amount of starvation due to > TCP window size exhaustion. With smaller packets, each router has less > waiting time before it can resend the packet; the net effect is that each > link can be kept busy, and some data will arrive promptly. > > To make things quantitative, at DS1 speeds a 1500 byte packet takes about > 7.7 milliseconds to be received. If the receiving host uses 8K byte > windows, which are hardly atypical, only 5 and a fraction packets can > be outstanding at any one time. Each router will take those 7.7 ms > to send each packet; if there are more than 6 hops, the sending host > will be idle till 7.7ms times the number of hops goes by, and the > ack comes back the same number of hops. If smaller packets were used, > the 7.7ms multiplier will be much reduced. > > Based on my comments, Rich Stevens wrote up a much clearer explanation > of this phenomenon in his new book ``TCP/IP Illustrated''. > > Now -- bulk transfer protocols might use great gronking huge windows, > and really be able to take advantage of every small increment in throughput > from fewer instances of per-packet overhead. But a lot of the other > traffic -- mail, ftp, etc. -- is in messages too short for that to matter > much. > > I've done a few tests, btw, that seemed to demonstrate this effect in > practice, not theory. The tests involved ttcp over a frame relay link > running at DS1 speeds. Cutting the MTU increased througput. (On the > other hand, Jeff Mogul thinks I was seeing an artifact of the ACK > scheduling in SunOS. One of these days, I'll find or build a TCP > simulator.) > > > --Steve Bellovin > From francis@cactus.ntt.jp Thu Jan 27 09:55:27 1994 Return-Path: francis@cactus.ntt.jp Received: from koudai.cs.titech.ac.jp ([131.112.176.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with ESMTP id UAA01260 for ; Wed, 26 Jan 1994 20:00:17 -0500 Received: by koudai.cs.titech.ac.jp (2.3W/koudai); Thu, 27 Jan 1994 10:01:31 +0900 Received: by lab.ntt.jp (8.6.4/GATENTTMX0.91); Thu, 27 Jan 1994 09:52:56 +0900 Received: from cactus.ntt.jp by ntt-twins.ntt.jp (8.5/NTTcs02b) id JAA11010; Thu, 27 Jan 1994 09:52:54 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Thu, 27 Jan 94 09:55:27 JST Date: Thu, 27 Jan 94 09:55:27 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9401270055.AA13044@cactus.ntt.jp> To: ericf@atc.boeing.com, francis@atc.boeing.com, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: Robert_Ullmann.LOTUS@crd.lotus.com, deering@parc.xerox.com, ipng@cmf.nrl.navy.mil > > I therefore propose that until we have bona fide requirements we can not > decide on an IPng and we can not identify the solution. Our requirements > identification is occurring far too late in the process. I propose that > ........ > the IPng requirements. In any case, we can not afford to proceed without > requirements and we need them now. > I've become rather cynical about efforts to define requirements. Even more so than protocols designed in committee, requirements defined in committee tend to be all-inclusive. Also, I think agreeing on requirements is about as hard as agreeing on a protocol, mainly because the path from requirement to corresponding protocol field is pretty short, so agreeing on requirements isn't much different than agreeing on protocol. Way back in Amsterdam, Frank pointed out that his and Craig's requirements doc failed for this very reason....they found that they couldn't include requirements that excluded certain protocols..... Once we pick the protocol, it is going to be hard enough to keep it clean. SIP has already suffered significant featurism (look at Steve's *original* proposal...), and it hasn't even yet been handed over to the masses in an "ownership" sense. If we choose a protocol now, there will be plenty of opportunity to fix bugs we find, and to add features if they are deemed required. PF From brian@dxcoms.cern.ch Thu Jan 27 09:02:14 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA02451 for ; Thu, 27 Jan 1994 03:00:38 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15416; Thu, 27 Jan 1994 09:02:15 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20044; Thu, 27 Jan 1994 09:02:14 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401270802.AA20044@dxcoms.cern.ch> Subject: Where next (was: Re: Proposal history...) To: ipng@cmf.nrl.navy.mil Date: Thu, 27 Jan 1994 09:02:14 +0100 (MET) In-Reply-To: <9401270055.AA13044@cactus.ntt.jp> from "Paul Francis" at Jan 27, 94 09:55:27 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: 857 All, I have to support the view that we are doing this backwards (first identifying the solutions, and then identifying the requirements). It's unreasonable to ask the WGs to stop until the requirements are agreed, but I think we should put top priority on the requirements aspect between now and Seattle. In physics we talk about Grand Unified Theory, or Theory Of Everything: the attempt to produce a master theory that implies all other theories. You don't do this by writing down all the existing equations on the same page, but by looking for simpler equations with more universality. Same for IPng: you won't get the perfect IPng by taking the logical OR of SIPP, TUBA and CATNIP. So we do have to ask the question - do we want to improve one of the existing proposals or do we want to look for the genius who can invent the perfect IPng? Brian From bound@zk3.dec.com Thu Jan 27 09:18:53 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA03491 for ; Thu, 27 Jan 1994 09:50:18 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA16072; Thu, 27 Jan 94 06:19:02 -0800 Received: by xirtlu.zk3.dec.com; id AA07208; Thu, 27 Jan 1994 09:18:59 -0500 Message-Id: <9401271418.AA07208@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Path MTU In-Reply-To: Your message of "Wed, 26 Jan 94 14:23:38 EST." <199401261923.OAA00578@picard.cmf.nrl.navy.mil> Date: Thu, 27 Jan 94 09:18:53 -0500 X-Mts: smtp Steve, Another interesting problem I am seeing now is storing per host routes and use of that memory, and then doing the garbage collection. Another interesting issue is whether to move PMTU into the transport layer which one of my colleagues feels is a good idea. Do you not think its a good idea to determine bandwith potential and then use it? PMTU can increase performance too. PC code doing frag/reassembly is costly at this time too. I am open to this technical discussion. thanks /jim From bound@zk3.dec.com Thu Jan 27 09:43:12 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03542 for ; Thu, 27 Jan 1994 10:03:21 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA17188; Thu, 27 Jan 94 06:43:22 -0800 Received: by xirtlu.zk3.dec.com; id AA08125; Thu, 27 Jan 1994 09:43:19 -0500 Message-Id: <9401271443.AA08125@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Path MTU In-Reply-To: Your message of "Thu, 27 Jan 94 08:34:10 +0100." <9401270734.AA18532@dxcoms.cern.ch> Date: Thu, 27 Jan 94 09:43:12 -0500 X-Mts: smtp Brian, One part of PMTU I am working on right now is detecting increases in PMTU across the network path. Do you think this is part of PMTU fine tuning? Also if we think PMTU discovery should be a requirement (and I do right now), a proposoal should not reduce the PMTU path because of tunneling IPng or IPv4 permanently, or the MTUs should be increases on either side of the tunnel. thanks /jim From bound@zk3.dec.com Thu Jan 27 10:00:34 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03780 for ; Thu, 27 Jan 1994 10:41:14 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA18088; Thu, 27 Jan 94 07:00:41 -0800 Received: by xirtlu.zk3.dec.com; id AA08728; Thu, 27 Jan 1994 10:00:40 -0500 Message-Id: <9401271500.AA08728@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng prototype code base and master solution Date: Thu, 27 Jan 94 10:00:34 -0500 X-Mts: smtp One aspect I want to point out about all these discussions is getting the code up for operational experience, and the effect of resources to work on the problem, per the master solution. I am leading and writing code and have been given a few other resources to work on IPng prototype. These resources are not given to me for infinite time and will have to be used elsewhere at some time. What we have going is a TUBA and SIPP code base and what I am trying to create too is the logical OR of TUBA and SIPP code base. All of this will be under AF_INET (internet family protoocol switch). The work right now is for a Host, but routers being looked at now. The work is being done on OSF/1 only fyi. If we move to a master solution it would be good to get some basic assumptions now and quickly because this cannot be a perpetual project at my end. One design objective is to not break existing binary compatibility of exising IPv4 applications. Our goal is that an IPv4 application (except apps that use IPv4 addresses inherently like FTP) should only need to present an address type to the transport via the sock_addr structure to become an IPng app. This has not been totally figured out but are close. Our large ISV customers polled stated this was important to them. Disclamer - Because we are neutral on IPng and working on all solutions I am not permitting this code base, until it really tests some operational problems for the Internet and IPng efforts, to be used by marketing types for quick demos that prove nothing other than a file got transfered etc. I want to see the nuts and bolts get tweeked. /jim From brian@dxcoms.cern.ch Thu Jan 27 16:34:48 1994 Return-Path: brian@dxcoms.cern.ch Received: from cmsun.cmf.nrl.navy.mil (cmsun.cmf.nrl.navy.mil [134.207.10.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03718 for ; Thu, 27 Jan 1994 10:32:55 -0500 Received: from dxmint.cern.ch by cmsun.cmf.nrl.navy.mil (4.1/client-1.3) id AA18183; Thu, 27 Jan 94 10:33:05 EST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05896; Thu, 27 Jan 1994 16:34:49 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16038; Thu, 27 Jan 1994 16:34:48 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401271534.AA16038@dxcoms.cern.ch> Subject: Re: Path MTU To: ipng@cmf.nrl.navy.mil Date: Thu, 27 Jan 1994 16:34:48 +0100 (MET) In-Reply-To: <9401271443.AA08125@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jan 27, 94 09:43:12 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: 1083 Jim, > > One part of PMTU I am working on right now is detecting increases in > PMTU across the network path. Do you think this is part of PMTU fine > tuning? This is part of it of course. However as I understood Van's arguments (I have his transparencies, but only on paper) there is more to it. With a sliding window protocol, if you send one big packet per window (i.e. packet size = MTU size = window size) you will lose throughput, since the next window will have to wait until the whole packet has been handled consecutively by every router and completely read into the remote host. If you send many smaller packets you will get pipelining and therefore more throughput. This proves that there must be an optimum packet size, significantly smaller than the window size if there are many routers on the path. Therefore, it is a false assumption that the ideal packet size is the PMTU size; it may well be less. I am not an expert in this area so I think I'd better shut up. (However we definitely want all our suppliers to implement MTU discovery by yesterday :-) Brian From smb@research.att.com Thu Jan 27 10:49:35 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03819 for ; Thu, 27 Jan 1994 10:48:23 -0500 From: smb@research.att.com Message-Id: <199401271548.KAA03819@picard.cmf.nrl.navy.mil> Received: by gryphon; Thu Jan 27 10:49:36 EST 1994 To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: Path MTU Date: Thu, 27 Jan 94 10:49:35 EST > > One part of PMTU I am working on right now is detecting increases in > PMTU across the network path. Do you think this is part of PMTU fine > tuning? This is part of it of course. However as I understood Van's arguments (I have his transparencies, but only on paper) there is more to it. With a sliding window protocol, if you send one big packet per window (i.e. packet size = MTU size = window size) you will lose throughput, since the next window will have to wait until the whole packet has been handled consecutively by every router and completely read into the remote host. If you send many smaller packets you will get pipelining and therefore more throughput. This proves that there must be an optimum packet size, significantly smaller than the window size if there are many routers on the path. Therefore, it is a false assumption that the ideal packet size is the PMTU size; it may well be less. You've got it exactly right, with one minor addition: the problem still shows up if even if you send more than one packet per window, so long as the number of packets per window is (roughly) less than the number of hops. I'm glad Van is worrying about this point, too. From smb@research.att.com Thu Jan 27 10:56:42 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03858 for ; Thu, 27 Jan 1994 10:55:23 -0500 From: smb@research.att.com Message-Id: <199401271555.KAA03858@picard.cmf.nrl.navy.mil> Received: by gryphon; Thu Jan 27 10:56:43 EST 1994 To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng prototype code base and master solution Date: Thu, 27 Jan 94 10:56:42 EST One design objective is to not break existing binary compatibility of exising IPv4 applications. Our goal is that an IPv4 application (except apps that use IPv4 addresses inherently like FTP) should only need to present an address type to the transport via the sock_addr structure to become an IPng app. This has not been totally figured out but are close. Our large ISV customers polled stated this was important to them. How are you going to make that work? There's a lot of code lying around that assumes that IP addresses fit in a struct inaddr, which is 4 bytes long. From bound@zk3.dec.com Thu Jan 27 11:23:31 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA04392 for ; Thu, 27 Jan 1994 11:47:09 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA21628; Thu, 27 Jan 94 08:23:43 -0800 Received: by xirtlu.zk3.dec.com; id AA11508; Thu, 27 Jan 1994 11:23:38 -0500 Message-Id: <9401271623.AA11508@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: IPng prototype code base and master solution In-Reply-To: Your message of "Thu, 27 Jan 94 10:56:42 EST." <9401271557.AA20564@decvax.dec.com> Date: Thu, 27 Jan 94 11:23:31 -0500 X-Mts: smtp Steve, One design objective is to not break existing binary compatibility of exising IPv4 applications. Our goal is that an IPv4 application (except apps that use IPv4 addresses inherently like FTP) should only need to present an address type to the transport via the sock_addr structure to become an IPng app. This has not been totally figured out but are close. Our large ISV customers polled stated this was important to them. >How are you going to make that work? There's a lot of code lying >around that assumes that IP addresses fit in a struct inaddr, which >is 4 bytes long. Well at first for SIP (without plus P) it was real easy as the sin_zero field was exactly 8 bytes. The gethostbyname would ask for a type SIP or IPv4 and start a server concurrent or iterative session on a port. If a client needed IPv4 or SIP the server would know and just pass a parameter to the forked or threaded client SIP or IPv4 and it could then use either address space via my integrated network layer. But with SIPP [Plus P] the address now could be an Address Sequence Record of multiple 64bit segments. Now SIPP has the same potential problem TUBA does in that there is no way to fit the large address in the present sock_addr_in structure. But I would still like to not break apps. So (and this is very rough and we are talking technical turkey now internally on this now OK) mabye we move in the kernel space to the BSD 4.4 sock_addr which permits a length field and variable address length. At the application layer the address structure it becomes even more opaque than now and for those instances where the binary would break we build "shims" (I know I hate this word). All addresses now in the kernel are using the 4.4 variable address structure. But in case of SIPP if 64bits of the address sequence record can alwayus be unique and in the transport I can differentiate the sequence records then I can prepend the prefix and addr seq segments to the tcpcb structure using 4.4 sock_addr_in. This would take care of alignments. But I am now believing we should move to 4.4 sock_addr_in regardless for any IPng. We may have no choice but to break binary compatibility but I am going to try to figure out a way to not let this happen for any IPng. I think the reason APIs keep coming up in IPng now is not that we want to get into that standards effort in the IETF but then the IETF never created a standard protocol that broke the API before either. /jim From bound@zk3.dec.com Thu Jan 27 11:43:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08861 for ; Thu, 27 Jan 1994 12:09:56 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA22554; Thu, 27 Jan 94 08:43:55 -0800 Received: by xirtlu.zk3.dec.com; id AA12038; Thu, 27 Jan 1994 11:43:53 -0500 Message-Id: <9401271643.AA12038@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Path MTU In-Reply-To: Your message of "Thu, 27 Jan 94 16:34:48 +0100." <9401271534.AA16038@dxcoms.cern.ch> Date: Thu, 27 Jan 94 11:43:47 -0500 X-Mts: smtp Brian and Steve too, >This is part of it of course. However as I understood Van's arguments (I >have his transparencies, but only on paper) there is more to it. With a >sliding window protocol, if you send one big packet per window (i.e. >packet size = MTU size = window size) you will lose throughput, since the >next window will have to wait until the whole packet has been handled >consecutively by every router and completely read into the remote host. >If you send many smaller packets you will get pipelining and therefore >more throughput. This proves that there must be an optimum packet size, >significantly smaller than the window size if there are many routers on >the path. Therefore, it is a false assumption that the ideal packet size >is the PMTU size; it may well be less. Yes this is definitely an issue. But, the PMTU can converge on the optimum segment size via the congestion window. Also the window size must be an exact multiple of the segment size. If networks get faster and throughput more efficient the PMTU can be larger. >I am not an expert in this area so I think I'd better shut up. Please dont do that the discussion is going good I think. We may need to get Jeff Mogul, Steve Deering, or Steve Bellovin to correct us once in awhile but we should move forward >(However we definitely want all our suppliers to implement MTU discovery >by yesterday :-) OK ......thats good input too.............. /jim From bound@zk3.dec.com Fri Jan 28 00:16:06 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA13850 for ; Fri, 28 Jan 1994 00:22:11 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA17994; Thu, 27 Jan 94 21:16:13 -0800 Received: by xirtlu.zk3.dec.com; id AA26990; Fri, 28 Jan 1994 00:16:12 -0500 Message-Id: <9401280516.AA26990@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: PMTU and Pipelining Date: Fri, 28 Jan 94 00:16:06 -0500 X-Mts: smtp I asked Jeff Mogul if he could give me an interpretation of Vans pipeline issue. Here is what I got back. /jim ------------------------------- Text from Brian However as I understood Van's arguments (I have his transparencies, but only on paper) there is more to it. With a sliding window protocol, if you send one big packet per window (i.e. packet size = MTU size = window size) you will lose throughput, since the next window will have to wait until the whole packet has been handled consecutively by every router and completely read into the remote host. If you send many smaller packets you will get pipelining and therefore more throughput. This proves that there must be an optimum packet size, significantly smaller than the window size if there are many routers on the path. Therefore, it is a false assumption that the ideal packet size is the PMTU size; it may well be less. End Test from Brian --------------------------- ----------------------------- Text from Jeff This is only part of Vans argument there is more. Yes, it is quite horribly awful to have MTU size = window size (actually, to have window size < 2 * MSS), but that is independent of pipelining in general, or MTU discovery in particularly. It has to do mostly with the standard TCP delayed ACK mechanism. What an end-system TCP implementation should do is to *not allow* the use of window sizes (receive or transmit buffer sizes) below (2 * first_hop_mss), which is normally (2 * (first_hop_mtu - 40)). With today's common networks, this normally means that the window size has to be larger than 3kB (for Ethernet) or 8.7kB (for FDDI, unless people would follow my suggestion and use a 4K MSS for FDDI, in which case the minimal safe window size would be exactly 8K and life would be a lot better. Hint, hint.) Note that PMTUD will never increase the path MTU estimate above the first hop MTU. So if the system sets the window size at least to (2 * first_hop_mss), then the condition "window size >= 2 * MSS" will always be true. Note that this is complicated by the fact that sosend() does manifestly the wrong thing in deciding when to move more data from user space into an outgoing socket buffer. It can screw up spectactularly badly even when PMTUD is not used, but because its effect on performance is so unstable, if PMTUD causes use of a different MSS, people may encounter nasty surprises. The proper solution is to get rid of sosend(), or at least make it cognizant of the underlying transport's current MSS. Getting back to pipelining: if you want TCP to exhibit proper pipelining, then the window size (i.e., both receive and transmit buffer size) has to be large enough to hold enough data to fill the entire pipeline. This has little to do with MSS size, except that if the MSS is small, then a given amount of useful data requires more header bytes, and so the pipeline fills faster. But it fills up with useless bits, so this is not a net win for useful-data bandwidth. Also, since many routers limit the number of packets queued (not just the number of bytes queued), using unnecessarily small packets can cause early buffer overflow and packet loss. In short: PMTUD does the right thing. TCP does the right thing, if the buffer sizes are large enough. sosend() does the wrong thing, but that's independent of PMTUD. -Jeff ------------------------------------ From brian@dxcoms.cern.ch Fri Jan 28 09:02:08 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA14390 for ; Fri, 28 Jan 1994 03:00:27 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00739; Fri, 28 Jan 1994 09:02:10 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01396; Fri, 28 Jan 1994 09:02:08 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401280802.AA01396@dxcoms.cern.ch> Subject: My discussion with Paul Van Binst To: ipng@cmf.nrl.navy.mil, vcerf@cnri.reston.va.us (Vint Cerf) Date: Fri, 28 Jan 1994 09:02:08 +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: 897 Just a few words on my discussion yesterday with Paul Van Binst, who chairs the EWOS Steering Committee. Paul is convinced that to get official recognition in Europe (i.e. by governments and by the European Union) standards have to be formal, i.e. ISO or ITU standards. EWOS is currently discussing what to do about de facto standards, and unfortunately they include IETF standards in this category. His view is that only by submitting IETF standards on fast-track procedures to ISO can they achieve the necessary level of formality. This of course raises the issue of change control passing from IETF to ISO. He mentioned that EWOS is planning a conference on Open Systems Standards later this year (date t.b.d.) where these issues will be debated. My conclusion: there is zero chance of anything equivalent to the FIRP report in Europe, on a timescale relevant to the IPng choice. Brian From sob@hsdndev.harvard.edu Fri Jan 28 10:06:38 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA00675 for ; Fri, 28 Jan 1994 11:31:34 -0500 Date: Fri, 28 Jan 94 10:06:38 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9401281506.AA23269@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: John"s points I've been catching up on mail after two days off to ComNet. I notice that John Curran sent out a message postulating a few things that generated quite a bit of exchange but I noticed that the prime representives for the three proposals did not seem to take part in the exchanges. Can Steve, Mark & Rob chime in with their thoughts? Scott From deering@parc.xerox.com Fri Jan 28 14:29:56 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA03241 for ; Fri, 28 Jan 1994 17:28:43 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <15059(7)>; Fri, 28 Jan 1994 14:30:12 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 28 Jan 1994 14:30:06 -0800 To: ipng@cmf.nrl.navy.mil Cc: deering@parc.xerox.com Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: jcurran's message of Wed, 26 Jan 94 10:55:32 -0800. <94Jan26.105653pst.15338(2)@alpha.xerox.com> Date: Fri, 28 Jan 1994 14:29:56 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan28.143006pst.12171@skylark.parc.xerox.com> > From: John Curran > > 1. Hierarchical prefix-based routing with aggregation (as recommended in > CIDR, SIPP, and TUBA) has the potential for routing scaling if adaquate > backpressure mechanisms exist. As a result of CIDR, IPng does not have > to "solve" the routing scaling problem for IPv4. I think this is still an open question -- if a significant number of those sites that have obtained a (pre-CIDR) IP network number, but have never attached to the Internet, were to attach over the next year or so (not an entirely farfetched possibility, given all the hype that the Internet is getting), the backbone routing tables still might explode. But perhaps you are right. IN THAT CASE, the IPAE mapping table degenerates into a table with only ONE entry, which maps all IP network numbers to a single, 32-bit prefix. Maintenance of that "table" is a non-issue. In that mode, IPAE is basically the same as CATNIP when translating from IPv4 to IPng. (However, it differs in the IPng to IPv4 direction, in that IPAE does not rely on the correct handling of previously-undefined IPv4 options by existing IPv4 systems, a black-hole-vulnerable assumption of CATNIP. In the last CATNIP draft I read, that was only one of several black-hole vulnerabilities; I'd better read Robert's latest to see if he has patched those holes before I say more.) On the other hand, you may be wrong. Maybe we will have a routing-table- size crisis before we have sufficient deployment of IPng systems. In that case, if we adopt IPAE, we will have a backup solution in place. Yes, it will be a major chore to maintain the mapping tables, but if we come to that point, I assume we will be willing to perform that chore in order to keep the Internet alive. > Once IPv4 addresses are no longer available, it is desirable (but not > required) to allow interoperability between new IPng systems and IPv4. Who are we to say that allowing IPng systems to communicate with IPv4 systems basically "for ever" within local sub-regions of the Internet (whether by translation or by dual-stacking) is not a requirement? I suspect that it *would* be a requirement for many sites. > ...Likewise, the cost > of variable length addressing is not actually a performance burden. Huh? It depends on your particular device, whether or not variable-length addressing is a performance burden. It might not be a burden on the latest hot-shot router architecture, but it might well be a burden on a memory- or CPU-challenged host. > o IPAE was designed originally as a method for improving route scaling > and providing IPng-IPv4 interoperability within IPv4 commonwealths. Extending the IPv4 address space was also one of its major design goals. > ...IPAE's signficant difference over other transition schemes remains > its ability to support multiple IPv4 uniqueness regions once IPv4 > addresses are no longer globally unique. I don't think that property is unique to IPAE -- any of the proposed schemes can provide that capability. What IPAE provides is that capability *without* having to keep an IPv4 stack on your IPng systems indefinitely. > Dual-stack deployment _cannot_ work in some circumstances (once IPv4 > addresses are not readily available, sites will be unable to deploy new > systems which can communicate with important IPv4 legacy systems, due to > lack of a IPv4 address). As Ross pointed out, this can be handled by allocating part of the IPv4 address space for local-use only. > If this group needs to make a quick decision, let it be NAT. Gag me with a chainsaw. > ... SIP started as close to IPv4 as possible (quite a reasonable starting > point) but now that variable length addresses have actually become accepted, Well, there's still at least one hold-out for fixed-length (64-bits, in fact) addresses -- me. SIPP happens to support variable-length addressing through use of the Routing Header, but I consider that observation as something to increase the comfort level of the address-space claustrophobes, not something we'd ever really need to use. (The real value of the Routing Header is for other functionality, such as provider-selection.) > ... Forwarding across SIP extended address spaces requires a circular > rewrite to get the next address element into the header, and this is not > going to pipeline easily in anyone's hardware. If we never go to extended addresses, that won't be a issue. And if we do, the effect occurs only at major boundaries (not at every or even most hops), where performance is probably already being sacrificed for things like firewall filtering. Steve From deering@parc.xerox.com Fri Jan 28 15:05:39 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA03428 for ; Fri, 28 Jan 1994 18:04:14 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <15207(7)>; Fri, 28 Jan 1994 15:05:45 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 28 Jan 1994 15:05:40 -0800 To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: what do you all think? In-reply-to: sob's message of Fri, 21 Jan 94 18:06:33 -0800. <9401220206.AA13477@hsdndev.harvard.edu> Date: Fri, 28 Jan 1994 15:05:39 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan28.150540pst.12171@skylark.parc.xerox.com> Scott, You asked what we thought of the message from Rex Buddenburg regarding future evolution of the Internet and the role of XTP in that future. I think his description of the likely evolution of the Internet is quite believable (though the idea of switching ATM cells over the CATV cable plant is even more braindamaged than expected from the packet-shredding crowd), but I don't see any place for XTP in that future. For years, XTP has been trying to find an ecological niche -- first it was going to replace TCP because TCP was too slow, then it was peddled to ANSI as TP-5, and to IEEE as a new LLC, and now its being positioned as the "next generation transport protocol" that can do not only everything TCP can do, but multicast video and audio too! I guess we'd better stop sending audio and video around the Internet until we get XTP deployed, eh? Uncharitably, Steve From jcurran@nic.near.net Fri Jan 28 18:17:03 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA03460 for ; Fri, 28 Jan 1994 18:14:51 -0500 Message-Id: <199401282314.SAA03460@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa10007; 28 Jan 94 18:17 EST To: Steve Deering cc: ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-reply-to: Your message of Fri, 28 Jan 1994 14:29:56 -0800. <94Jan28.143006pst.12171@skylark.parc.xerox.com> Date: Fri, 28 Jan 1994 18:17:03 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Fri, 28 Jan 1994 14:29:56 PST ] ] I think this is still an open question -- if a significant number of those ] sites that have obtained a (pre-CIDR) IP network number, but have never ] attached to the Internet, were to attach over the next year or so (not an ] entirely farfetched possibility, given all the hype that the Internet is ] getting), the backbone routing tables still might explode. Either: o These new sites will acquire CIDR-friendly addresses. -or- o These new sites will pay sufficient funds to offset the cost of their route entry in the global Internet. Explosion isn't a possibility, business factors enter the equation first. ] But perhaps you are right. IN THAT CASE, the IPAE mapping table degenerates ] into a table with only ONE entry, which maps all IP network numbers to a ] single, 32-bit prefix. Maintenance of that "table" is a non-issue. In that ] mode, IPAE is basically the same as CATNIP when translating from IPv4 to IPng. ] (However, it differs in the IPng to IPv4 direction, in that IPAE does not ] rely on the correct handling of previously-undefined IPv4 options by ] existing IPv4 systems, a black-hole-vulnerable assumption of CATNIP. ] In the last CATNIP draft I read, that was only one of several black-hole ] vulnerabilities; I'd better read Robert's latest to see if he has patched ] those holes before I say more.) Interesting view of CATNIP... I hadn't thought of it in comparision to IPAE. (Time to catch up with reading :-) ] On the other hand, you may be wrong. Maybe we will have a routing-table- ] size crisis before we have sufficient deployment of IPng systems. In that ] case, if we adopt IPAE, we will have a backup solution in place. Yes, it ] will be a major chore to maintain the mapping tables, but if we come to that ] point, I assume we will be willing to perform that chore in order to keep ] the Internet alive. We have plenty of backup solutions available (NAT, renumbering, etc.); I would not presume that maintaining that routing/mapping table is the one with the least cost. And unlike IPng, workarounds will be deployed in an "as hoc" manner by providers based strictly upon cost. (Let's all hope that IPng is not put into production in an ad-hoc manner...) The IPAE mapping tables are as deployable as hierachical renumbering for the entire Internet, but IPAE has additional reliability, diagnosis, and configuraton side effects that (personal opinion) I find absolutely unacceptable (except in the derivative case described above with 1 entry). It's possible that other Internet service providers feel differently; it would probably be best if we sought input outside the directorate on this matter. ] > ... SIP started as close to IPv4 as possible (quite a reasonable starting ] > point) but now that variable length addresses have actually become accepted, ] ] Well, there's still at least one hold-out for fixed-length (64-bits, in fact) ] addresses -- me. SIPP happens to support variable-length addressing through ] use of the Routing Header, but I consider that observation as something to ] increase the comfort level of the address-space claustrophobes, not ] something we'd ever really need to use. (The real value of the Routing ] Header is for other functionality, such as provider-selection.) ] ] > ... Forwarding across SIP extended address spaces requires a circular ] > rewrite to get the next address element into the header, and this is not ] > going to pipeline easily in anyone's hardware. ] ] If we never go to extended addresses, that won't be a issue. And if we ] do, the effect occurs only at major boundaries (not at every or even most ] hops), where performance is probably already being sacrificed for things ] like firewall filtering. Major boundaries are likely to traffic concentration points between providers; thus the circular rewrite is going to occur at a unfortunate location. I don't think that this is a serious problem, but then I'm generally willing to swap performance for other benefits. /John From vcerf@CNRI.Reston.VA.US Fri Jan 28 19:26:38 1994 Return-Path: vcerf@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 TAA03770 for ; Fri, 28 Jan 1994 19:31:39 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15812; 28 Jan 94 19:26 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: My discussion with Paul Van Binst In-reply-to: Your message of "Fri, 28 Jan 94 09:02:08 +0100." <9401280802.AA01396@dxcoms.cern.ch> Date: Fri, 28 Jan 94 19:26:38 -0500 From: "Vinton G. Cerf" Message-ID: <9401281926.aa15812@IETF.CNRI.Reston.VA.US> Brian, is it possible that the FIRP outcome, assuming it is essentially unchanged after the comment period, can be used to persuade some of our European colleagues to reconsider their positions? I certainly cannot imagine that any procedure which resulted in loss of IETF responsibility for the Internet Standards would be beneficial. vint From bound@zk3.dec.com Fri Jan 28 21:22:54 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id VAA04138 for ; Fri, 28 Jan 1994 21:28:41 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA25189; Fri, 28 Jan 94 18:23:23 -0800 Received: by xirtlu.zk3.dec.com; id AA19583; Fri, 28 Jan 1994 21:23:00 -0500 Message-Id: <9401290223.AA19583@xirtlu.zk3.dec.com> To: deering@parc.xerox.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Question and SIPP address idea ... Date: Fri, 28 Jan 94 21:22:54 -0500 X-Mts: smtp Steve, I also still believe 64bits are enough for any one site. But, how they remain globally unique and how an additional 64bit or 128bit set of prefixes are implemented is the clarity I strive for and here is what I have come up with for now. Do you think this would work? With a SIPP address of 64bits that gives any local site more than enough address space to run all their circuits for at least the life of a network generation (lets say 30 years). 2**64th is quite large. I think applications should only care about the actual address of that which it is communicating with and routing to that which it is communicating with is a function of the network layer and those algorithms. This funtionality depending on how you structure the routign heirarcy and the unforseen gotchas that happen could use an extended address like a SIPP ADDR SEQ I think. When a SIPP ADDR SEQ is needed and in fact does exist it would be transparent to the application and just exist within the returned ASEQ Address record. The application would always only bind its socket address to its site destination 64bit address and assume transmit or listen/accept from a peer 64bit site address. But, the entire ADDR SEQ record could (not required until needed) be passed to the transport layer through a paramater in the socket abstraction from the server or client application. The transport layer would package that ASEQ record as an appended data structure in the inpcb or tcpcb, which could be used by the network layer protocol and routing algorithms if required. I want to get a logic check before I move forward with this design strategy? This would also keep SIPP 64bit address for applications and remove on the LAN the need to create uneeded alignments in the tcp or udp code path for performance reasons in most cases. Most traffic for applications is on the LAN not over the backbone and this will be the case for many years to come. Hence I prefer too not bog down my code base with extended wrapped or padded address space on my Host. So whats my motive: Performance and maintaining existing binary compatibility without shims. I just tried designing a shim for 160bits and 192bit addresses today with another engineer and its bogus so far. thanks /jim thanks /jim From brian@dxcoms.cern.ch Mon Jan 31 08:42:09 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA05046 for ; Mon, 31 Jan 1994 02:40:18 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23767; Mon, 31 Jan 1994 08:42:09 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22486; Mon, 31 Jan 1994 08:42:09 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401310742.AA22486@dxcoms.cern.ch> Subject: Re: My discussion with Paul Van Binst To: vcerf@CNRI.Reston.VA.US (Vinton G. Cerf) Date: Mon, 31 Jan 1994 08:42:09 +0100 (MET) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil In-Reply-To: <9401281926.aa15812@IETF.CNRI.Reston.VA.US> from "Vinton G. Cerf" at Jan 28, 94 07:26:38 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: 511 >--------- Text sent by Vinton G. Cerf follows: > > Brian, > > is it possible that the FIRP outcome, assuming it is essentially > unchanged after the comment period, can be used to persuade some > of our European colleagues to reconsider their positions? Yes but on a very long timescale! > > I certainly cannot imagine that any procedure which resulted in > loss of IETF responsibility for the Internet Standards would be > beneficial. > I would not wish to suggest this in an IETF plenary :-) Brian From francis@cactus.ntt.jp Mon Jan 31 10:13:57 1994 Return-Path: francis@cactus.ntt.jp Received: from koudai.cs.titech.ac.jp (koudai.cs.titech.ac.jp [131.112.176.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with ESMTP id UAA04137 for ; Sun, 30 Jan 1994 20:29:56 -0500 Received: by koudai.cs.titech.ac.jp (2.3W/koudai); Mon, 31 Jan 1994 10:31:20 +0900 Received: by lab.ntt.jp (8.6.4/GATENTTMX0.91); Mon, 31 Jan 1994 10:11:57 +0900 Received: from cactus.ntt.jp by ntt-twins.ntt.jp (8.5/NTTcs02b) id KAA13474; Mon, 31 Jan 1994 10:11:21 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Mon, 31 Jan 94 10:13:57 JST Date: Mon, 31 Jan 94 10:13:57 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9401310113.AA06153@cactus.ntt.jp> To: bound@zk3.dec.com, deering@parc.xerox.com Subject: Re: Question and SIPP address idea ... Cc: ipng@cmf.nrl.navy.mil > > I also still believe 64bits are enough for any one site. But, how they > remain globally unique and how an additional 64bit or 128bit set of > prefixes are implemented is the clarity I strive for and here is what I > have come up with for now. > > Do you think this would work? Jim, Attached is the latest version of the routing and addressing draft, which will be posted real soon now. Please look over the parts on API and let me know what you think. > > > So whats my motive: Performance and maintaining existing binary > compatibility without shims. I just tried designing a shim for 160bits > and 192bit addresses today with another engineer and its bogus so far. > Please talk to Ramesh about this (rxg@thumper.bellcore.com). He and Sue Thomson had TCP and above binaries working over Pip on SunOS just fine. I just don't enough details to be intelligent about it.... PF From Robert_Ullmann.LOTUS@CRD.lotus.com Mon Jan 31 07:28:24 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08459 for ; Mon, 31 Jan 1994 12:24:11 -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 AA02841; Mon, 31 Jan 94 12:28:06 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA13828; Mon, 31 Jan 94 07:28:24 EST Date: Mon, 31 Jan 94 07:28:24 EST Message-Id: <9401311228.AA13828@Mail.Lotus.com> Received: by DniMail (v1.0); Mon Jan 31 07:28:21 1994 EDT To: UNIXML::"ipng-request@cmf.nrl.navy.mil"@lotus.com Subject: Re: Proposal history (Steve Deering) ] But perhaps you are right. IN THAT CASE, the IPAE mapping table degenerates ] into a table with only ONE entry, which maps all IP network numbers to a ] single, 32-bit prefix. Maintenance of that "table" is a non-issue. In that ] mode, IPAE is basically the same as CATNIP when translating from IPv4 to IPng. ] (However, it differs in the IPng to IPv4 direction, in that IPAE does not ] rely on the correct handling of previously-undefined IPv4 options by ] existing IPv4 systems, a black-hole-vulnerable assumption of CATNIP. ] In the last CATNIP draft I read, that was only one of several black-hole ] vulnerabilities; I'd better read Robert's latest to see if he has patched ] those holes before I say more.) The basic case that highlights this is two IPng systems communicating via an intervening IPv4 network. IPAE does this by encapsulating the datagram in a new "transport layer", while CATNIP moves the extra addressing into an IP option. Both cause datagrams to be black holed (or similar problems); the option causes systems that react "badly" to discard datagrams. The "transport" causes systems implementing protocol filters to discard datagrams. Actual live research on the net showed that the CATNIP address extension option caused 3 particular problems. (There were ~7000 paths tested.) 1) Prime 50-series systems discarded the datagram as malformed. This was fixed in a subsequent release. (And this is a little emabarrasing, since I was the engineer who reviewed and signed off on that code! :-) 2) Sun systems (at 4.1.1, and unknown other revs) crash when sent certain combinations. This can be used *now* to shoot down the majority of Suns on the net, since it only takes a single datagram sent from anywhere to do it, and it works every time. I suspect Sun will be fixing this. (you think? :-) 3) One router in the infrastructure tested (one single box, not one type!) was observed to drop datagrams; this was the ANS border router (ANS the organization, not ANS the network.) To compare with this, ALL routers implementing filters dropped IPAE datagrams silently, and this can't be fixed by configuring them to pass IPAE without effectively disabling the filter. Fixing this requires organization border routers to become IPAE-knowledgeble before host deployment; this is exactly the kind of deployment constraint IPv7/CATNIP was designed to avoid inflicting on administrations. (John Curran) > Interesting view of CATNIP... I hadn't thought of it in comparision to IPAE. > (Time to catch up with reading :-) My god, have I been that bad at communicating? CATNIP doesn't need an "IPAE" type transition mechanism. The mechanism is built in. (And predates IPAE BTW having been the essential feature of the 1989 TP/IX draft :-) All of the issues in the IPAE transition are addressed directly in the CATNIP design, except of course for the ones *created* by the IPAE approach. SIPP would be better off without IPAE. See the -02 CATNIP draft, section 8. (This may have been what cause Steve to lose his marbles last week and blast off that nastygram; I think we ought to forgive him.) Best Regards, Robert From Robert_Ullmann.LOTUS@CRD.lotus.com Mon Jan 31 07:29:58 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08462 for ; Mon, 31 Jan 1994 12:24:21 -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 AA02854; Mon, 31 Jan 94 12:28:13 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA13876; Mon, 31 Jan 94 07:29:58 EST Date: Mon, 31 Jan 94 07:29:58 EST Message-Id: <9401311229.AA13876@Mail.Lotus.com> Received: by DniMail (v1.0); Mon Jan 31 07:29:56 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: Proposal history (Steve Deering) ] But perhaps you are right. IN THAT CASE, the IPAE mapping table degenerates ] into a table with only ONE entry, which maps all IP network numbers to a ] single, 32-bit prefix. Maintenance of that "table" is a non-issue. In that ] mode, IPAE is basically the same as CATNIP when translating from IPv4 to IPng. ] (However, it differs in the IPng to IPv4 direction, in that IPAE does not ] rely on the correct handling of previously-undefined IPv4 options by ] existing IPv4 systems, a black-hole-vulnerable assumption of CATNIP. ] In the last CATNIP draft I read, that was only one of several black-hole ] vulnerabilities; I'd better read Robert's latest to see if he has patched ] those holes before I say more.) The basic case that highlights this is two IPng systems communicating via an intervening IPv4 network. IPAE does this by encapsulating the datagram in a new "transport layer", while CATNIP moves the extra addressing into an IP option. Both cause datagrams to be black holed (or similar problems); the option causes systems that react "badly" to discard datagrams. The "transport" causes systems implementing protocol filters to discard datagrams. Actual live research on the net showed that the CATNIP address extension option caused 3 particular problems. (There were ~7000 paths tested.) 1) Prime 50-series systems discarded the datagram as malformed. This was fixed in a subsequent release. (And this is a little emabarrasing, since I was the engineer who reviewed and signed off on that code! :-) 2) Sun systems (at 4.1.1, and unknown other revs) crash when sent certain combinations. This can be used *now* to shoot down the majority of Suns on the net, since it only takes a single datagram sent from anywhere to do it, and it works every time. I suspect Sun will be fixing this. (you think? :-) 3) One router in the infrastructure tested (one single box, not one type!) was observed to drop datagrams; this was the ANS border router (ANS the organization, not ANS the network.) To compare with this, ALL routers implementing filters dropped IPAE datagrams silently, and this can't be fixed by configuring them to pass IPAE without effectively disabling the filter. Fixing this requires organization border routers to become IPAE-knowledgeble before host deployment; this is exactly the kind of deployment constraint IPv7/CATNIP was designed to avoid inflicting on administrations. (John Curran) > Interesting view of CATNIP... I hadn't thought of it in comparision to IPAE. > (Time to catch up with reading :-) My god, have I been that bad at communicating? CATNIP doesn't need an "IPAE" type transition mechanism. The mechanism is built in. (And predates IPAE BTW having been the essential feature of the 1989 TP/IX draft :-) All of the issues in the IPAE transition are addressed directly in the CATNIP design, except of course for the ones *created* by the IPAE approach. SIPP would be better off without IPAE. See the -02 CATNIP draft, section 8. (This may have been what cause Steve to lose his marbles last week and blast off that nastygram; I think we ought to forgive him.) Best Regards, Robert From Robert_Ullmann.LOTUS@CRD.lotus.com Mon Jan 31 08:03:45 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08456 for ; Mon, 31 Jan 1994 12:23:50 -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 AA02808; Mon, 31 Jan 94 12:27:43 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA13963; Mon, 31 Jan 94 08:03:45 EST Date: Mon, 31 Jan 94 08:03:45 EST Message-Id: <9401311303.AA13963@Mail.Lotus.com> Received: by DniMail (v1.0); Mon Jan 31 08:03:43 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: note re that Sun bug I forgot to mention one thing about the Sun bug: it was triggered by an implementation of the RFC1475 option, and seemed highly dependent on the exact position of bytes and length of the datagram. The option as defined in -02 CATNIP doesn't seem to have the same effect, but I haven't tested it side-by-side with the same targets. The change wasn't made to avoid the Sun problem. Robert From brian@dxcoms.cern.ch Mon Jan 31 14:08:08 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id IAA05801 for ; Mon, 31 Jan 1994 08:06:18 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00124; Mon, 31 Jan 1994 14:08:09 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05074; Mon, 31 Jan 1994 14:08:09 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401311308.AA05074@dxcoms.cern.ch> Subject: Re: CLNP is it good enough for the future To: ipng@cmf.nrl.navy.mil Date: Mon, 31 Jan 1994 14:08:08 +0100 (MET) In-Reply-To: <199401282134.QAA02882@picard.cmf.nrl.navy.mil> from "John Curran" at Jan 25, 94 02:24:55 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: 1027 >--------- Text sent by John Curran follows: ... > If we're going to tell the entire Internet applications community to "just > migrate to this new address format", it would be in our best interest to > provide them new interfaces to the network which result in needed > capabilities being deployed. > Are you sure? I've been remembering the first time I ever discussed DECnet Phase V with an Important Person (IP:-) from DEC. It was my perception then (1985?) that this was all going to be very difficult, and that an easy though messy thing would be a maintenance release of DECnet Phase IV where 16 bit addresses were changed to 32 bits. Yep, the APIs would change, but in a very simple way. Lousy, boring software mods. Yawn. Cost a few million dollars. Boy, do I wish they had taken that lousy, boring approach! So if we are in the end going to "just migrate to this new address format" then there is an easy, messy, lousy, boring approach, isn't there? > Sorry to rave, > /John > No need to apologise Brian From jcurran@nic.near.net Mon Jan 31 09:11:56 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA06196 for ; Mon, 31 Jan 1994 09:09:50 -0500 Message-Id: <199401311409.JAA06196@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa04193; 31 Jan 94 9:12 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-reply-to: Your message of Mon, 31 Jan 1994 14:08:08 +0100. <9401311308.AA05074@dxcoms.cern.ch> Date: Mon, 31 Jan 1994 09:11:56 -0500 From: John Curran -------- ] From: Brian Carpenter CERN-CN ] Subject: Re: CLNP is it good enough for the future ] Date: Mon, 31 Jan 1994 14:08:08 +0100 (MET) ] ] >--------- Text sent by John Curran follows: ] ... ] > If we're going to tell the entire Internet applications community to "just ] > migrate to this new address format", it would be in our best interest to ] > provide them new interfaces to the network which result in needed ] > capabilities being deployed. ] > ] ] Are you sure? ] ] I've been remembering the first time I ever discussed DECnet Phase V ] with an Important Person (IP:-) from DEC. It was my perception then ] (1985?) that this was all going to be very difficult, and that an easy ] though messy thing would be a maintenance release of DECnet Phase IV ] where 16 bit addresses were changed to 32 bits. Yep, the APIs would ] change, but in a very simple way. Lousy, boring software mods. Yawn. ] Cost a few million dollars. ] ] Boy, do I wish they had taken that lousy, boring approach! Be careful in stretching the analogy... most folks leave DECNET Phase IV because they *locally* run out of address space (often in terms of areas). In IPng, individual sites do not feel the pressure of the address space depletion.... only new sites (and of course, network service providers) have to deal with the problem. In truth, we need to have an extremely simple API transition (ideally, simple to the point of being transparent to existing applications.) On the other hand, new capabilities in the network will not be utilized unless we include the functionality (and matching APIs) to use such in the base release. /John From bound@zk3.dec.com Mon Jan 31 10:03:13 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA07003 for ; Mon, 31 Jan 1994 10:12:45 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA28103; Mon, 31 Jan 94 07:03:21 -0800 Received: by xirtlu.zk3.dec.com; id AA29204; Mon, 31 Jan 1994 10:03:19 -0500 Message-Id: <9401311503.AA29204@xirtlu.zk3.dec.com> To: John Curran Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-Reply-To: Your message of "Mon, 31 Jan 94 09:11:56 EST." <199401311409.JAA06196@picard.cmf.nrl.navy.mil> Date: Mon, 31 Jan 94 10:03:13 -0500 X-Mts: smtp Also most of my customers have not run out of PhIV address space either. Also seeing a phenomenal growth in our IP base from PhIV all over the world not just in the U.S. /jim From bound@zk3.dec.com Mon Jan 31 10:05:06 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA07007 for ; Mon, 31 Jan 1994 10:12:51 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA28194; Mon, 31 Jan 94 07:05:15 -0800 Received: by xirtlu.zk3.dec.com; id AA29273; Mon, 31 Jan 1994 10:05:12 -0500 Message-Id: <9401311505.AA29273@xirtlu.zk3.dec.com> To: francis@cactus.ntt.jp (Paul Francis) Cc: ipng@cmf.nrl.navy.mil Subject: Re: Question and SIPP address idea ... In-Reply-To: Your message of "Mon, 31 Jan 94 10:13:57 +0200." <9401310113.AA06153@cactus.ntt.jp> Date: Mon, 31 Jan 94 10:05:06 -0500 X-Mts: smtp Paul, There was not attachment to your mail message fyi. ?????????? At least on my end. ???? thanks /jim From Greg_Minshall@Novell.COM Mon Jan 31 07:43:41 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA07411 for ; Mon, 31 Jan 1994 10:47:54 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16138; Mon, 31 Jan 94 08:54:04 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06547; Mon, 31 Jan 94 07:43:41 PST Date: Mon, 31 Jan 94 07:43:41 PST Message-Id: <9401311543.AB06547@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: telechat yesterday... First off, i think that part of IPAE is, basically, a NAT box (it just happens to be NATting between two different internet protocols). Were we basically spending our time yesterday talking about whether or not we should try to make life simpler, rather than harder, on the designers of NAT boxes? Today, people are shipping IPv4 boxes. Tomorrow (maybe!), people will be shipping boxes with both IPng and IPv4. At some point, people will start shipping boxes with only IPng. At various points there, people may decide to start shipping IPv4<>IPv4 NAT boxes as well as IPng<>IPv4 NAT boxes as well as (for who knows what reason!) IPng<>IPng NAT boxes. We can't stop this from happening. However, we can try to make life easier on the designers of NAT boxes. Greg From Greg_Minshall@Novell.COM Mon Jan 31 07:43:52 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA07410 for ; Mon, 31 Jan 1994 10:47:53 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16152; Mon, 31 Jan 94 08:54:15 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06547; Mon, 31 Jan 94 07:43:52 PST Date: Mon, 31 Jan 94 07:43:52 PST Message-Id: <9401311543.AB06547@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: Interoperation, Encapsulation, Translation, and Dual Stacks Cc: ipng@cmf.nrl.navy.mil Jim, >In this case it appears you have a true dual stack. I was speaking of >Hosts but thats OK. I have NO IDEA what in heaven's name an upper case Host is supposed to be. Sounds like some very holy thing. However, a router which has an IP address of its own is, in fact, a real live lower case host. Bah! >On a Host most OSI implementations are under the AF_ISO comm domain. The >IP is under the AF_INET domain. I figure the best way right now is to >implement IPng under AF_INET domain where the infrastructure will change >the least. I think that overloading AF_INET with IPng stuff is probably a mistake. Probably AF_WHATEVER, or some such, with the socket *actually* getting bound at connect() or bind() time. (Sorry, APIs again.) Greg From Greg_Minshall@Novell.COM Mon Jan 31 07:43:57 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA07420 for ; Mon, 31 Jan 1994 10:48:00 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16160; Mon, 31 Jan 94 08:54:21 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06547; Mon, 31 Jan 94 07:43:57 PST Date: Mon, 31 Jan 94 07:43:57 PST Message-Id: <9401311543.AB06547@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: Brian's paper/Translation Cc: ipng@cmf.nrl.navy.mil Jim, >It does no good to call things bogus. I think it is *just fine* to call an *idea* "bogus" (especially if the idea is, in fact, bogus). We need to make strong technical comments. This is part of the "technical" aspect of the process. (I do *NOT* think it is OK to call people "bogus" or any other such thing.) Greg Minshall From rcallon@wellfleet.com Mon Jan 31 10:56:08 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA07442 for ; Mon, 31 Jan 1994 10:49:26 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25025; Mon, 31 Jan 94 10:36:25 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA07614; Mon, 31 Jan 94 10:46:04 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA18724; Mon, 31 Jan 94 10:56:08 EST Date: Mon, 31 Jan 94 10:56:08 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401311556.AA18724@cabernet.wellfleet> To: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) On the other hand, you may be wrong. Maybe we will have a routing-table- size crisis before we have sufficient deployment of IPng systems. In that case, if we adopt IPAE, we will have a backup solution in place. Yes, it will be a major chore to maintain the mapping tables, but if we come to that point, I assume we will be willing to perform that chore in order to keep the Internet alive. I think that this is exactly backward. If we deploy IPAE, then we will have major severe dependencies between IP and IPng, which implies that we will not be able to do anything about extending the life of IP without making sure that it is compatible with IPAE and IPng. Those mapping tables are likely to be a *lot* worse than other things that we could have done to extend IP, if only we didn't have those dependencies. In fact, based on previous actual experience with similar (though simpler) transitions, my guess is that folks will go ahead and deploy extensions to IP, regardless of whether they are compatible with IPAE or not. For example, folks may deploy IP-only NAT boxes at the boundaries between their site and the outside world, as well as IPAE mappings inside their site. This is likely to lead to an inconsistency with IPAE, unless the NAT boxes get updated to also do IPng. This sort of problem can result in networks being backed into transition corners from which there is no obvious way out. > ...IPAE's signficant difference over other transition schemes remains > its ability to support multiple IPv4 uniqueness regions once IPv4 > addresses are no longer globally unique. I don't think that property is unique to IPAE -- any of the proposed schemes can provide that capability. What IPAE provides is that capability *without* having to keep an IPv4 stack on your IPng systems indefinitely. Agree with Steve's first point here: Any scheme allows IPv4 uniqueness regions once IPv4 addresses are no longer unique. > ... SIP started as close to IPv4 as possible (quite a reasonable starting > point) but now that variable length addresses have actually become accepted, Well, there's still at least one hold-out for fixed-length (64-bits, in fact) addresses -- me. SIPP happens to support variable-length addressing through use of the Routing Header, but I consider that observation as something to increase the comfort level of the address-space claustrophobes, not something we'd ever really need to use. (The real value of the Routing Header is for other functionality, such as provider-selection.) There is a difference between handling larger addresses in an awkward but workable way in case we ever need them, versus handling larger and/or variable addresses in a way which is inherent to the protocol stack. I think that which we do depends upon whether larger (than 64 bit) addresses are insurance, or a central part of the protocol. It would be desireable to look at the addressing plans in more detail and figure out which we are doing. > ... Forwarding across SIP extended address spaces requires a circular > rewrite to get the next address element into the header, and this is not > going to pipeline easily in anyone's hardware. If we never go to extended addresses, that won't be a issue. And if we do, the effect occurs only at major boundaries (not at every or even most hops), where performance is probably already being sacrificed for things like firewall filtering. Why do we need a circular re-write? Why not list the FULL address in the extended header, with only the next 64-bit address to use in the regular SIPP header? Ross From rcallon@wellfleet.com Mon Jan 31 11:02:45 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA07509 for ; Mon, 31 Jan 1994 10:55:57 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25074; Mon, 31 Jan 94 10:43:02 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA07770; Mon, 31 Jan 94 10:52:41 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA18746; Mon, 31 Jan 94 11:02:45 EST Date: Mon, 31 Jan 94 11:02:45 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401311602.AA18746@cabernet.wellfleet> To: jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: ipng@cmf.nrl.navy.mil -------- ] From: Ross Callon ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Wed, 26 Jan 94 19:39:49 EST ] ... ] My expectation is that when there are too many systems for IP addresses ] to be globally unique, then folks will continue to use and deploy IP ] systems, but the bulk of the systems will have local IP addresses (only ] a few systems will have globally unique IP addresses -- I think that it ] is more believable that some global IP connectivity will continue to be ] useful for a long while for some systems, rather than that *all* IP use ] will become local). ] ] This implies that after IP ceases to have globally-sufficient addresses, ] new sytems, in most cases, will have globally unique IPng addresses, and ] local IPv4 addresses. This implies that such new systems will talk globally ] with all IPng systems, and talk locally with local IPv4 systems. A few ] systems will be able to have globally significant IPv4 and IPng addresses. One sites' "local IPv4 address" is another sites "globally-unique" address?? In the absence of clear guidance from the transition documentation, this is clearly the case. In the absence of clear guidance from the IPng directorate, and/or the IESG, then (i) folks will deploy local addresses anyway; and (ii) the problem that you describe will occur. This implies that we should get our act together and (i) get the IANA to assign some specific addresses for local use (at least a class A), and (ii) put together a document which describes how to use the local addresses, and the implications thereof. In 2003, the system administrator for foo.com unpacks 2 new computer systems. Host A is assigned the last address in foo.com's address range. The admin calls and says: "I need one more, what should I do?" I tell him: "You should start using LOCALLY-unique IP addresses." He then assigns his new system the address "192.32.180.26" (picked totally out of thin air) and begins telling his 1000 hosts abut this new address space for routing purposes. Such fun. Meanwhile, down the hall in foo.com, someone starts swearing at the network. His communication with Ross Callon (the "true owner" of 192.32.180.26) has suddenly stopped. Ross, working at ABC Corp., suddenly finds that he can no longer talk to anyone at FOO, due to their address selection. The entire thing takes about 2 weeks realtime to resolve, and the estimate for lost time for all involved comes to slightly under $35K. Ross, when you write the dual-stack paper, would you specify where these local addresses come from? If there is going to be a reserved address space for this purpose, we need to document such interesting topics as how sites handle DNS for the local address space and the use of overlapping IPv4 netowrks on the local network. Perhaps dual-stack is viable, under the right administrative circumstances. We need documentation on this as soon as possible. If you're advocating something other than a reserved set of networks for this purpose (i.e. IPv4 uniqueness within scopes shared between sites) then how we get from one unique space to _one space with multiple uniqueness scopes_ needs to be described. Needless to say, the same type of information is desperately needed in order to evaluate transition ala IPAE. I don't think that we should put all of this in one paper, any more than all of the description of the IP network layer is in one paper. I think that we should *right now* publish an Internet Draft or RFC on local IP addresses. Ross From jcurran@nic.near.net Mon Jan 31 11:10:29 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA07623 for ; Mon, 31 Jan 1994 11:09:14 -0500 Message-Id: <199401311609.LAA07623@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa05469; 31 Jan 94 11:11 EST To: Ross Callon cc: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Mon, 31 Jan 1994 10:56:08 -0500. <9401311556.AA18724@cabernet.wellfleet> Date: Mon, 31 Jan 1994 11:10:29 -0500 From: John Curran -------- ] From: Ross Callon ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Mon, 31 Jan 94 10:56:08 EST ] ] Why do we need a circular re-write? Why not list the FULL address in the ] extended header, with only the next 64-bit address to use in the regular ] SIPP header? I don't believe carrying forward information in a pipeline is not nearly as problematic as delaying forwarding for subsequent information. (i.e. I'm not sure that having the full address in the extended header will make a significant difference as long as the regular destination has to be changed.) It would be best to ask a hardware designer. /John From brian@dxcoms.cern.ch Mon Jan 31 17:14:41 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA07657 for ; Mon, 31 Jan 1994 11:12:49 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11929; Mon, 31 Jan 1994 17:14:41 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09244; Mon, 31 Jan 1994 17:14:41 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401311614.AA09244@dxcoms.cern.ch> Subject: a proposal (fwd) To: ipng@cmf.nrl.navy.mil Date: Mon, 31 Jan 1994 17:14:41 +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: 5573 Just in case other IPng people have not seen this. I sent Yakov the stuff I circulated a few weeks ago with the name "PINNs". Brian >--------- Text sent by yakov@watson.ibm.com follows: From: yakov@watson.ibm.com Message-Id: <199401281810.NAA27711@merit.edu> Date: Fri, 28 Jan 94 13:09:27 EST To: regional-techs@merit.edu Cc: 0003858921@mcimail.com Subject: a proposal Folks, Appended is a proposal on address allocation for private internets. It was drafted by myself and Bob Moskowitz (Chrysler Corp.). Yakov & Bob. P.S. The proposal incorporates comments that we received from several people. The Acknowledgement section will be added to reflect their contributions. --------------------------------cut here-------------------------------- Address Allocation for Private Internets Hosts within sites that use IP can be partitioned into three categories: - hosts that do not require Internet access - hosts that need access to a limited set of Internet services (e.g. E-mail, FTP, netnews, remote login) which can be handled by application layer relays - hosts that need unlimited access (provided via IP connectivity) to the Internet Hosts within the first category may use IP addresses that are unambiguous within a site, but may be ambiguous within the Internet. For many hosts in the second category an unrestricted Internet access (provided via IP connectivity) may be more than just unnecessary -- it may be undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within a site, but may be ambiguous within the Internet. Only hosts in the last category require IP addresses that are unambiguous within the Internet. It is common for organizations to build private internets which have little or no hosts falling into the third category. Even if an organization has a mixed category of hosts, in many cases within the organization hosts in the first and the second category are interconnected in such a way as to disable their IP level connectivity to the Internet, and hosts in the third category are segregated into a separate segment(s) of topology (separate Link Layer subnetwork). Only these segments need to have IP level connectivity to the Internet. Even if the hosts in the third category are not segregated into a separate physical segment of topology, such hosts can be segregated on a common (with the hosts in the first or the second category) physical segment of topology by assigning two distinct subnetwork numbers to the segment. To conserve IP network address space utilization for the public Internet, hosts within private internets that fall into the first or the second category may take their addresses out of the specific IP address block to be used exclusively by such hosts. The size of the block is expected to be sufficient to accommodate most or all of the practical situations. The reserved block consists of three sub-blocks: a single Class A network number (X), 8 contiguous Class B network numbers (from Y to Z), and 255 contiguous Class C network number (from W to V). For sites with fewer than 1,000 hosts we suggest to use addresses out of the sub-block of Class C network numbers. For sites with more than 10,000 hosts we suggest to use addresses out of the Class A network number. For all other sites we suggest to use addresses out of the sub-block of Class B network numbers. Of course, it is also possible for a site to use addresses out of more than one sub-block (using a mix of Class A, B, and C network numbers) An organization that uses addresses out of the pool allocated for private networks can be more liberal in terms of address space utilization, as compared to the address space utilization of the Internet-visible address space. Thus, rather than using variable-length subnettting, a site may use fixed-length subnetting. In many cases use of Class C network numbers may be helpful to avoid dealing with IP subnetting altogether. The reserved IP address block will not be routed in the Internet. Routers in the Internet are expected to be configured to reject (filter out) Network Layer Reachability Information associated with the destinations identified by the address block. If a router receives such information the rejection shall not be treated as a routing protocol error. Since within a single internet IP addresses have to be unambigous, assigning IP addresses out of the block allocated for private internets has the following implications: - when a host that is taken its IP address from the block moves from the first or the second category into the third one, the host has to change its IP address. - if several previously unconnected sites (several private internets) that have hosts numbered out of the block decide to interconnect (merge their internets into a single internet), this may require changing addresses of the hosts. Since the IP addresses within the block will not be routed in the Internet, a host that takes its IP address from the block will be unreachable (at the network layer) from any host in the Internet. That offers additional firewall protection. With the proposed scheme many large corporate sites can use a relatively small block of addresses from the global IP address space. That would benefit the Internet by conserving the use of IP address space. From rcallon@wellfleet.com Mon Jan 31 11:18:06 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA07642 for ; Mon, 31 Jan 1994 11:11:20 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25280; Mon, 31 Jan 94 10:58:23 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08155; Mon, 31 Jan 94 11:08:02 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA18770; Mon, 31 Jan 94 11:18:06 EST Date: Mon, 31 Jan 94 11:18:06 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401311618.AA18770@cabernet.wellfleet> To: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future I've been remembering the first time I ever discussed DECnet Phase V with an Important Person (IP:-) from DEC. It was my perception then (1985?) that this was all going to be very difficult, and that an easy though messy thing would be a maintenance release of DECnet Phase IV where 16 bit addresses were changed to 32 bits. Yep, the APIs would change, but in a very simple way. Lousy, boring software mods. Yawn. Cost a few million dollars. Boy, do I wish they had taken that lousy, boring approach! So if we are in the end going to "just migrate to this new address format" then there is an easy, messy, lousy, boring approach, isn't there? Totally agree. I don't know if it is really all that messy, but it is boring and straightforward. > Sorry to rave, > /John > No need to apologise Brian With the intention only of learning from the past (not beating a sore horse): Having observed closely both DECnet Ph 5 and OSI design, the number one lesson from both efforts should be to avoid very complex designs in which every part of the design is heavily dependent upon other parts of the design. Thus, if you *have* to make a complex design, it is *much* more likely to work if the overall design can be split up into multiple independent parts, each of which can be designed and deployed independently from the other parts. Thus, for example, the use of local addresses for IP, other means for extending the life of IPv4, and the migration from IPv4 to IPng, are all more likely to work if they are not heavily co- dependent in complex ways. Ross From sob@hsdndev.harvard.edu Mon Jan 31 11:34:48 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA07823 for ; Mon, 31 Jan 1994 11:32:46 -0500 Date: Mon, 31 Jan 94 11:34:48 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9401311634.AA04939@hsdndev.harvard.edu> To: Greg_Minshall@Novell.COM, ipng@cmf.nrl.navy.mil Subject: Re: telechat yesterday... Greg, well, come to think of it that may be a clean way to look at IPAE - so we are talking about the degree not the existance of NATs? Scott From ericf@atc.boeing.com Mon Jan 31 09:04:13 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08169 for ; Mon, 31 Jan 1994 12:00:45 -0500 Received: by atc.boeing.com (5.57) id AA20320; Mon, 31 Jan 94 09:04:13 -0800 Date: Mon, 31 Jan 94 09:04:13 -0800 From: Eric Fleischman Message-Id: <9401311704.AA20320@atc.boeing.com> To: jcurran@nic.near.net, rcallon@wellfleet.com Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: ipng@cmf.nrl.navy.mil Dear John, The "local addresses" which Ross and I are advocating for IPv4 are reserved unallocated addresses. In the "users view of IPng" IPng white paper which I have written (and which is currently undergoing comment within Boeing) I suggest 12 contiguous Class B addresses to be used for that purpose. Sincerely yours, --Eric Fleischman From deering@parc.xerox.com Mon Jan 31 09:54:43 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08700 for ; Mon, 31 Jan 1994 12:53:11 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14591(4)>; Mon, 31 Jan 1994 09:54:51 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 31 Jan 1994 09:54:45 -0800 To: rcallon@wellfleet.com (Ross Callon) Cc: ipng@cmf.nrl.navy.mil Cc: deering@parc.xerox.com Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: rcallon's message of Mon, 31 Jan 94 07:56:08 -0800. <9401311556.AA18724@cabernet.wellfleet> Date: Mon, 31 Jan 1994 09:54:43 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan31.095445pst.12171@skylark.parc.xerox.com> > I think that this is exactly backward. If we deploy IPAE, then we will > have major severe dependencies between IP and IPng, which implies that > we will not be able to do anything about extending the life of IP > without making sure that it is compatible with IPAE and IPng. Those > mapping tables are likely to be a *lot* worse than other things that we > could have done to extend IP, if only we didn't have those dependencies. I'm sorry Ross, but that just sounds like a lot of handwaving to me. Please be specific about what "major severe dependencies" you forsee, and what those "other things we could have done to extend IP" are, so that we can judge for ourselves how much worse IPAE would be. > Why do we need a circular re-write? Why not list the FULL address in the > extended header, with only the next 64-bit address to use in the regular > SIPP header? Because that would steal another 8 bytes from the useable payload. Steve From deering@parc.xerox.com Mon Jan 31 10:26:39 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA09023 for ; Mon, 31 Jan 1994 13:25:14 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14523(7)>; Mon, 31 Jan 1994 10:26:54 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 31 Jan 1994 10:26:50 -0800 To: ipng@cmf.nrl.navy.mil Subject: Re: telechat yesterday... Date: Mon, 31 Jan 1994 10:26:39 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan31.102650pst.12171@skylark.parc.xerox.com> > First off, i think that part of IPAE is, basically, a NAT box (it just > happens to be NATting between two different internet protocols). I disagree. The address mapping function of IPAE does address *extension*, not address translation. I.e., it does not translate an address x into an address y, but rather extends x to p.x, where p is some prefix that is a function of x. Embedded in Robert's inflamatory message of last week, was the request that we distinguish between *packet* translation and *address* translation. I would agree with that, with the additional request that we distinguish between address *extension* and address *translation*. I think the transition proposals can be characterized as follows: NAT - address translation CATNIP - packet translation, address extension with a constant SIPP/IPAE - packet translation, address extension with f(address) TUBA - none of the above Steve From deering@parc.xerox.com Mon Jan 31 10:54:41 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA09369 for ; Mon, 31 Jan 1994 13:53:07 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14613(5)>; Mon, 31 Jan 1994 10:54:57 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 31 Jan 1994 10:54:52 -0800 To: ipng@cmf.nrl.navy.mil Cc: deering@parc.xerox.com Subject: IPAE Date: Mon, 31 Jan 1994 10:54:41 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan31.105452pst.12171@skylark.parc.xerox.com> Fellow Directorate Members, I suggest that people who have criticisms, concerns, or questions about IPAE raise them on the SIPP list, where there are people more expert than me and more responsible than me in responding to email, and where the discussion is open to all participants, not just the Chosen of the Directorate. Steve From rcallon@wellfleet.com Mon Jan 31 14:03:01 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA09391 for ; Mon, 31 Jan 1994 13:56:18 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26528; Mon, 31 Jan 94 13:43:18 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA11189; Mon, 31 Jan 94 13:52:57 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA18888; Mon, 31 Jan 94 14:03:01 EST Date: Mon, 31 Jan 94 14:03:01 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401311903.AA18888@cabernet.wellfleet> To: deering@parc.xerox.com Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: ipng@cmf.nrl.navy.mil > I think that this is exactly backward. If we deploy IPAE, then we will > have major severe dependencies between IP and IPng, which implies that > we will not be able to do anything about extending the life of IP > without making sure that it is compatible with IPAE and IPng. Those > mapping tables are likely to be a *lot* worse than other things that we > could have done to extend IP, if only we didn't have those dependencies. I'm sorry Ross, but that just sounds like a lot of handwaving to me. Please be specific about what "major severe dependencies" you forsee, and what those "other things we could have done to extend IP" are, so that we can judge for ourselves how much worse IPAE would be. Steve; You can't expect the descriptions of the bugs to be any more precise than the spec which folks are trying to find the bugs in. Thus I am not going to be able to find precise detailed descriptions of the dependencies, bugs and/or holes unless and until I have a precise detailed description of the IPAE transition. Also, others have pointed out enough unworkable features in the current IPAE spec that I don't see much point in spending the time to document yet more bugs in it until we get an update which fixes the problems already pointed out. We have already been discussing a number of things that can be done to extend the life of IP, including CIDR, local addresses, Network Address Translation (NAT), address renumbering and reclamation, and use of application gateways for folks that only need Email and/or FTP access. There are probably other things that people will think of and deploy in the future. Some of these (eg CIDR) will "obviously" work fine with IPAE. Others (NAT) will need to interact in ways which I have not seen or heard discussed. Regarding NAT and IPAE: If you have mapping tables which map from IP address to IPng address (inherent to IPAE), and the IP address changes in different parts of the Internet in ways which depend upon transient address assignments (which are inherent in NAT), then you are going to have to have time-dependent and location-dependent changes in your IP to IPng address mapping tables. A reasonable way to deploy NAT is to put the IP address mapping at the boundaries between organizations. This implies that SIPP translation will occur on both sides of the NAT translations. I haven't seen any description of how to do this, nor how to debug and manage your network while all of this is happening. Ross From rcallon@wellfleet.com Mon Jan 31 14:14:38 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA09535 for ; Mon, 31 Jan 1994 14:07:45 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26646; Mon, 31 Jan 94 13:54:55 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA11458; Mon, 31 Jan 94 14:04:34 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA18906; Mon, 31 Jan 94 14:14:38 EST Date: Mon, 31 Jan 94 14:14:38 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401311914.AA18906@cabernet.wellfleet> To: jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: ipng@cmf.nrl.navy.mil -------- ] From: Ross Callon ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Mon, 31 Jan 94 10:56:08 EST ] ] Why do we need a circular re-write? Why not list the FULL address in the ] extended header, with only the next 64-bit address to use in the regular ] SIPP header? I don't believe carrying forward information in a pipeline is not nearly as problematic as delaying forwarding for subsequent information. (i.e. I'm not sure that having the full address in the extended header will make a significant difference as long as the regular destination has to be changed.) It would be best to ask a hardware designer. John Okay, I wandered over to the next office and asked the local router hardware designer. He sort of sighed, muttered a lot of words that I would interpret as "there are relative degrees of pain, which effect router performance in varying amounts", and then said "...try to convince them not to do a circular shift of a variable number of address parts". It sounds like this is one of those things which makes performance harder to meet, which could be done better in other ways, but which we could do if necesssary. Ross From deering@parc.xerox.com Mon Jan 31 12:38:57 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA00236 for ; Mon, 31 Jan 1994 15:45:01 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14681(7)>; Mon, 31 Jan 1994 12:39:04 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 31 Jan 1994 12:38:59 -0800 To: rcallon@wellfleet.com (Ross Callon) Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: rcallon's message of Mon, 31 Jan 94 11:14:38 -0800. <9401311914.AA18906@cabernet.wellfleet> Date: Mon, 31 Jan 1994 12:38:57 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan31.123859pst.12171@skylark.parc.xerox.com> > Okay, I wandered over to the next office and asked the local router > hardware designer. He...then said "...try to convince them not to do a > circular shift of a variable number of address parts". Good, we're not doing that. Processing the SIPP Routing header entails swapping two fixed-size (64-bit) addresses. I agree that swapping variable-length things would be awful. Steve From rcallon@wellfleet.com Mon Jan 31 15:58:01 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id PAA00426 for ; Mon, 31 Jan 1994 15:52:00 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27542; Mon, 31 Jan 94 15:38:17 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA13397; Mon, 31 Jan 94 15:47:56 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA18966; Mon, 31 Jan 94 15:58:01 EST Date: Mon, 31 Jan 94 15:58:01 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401312058.AA18966@cabernet.wellfleet> To: deering@parc.xerox.com Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: ipng@cmf.nrl.navy.mil > Okay, I wandered over to the next office and asked the local router > hardware designer. He...then said "...try to convince them not to do a > circular shift of a variable number of address parts". Good, we're not doing that. Processing the SIPP Routing header entails swapping two fixed-size (64-bit) addresses. I agree that swapping variable-length things would be awful. Steve; Sounds good. There are actually three possibilities: - Swapping things that are variable length. Very bad. Not likely to be a SIPP issue given that SIPP addresses are fixed at 64 bits. - Swapping a variable number of fixed length things (possibly in some sort of circular shift of fixed length address components). Intermediate badness. - Swapping two fixed sized things. Better still. Our hardware/systems guy (or one of our 3 or 4 top hardware guys, actually) definitely preferred the third approach (swapping two addresses at a time) over the second (circular shift of a variable number of fixed length addresses). Ross From Greg_Minshall@Novell.COM Mon Jan 31 16:46:18 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA02326 for ; Mon, 31 Jan 1994 19:50:09 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA13632; Mon, 31 Jan 94 17:56:44 MST Received: from [130.57.64.149] by WC.Novell.COM (4.1/SMI-4.1) id AA09973; Mon, 31 Jan 94 16:46:19 PST Date: Mon, 31 Jan 94 16:46:18 PST Message-Id: <9402010046.AA09973@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: John Curran From: Greg Minshall Subject: Re: CLNP is it good enough for the future Cc: ipng@cmf.nrl.navy.mil Look, folks... >As it turns out, we are driven to consider an IPng because of this >pressing need, but the chance to deploy a new network-layer Internet >protocol will only come once, so we should seriously consider exactly >what additional capabilities should be included. Note that IPng is >not simply about the _network_ layer, but it is about the architecture >of the entire Internet service suite. This will be the only chance we >have to adopt new TCP, service location, authentication, or other >capabilities into the _base_ set of IPng requirements. Capabilities >such as multicasting or authentication do not succeed unless the support >becomes an inherent aspect of IPng. We don't today know what additional capabilities "should be included". We will never know that. (We will, however, know quite painfully what "should *have been* included".) The real question is "how little can we put in such that a) it is fully functional, and b) doesn't constrain us overly in adding other things as we need them?". (Which is not to say we shouldn't say "we need multicasting; we need authentication". It is just to say that having something which includes a bunch of things and yet can evolve/revolute is also a worthwhile goal.) Greg From bound@zk3.dec.com Mon Jan 31 20:05:36 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA02499 for ; Mon, 31 Jan 1994 20:23:35 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA25719; Mon, 31 Jan 94 17:05:45 -0800 Received: by xirtlu.zk3.dec.com; id AA15457; Mon, 31 Jan 1994 20:05:42 -0500 Message-Id: <9402010105.AA15457@xirtlu.zk3.dec.com> To: Greg Minshall Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Brian's paper/Translation In-Reply-To: Your message of "Mon, 31 Jan 94 07:43:57 PST." <9401311543.AB06547@WC.Novell.COM> Date: Mon, 31 Jan 94 20:05:36 -0500 X-Mts: smtp Greg, that was bogus and bah a router is not even close to a host after the network layer. I got work to do on a host. /jim From Greg_Minshall@Novell.COM Mon Jan 31 17:21:36 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA02507 for ; Mon, 31 Jan 1994 20:25:33 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA15811; Mon, 31 Jan 94 18:32:02 MST Received: from [130.57.64.149] by WC.Novell.COM (4.1/SMI-4.1) id AA10089; Mon, 31 Jan 94 17:21:37 PST Date: Mon, 31 Jan 94 17:21:36 PST Message-Id: <9402010121.AA10089@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rcallon@wellfleet.com (Ross Callon), deering@parc.xerox.com, ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Ross, >I think that this is exactly backward. If we deploy IPAE, then we will >have major severe dependencies between IP and IPng, which implies that >we will not be able to do anything about extending the life of IP >without making sure that it is compatible with IPAE and IPng. Those >mapping tables are likely to be a *lot* worse than other things that we >could have done to extend IP, if only we didn't have those dependencies. In your mind, how is IPAE here any different than CATNIP? Greg From jcurran@nic.near.net Mon Jan 31 20:23:34 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA02485 for ; Mon, 31 Jan 1994 20:21:36 -0500 Message-Id: <199402010121.UAA02485@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa14455; 31 Jan 94 20:24 EST To: Greg Minshall cc: ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-reply-to: Your message of Mon, 31 Jan 1994 16:46:18 -0800. <9402010046.AA09973@WC.Novell.COM> Date: Mon, 31 Jan 1994 20:23:34 -0500 From: John Curran -------- ] From: Greg Minshall ] Subject: Re: CLNP is it good enough for the future ] Date: Mon, 31 Jan 94 16:46:18 PST ] ] Look, folks... ] ] >As it turns out, we are driven to consider an IPng because of this ] >pressing need, but the chance to deploy a new network-layer Internet ] >protocol will only come once, so we should seriously consider exactly ] >what additional capabilities should be included. Note that IPng is ] >not simply about the _network_ layer, but it is about the architecture ] >of the entire Internet service suite. This will be the only chance we ] >have to adopt new TCP, service location, authentication, or other ] >capabilities into the _base_ set of IPng requirements. Capabilities ] >such as multicasting or authentication do not succeed unless the support ] >becomes an inherent aspect of IPng. ] ] We don't today know what additional capabilities "should be included". We ] will never know that. (We will, however, know quite painfully what "should ] *have been* included".) ] ] The real question is "how little can we put in such that a) it is fully ] functional, and b) doesn't constrain us overly in adding other things as we ] need them?". ] ] (Which is not to say we shouldn't say "we need multicasting; we need ] authentication". It is just to say that having something which includes a ] bunch of things and yet can evolve/revolute is also a worthwhile goal.) Greg, How do you intend to pursuade folks to upgrade to IPng? Presuming that we follow your model, and end up with a fully-functional and expandable IPng protocol, with the minimum in new capabilities (i.e. none), please explain why Harvard, NRL, or Boeing would bother to deploy IPng at all? /John From Greg_Minshall@Novell.COM Mon Jan 31 17:29:53 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA02530 for ; Mon, 31 Jan 1994 20:33:45 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16214; Mon, 31 Jan 94 18:40:21 MST Received: from [130.57.64.149] by WC.Novell.COM (4.1/SMI-4.1) id AA10119; Mon, 31 Jan 94 17:29:55 PST Date: Mon, 31 Jan 94 17:29:53 PST Message-Id: <9402010129.AA10119@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: John Curran From: Greg Minshall Subject: Re: CLNP is it good enough for the future Cc: ipng@cmf.nrl.navy.mil John, > How do you intend to pursuade folks to upgrade to IPng? Presuming that >we follow your model, and end up with a fully-functional and expandable IPng >protocol, with the minimum in new capabilities (i.e. none), please explain >why Harvard, NRL, or Boeing would bother to deploy IPng at all? As long as people are happy with IPv4 (including whatever price providers charge them for its use), i see *NO REASON* to try to persuade them to upgrade to IPng. If over some period of time they see a benefit to IPng (universal connectivity, $$$, easier installation/management, whatever), then they will migrate. Greg From Greg_Minshall@Novell.COM Mon Jan 31 17:30:02 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA02532 for ; Mon, 31 Jan 1994 20:33:50 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16217; Mon, 31 Jan 94 18:40:27 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB10119; Mon, 31 Jan 94 17:30:02 PST Date: Mon, 31 Jan 94 17:30:02 PST Message-Id: <9402010130.AB10119@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: Brian's paper/Translation Cc: ipng@cmf.nrl.navy.mil Jim, >that was bogus and bah a router is not even close to a host after the >network layer. But wait, there's more! A "host" != "BSD networking code". Some "hosts" (maybe Mac's, PCs, etc.) may look more like the insides of a cisco, wellfleet, whatever, router than they do a BSD kernel. In some cases, it may be that one host looks more like one router than like another host. What i am objecting to are statements of the form "a host looks like this: X", for various X, since i think that different hosts look very different. Greg From jcurran@nic.near.net Mon Jan 31 20:46:10 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA02559 for ; Mon, 31 Jan 1994 20:44:11 -0500 Message-Id: <199402010144.UAA02559@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa16147; 31 Jan 94 20:46 EST To: Greg Minshall cc: ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-reply-to: Your message of Mon, 31 Jan 1994 17:29:53 -0800. <9402010129.AA10119@WC.Novell.COM> Date: Mon, 31 Jan 1994 20:46:10 -0500 From: John Curran -------- ] From: Greg Minshall ] Subject: Re: CLNP is it good enough for the future ] Date: Mon, 31 Jan 94 17:29:53 PST ] ] John, ] ] > How do you intend to pursuade folks to upgrade to IPng? Presuming that ] >we follow your model, and end up with a fully-functional and expandable IPng ] >protocol, with the minimum in new capabilities (i.e. none), please explain ] >why Harvard, NRL, or Boeing would bother to deploy IPng at all? ] ] As long as people are happy with IPv4 (including whatever price providers ] charge them for its use), i see *NO REASON* to try to persuade them to ] upgrade to IPng. If over some period of time they see a benefit to IPng ] (universal connectivity, $$$, easier installation/management, whatever), ] then they will migrate. I agree that people will migrate if there are real benefits. I must admit that I never even considered taking a position that we should not be encouraging such migration, and had simply assumed otherwise. /John From bound@zk3.dec.com Mon Jan 31 22:07:52 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA02971 for ; Mon, 31 Jan 1994 22:15:06 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA28794; Mon, 31 Jan 94 19:07:59 -0800 Received: by xirtlu.zk3.dec.com; id AA17114; Mon, 31 Jan 1994 22:07:58 -0500 Message-Id: <9402010307.AA17114@xirtlu.zk3.dec.com> To: Robert_Ullmann.LOTUS@CRD.lotus.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-Reply-To: Your message of "Mon, 31 Jan 94 07:29:58 EST." <9401311229.AA13876@Mail.Lotus.com> Date: Mon, 31 Jan 94 22:07:52 -0500 X-Mts: smtp Rob, >IPAE does this by encapsulating the datagram in a new "transport layer", >while CATNIP moves the extra addressing into an IP option. WHAT. I am beginning to question if you have read IPAE in depth and just hacking at the strategy. What transport layer. I can't parse this?? Also please be specfic with black holes? Where and please define your interpretation of black holes. I am honestly trying to understand but I have to say all I hear is handwaving around IPAE. Maybe it should be taken to the SIPP list because we cannot get people to just say technically or architecturally what is wrong with IPAE. I raise this as an objection to this process and its unfair to the engineers who built and architected IPAE. I am going to start hitting the 'd' key on this kind of mail. Also the tone of some of these messages as far as I am concerned is OUT OF LINE. I am not putting up with it. I will react to anymore mail like this by sending it to my UNIX )--->/dev/null file. /jim From bound@zk3.dec.com Mon Jan 31 22:40:24 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA03526 for ; Mon, 31 Jan 1994 22:46:36 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA29814; Mon, 31 Jan 94 19:40:32 -0800 Received: by xirtlu.zk3.dec.com; id AA17367; Mon, 31 Jan 1994 22:40:30 -0500 Message-Id: <9402010340.AA17367@xirtlu.zk3.dec.com> To: Greg Minshall Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Brian's paper/Translation In-Reply-To: Your message of "Mon, 31 Jan 94 17:30:02 PST." <9402010130.AB10119@WC.Novell.COM> Date: Mon, 31 Jan 94 22:40:24 -0500 X-Mts: smtp Greg, >But wait, there's more! A "host" != "BSD networking code". Some "hosts" >(maybe Mac's, PCs, etc.) may look more like the insides of a cisco, >wellfleet, whatever, router than they do a BSD kernel. In some cases, it >may be that one host looks more like one router than like another host. >What i am objecting to are statements of the form "a host looks like this: >X", for various X, since i think that different hosts look very different. I see your point. My point is that most all public domain code for IPng at this point is a derivative of BSD not that its exactly BSD. I could tell you horror stories about engineers who parted from BSD code base and at first with their minimal designs and functionality were just fine. But then when they began doing things like NFS, GateD, and on PC type machines too. Having ported custom features for TCP and UDP across several UNIX boxes and several PC comm cards in the past I could not have had what is known as a common engineering code base had it not been for BSD implementation. I also happen to like the extra features I get in the UNIX OS kernel but that has nothing to do with networking. You have convinced me though to stop working on my Host White Paper its too early, I could do nothing more than propose requirements without giving away trade secrets so to speak based on the prototype work. This would be viewed as biased and right now I am not really up to the flame mail I have seen on this mailing list and really don't feel like putting up with it anymore. Thats about as nice as I can say it. Also I spent time with our routing architects and we each have different problems to solve (Host vs Router). For the Host we also get to do BIND Servers/Reslovers, Network Management Stations, Translators (yes I am convinced we need to build them no matter who wins), and a Host is faced with mucho installed base of applications that must keep on ticking. If you bothered to realize this, it is why I am staying with AF_INET because I will break less. Whereever I can break less I will and thats an implementation business choice not and IETF decision. I guess it depends on who your customer is that spends the most money with you too. Oh and right now IPAE has the best solution to solve the IPv4 to IPng ONLY system problem too in my opinion. /jim From bound@zk3.dec.com Mon Jan 31 22:46:50 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA03659 for ; Mon, 31 Jan 1994 22:51:32 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA00339; Mon, 31 Jan 94 19:46:57 -0800 Received: by xirtlu.zk3.dec.com; id AA17426; Mon, 31 Jan 1994 22:46:56 -0500 Message-Id: <9402010346.AA17426@xirtlu.zk3.dec.com> To: John Curran Cc: Greg Minshall , ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: CLNP is it good enough for the future In-Reply-To: Your message of "Mon, 31 Jan 94 20:46:10 EST." <199402010144.UAA02559@picard.cmf.nrl.navy.mil> Date: Mon, 31 Jan 94 22:46:50 -0500 X-Mts: smtp I think we need to encourage migration. BECAUSE THEY ARE GOING TO RUN OUT OF ADDRESS SPACE on the Internet. Also I am sure all of us in our companies are dealing with NII and GII? I am and these customers and this opportunity requires for sure Multicast, policy based routing, and Flow IDs to name a few. My customers are ready for the next generation of networking potential becuase of something we don't talk about in the IETF world. APPLICATIONS MOVING TO A DISTRIBUTED COMPUTING MODEL. Yes soon NFS will run very well over backbones and in fact I use it that way today and it works fine. Next will be DCE and ONC. Yes the RPC will work on a backbone. And also folks are going to want their message queueing applications and transation processing systems to use policy based routing and Flow IDs. I support encouragement of migration, because I support my customers. /jim From bound@zk3.dec.com Mon Jan 31 23:02:35 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA03874 for ; Mon, 31 Jan 1994 23:06:08 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA01018; Mon, 31 Jan 94 20:02:42 -0800 Received: by xirtlu.zk3.dec.com; id AA17759; Mon, 31 Jan 1994 23:02:41 -0500 Message-Id: <9402010402.AA17759@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: cable tv came through!! In-Reply-To: Your message of "Sat, 29 Jan 94 11:23:51 EST." <9401291623.AA24193@hsdndev.harvard.edu> Date: Mon, 31 Jan 94 23:02:35 -0500 X-Mts: smtp WOW.. That was pretty clear to me and also one of my customers. Not only did they encourage migration but also stated we must consider the future in our IPng selection. That was a good one in my opinion. /jim From jallard@microsoft.com Mon Jan 31 23:07:15 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA05465 for ; Tue, 1 Feb 1994 02:07:24 -0500 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA23703; Mon, 31 Jan 94 23:10:28 -0800 Message-Id: <9402010710.AA23703@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 31 Jan 94 23:10:28 PST To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: AF_IPNG Date: Mon, 31 Jan 94 23:07:15 >>On a Host most OSI implementations are under the AF_ISO comm domain. The >>IP is under the AF_INET domain. I figure the best way right now is to >>implement IPng under AF_INET domain where the infrastructure will change >>the least. > >I think that overloading AF_INET with IPng stuff is probably a mistake. >Probably AF_WHATEVER, or some such, with the socket *actually* getting >bound at connect() or bind() time. (Sorry, APIs again.) i second the motion. using the mbz area of the sockaddr_in is sheer badness, esp with pc implementations. under windows nt for example, we allow 3rd parties to extend our sockets interface w/o src, but only w/ different addr families. an implementation as you describe abv would require single vendor support for ipv4 and ipng on the same system in a dual stack config. pls don't. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 From bound@zk3.dec.com Mon Jan 31 23:14:04 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA04324 for ; Mon, 31 Jan 1994 23:27:46 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA01312; Mon, 31 Jan 94 20:14:11 -0800 Received: by xirtlu.zk3.dec.com; id AA17826; Mon, 31 Jan 1994 23:14:10 -0500 Message-Id: <9402010414.AA17826@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: another white paper In-Reply-To: Your message of "Sun, 30 Jan 94 09:22:26 EST." <9401301422.AA18094@hsdndev.harvard.edu> Date: Mon, 31 Jan 94 23:14:04 -0500 X-Mts: smtp WOW WOW.. Two in a row with similar requirements. Same on what I am hearing at my end in the market. Are we maybe getting our requirements. A business techno person who does not work for Digital told me that IPng could generate an easy multi-billion dollar global business because of the information revolution. But it will have to have some very good planning for the technology to make it happen, and clearly must evolve past the status quo of IP. It should be done even if the address space does not run out, just for the global economy. Not sure I agree but it was a different observation. /jim From jcurran@nic.near.net Mon Jan 31 23:20:26 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA04153 for ; Mon, 31 Jan 1994 23:17:51 -0500 Message-Id: <199402010417.XAA04153@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa25760; 31 Jan 94 23:20 EST To: bound@zk3.dec.com cc: Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-reply-to: Your message of Mon, 31 Jan 1994 22:07:52 -0500. <9402010307.AA17114@xirtlu.zk3.dec.com> Date: Mon, 31 Jan 1994 23:20:26 -0500 From: John Curran -------- ] From: bound@zk3.dec.com ] Subject: Re: Proposal history ] Date: Mon, 31 Jan 94 22:07:52 -0500 ] ... ] I am honestly trying to understand but I have to say all I hear is ] handwaving around IPAE. Maybe it should be taken to the SIPP list ] because we cannot get people to just say technically or architecturally ] what is wrong with IPAE. I raise this as an objection to this process ] and its unfair to the engineers who built and architected IPAE. Jim, I have tried to be very precise in my comments regarding IPAE. I will repeat them here: 1) I do not not believe that the mapping table and the proposed distribution mechanism for the same can actually be deployed in the Internet in a manner which will insure any degree of consistency. The mapping table require several times more coordination than currently exists between providers, and frankly, I'm skeptical that provider coordination could ever reach such a level without dramtically altering the cost structure of many Internet service providers to cover the necessary staff. Either the use of a single prefix for mapping, or the addition of a dynamic protocol to exchange this information could alleviate this problem. 2) Successful communication via IPAE introduces several factors (such as the contents of the relevent mapping tables and the connectivity type of the destination system) and consequently several new failure modes. End-to-end problem analysis in the current Internet is "challenging" and the introduction of new failure modes is very costly. In a suit before one IETF plenary, I noted that supporting IPAE will require significant retraining for network operation staffs. Neither SIP nor TUBA requires major retraining (the paradigm of end-to-end communication is unchanged) but both IPAE and NAT result in new models for communication which must be understood by operation and support staffs. While the addition of new failure modes cannot be avoided by any scheme providing transparent IPv4 to IPng connectivity, it can be minimized by the use of dual protocol support where ever possible (particularly among transit networks) and limited use of translators _only_ for the purposes of connecting known protocol "islands" to the rest of the Internet. Given that my concerns are entirely within the realm of "operations of _very_ large IPng networks", I can understand why many folks do not share them. One of the main reasons for IPng is to solve a problem ("IPv4 address depletion") which also lies within the realm of large Internet operation. It's important for the solution to be a net improvement over the original problem. /John p.s. Jim, this message is not cc'ed on the SIPP list, as it quotes from your message. Feel free to forward it if you'd like. From bound@zk3.dec.com Mon Jan 31 23:55:42 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA05053 for ; Mon, 31 Jan 1994 23:58:33 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA02245; Mon, 31 Jan 94 20:55:50 -0800 Received: by xirtlu.zk3.dec.com; id AA18338; Mon, 31 Jan 1994 23:55:48 -0500 Message-Id: <9402010455.AA18338@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-Reply-To: Your message of "Mon, 31 Jan 94 23:20:26 EST." <9402010420.AA01650@decvax.dec.com> Date: Mon, 31 Jan 94 23:55:42 -0500 X-Mts: smtp John, >I have tried to be very precise in my comments regarding IPAE. I will >repeat them here: OK............... you have been and I stayed out of it last time. But being one who is implementing IPAE I will give you my best answer on this round. Most have not been this clear. >1) I do not not believe that the mapping table and the proposed >distribution mechanism for the same can actually be deployed >in the Internet in a manner which will insure any degree of >consistency. The mapping table require several times more >coordination than currently exists between providers, and >frankly, I'm skeptical that provider coordination could ever >reach such a level without dramtically altering the cost >structure of many Internet service providers to cover the >necessary staff. >Either the use of a single prefix for mapping, or the addition of >a dynamic protocol to exchange this information could alleviate >this problem. We need to decide if it is a single prefix or not. I am not sure what you mean by dynamic protocol. But, if it is not a single prefix then this problem will exist for all proposals. With a single prefix the entire IPv4 address space is a simple mapping. What I can build for my customers with IPAE is very simple. Someone will define the prefixes for providers and intra-subscribers. I am assuming that with CIDR lessons learned we will use aggregation on some part of the chosen address space and solution. I will get those aggregates from an authoritarian site and build a translation mask and assign prefixes based on site determination. These could very well be a set of SIPP address sequences or initially a 64bit address, where the high order 32bits is the prefix. On a Host Server I can do this very fast and efficiently and build an IPAE translator. Why is this so hard to manage as opposed to subnets today within a Class A address. It just gets multiplied. For example: I get a DNS record in my application as follows: 1-111100000000-16.144.43.16 First I know its for an IPv4 system cause the c-bit is set. DNS records will need to add this. Do you think this is not possible? Second I just process it like anyother DNS record and send it out as the destination address. It enters the IPng SIPP transport accomodating 64bit addresses and goes on down to the integrated network layer module where the c-bit is checked. If its on its for IPv4. If its not in this site its sent to the next hop router. If that router has an IPv4 path to this destination with this prefix it is taken. If it must traverse SIPP domain then its encapsulated in a SIPP packet towards that prefix address. There may or may not be any translation take place. This can all be done on Host Gateways but it does not have to be, but on a Host you will have a managment interface from each vendor, which will also as today have a DNS interface. With autoconfiguration most of what you do now hopefully will be transparent if we do that correctly. In addition like a person from NASA stated during the SIPP / IPAE discussion. The reason I am for IPAE is that its the solution documented and we need what it is saying it can do. Of course IPAE is more than solving the above problem but entire transition plan of which this problem is just one. If we cannot use a single prefix then I agree its gets complicated and IPAE will work on my end. I see your point but its not clear to me as a provider what you think will not work. Is it the DNS update or starting the entries? We can't maintain the aggregates? We need an additional management interface for the network? We cannot coordinate a central place to ftp the aggregates? Others ???? >2) Successful communication via IPAE introduces several factors >(such as the contents of the relevent mapping tables and the >connectivity type of the destination system) and consequently >several new failure modes. End-to-end problem analysis in the >current Internet is "challenging" and the introduction of new >failure modes is very costly. In a suit before one IETF plenary, >I noted that supporting IPAE will require significant retraining >for network operation staffs. Neither SIP nor TUBA requires major >retraining (the paradigm of end-to-end communication is unchanged) >but both IPAE and NAT result in new models for communication which >must be understood by operation and support staffs. >While the addition of new failure modes cannot be avoided by any >scheme providing transparent IPv4 to IPng connectivity, it can be >minimized by the use of dual protocol support where ever possible >(particularly among transit networks) and limited use of translators >_only_ for the purposes of connecting known protocol "islands" to >the rest of the Internet. Yes new failure modes are created. But that is the cost if we do not have a single prefix for the IPv4 address space, whether we like it or not. The trick is to come up with a plan to solve that problem. Because many of us believe that all nodes having both protocols running separately until the world completely uses IPng is not realistic. > Given that my concerns are entirely within the realm of "operations of >_very_ large IPng networks", I can understand why many folks do not share >them. One of the main reasons for IPng is to solve a problem ("IPv4 address >depletion") which also lies within the realm of large Internet operation. It's >important for the solution to be a net improvement over the original problem. And we must solve this problem and if we don't we are not done. >p.s. Jim, this message is not cc'ed on the SIPP list, as it quotes from > your message. Feel free to forward it if you'd like. OK I will. /jim From brian@dxcoms.cern.ch Tue Feb 1 08:50:57 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA05547 for ; Tue, 1 Feb 1994 02:48:58 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06129; Tue, 1 Feb 1994 08:51:00 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27512; Tue, 1 Feb 1994 08:50:57 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402010750.AA27512@dxcoms.cern.ch> Subject: Re: telechat yesterday... To: ipng@cmf.nrl.navy.mil Date: Tue, 1 Feb 1994 08:50:57 +0100 (MET) In-Reply-To: <94Jan31.102650pst.12171@skylark.parc.xerox.com> from "Steve Deering" at Jan 31, 94 10:26:39 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: 511 >--------- Text sent by Steve Deering follows: ... > NAT - address translation > CATNIP - packet translation, address extension with a constant > SIPP/IPAE - packet translation, address extension with f(address) > TUBA - none of the above > Mark may care to comment, but TUBA permits translation with address extension (with f(service provider)). I agree that this is not an essential feature of TUBA transition but it has been implemented by Francis Dupont at INRIA (France). Brian From brian@dxcoms.cern.ch Tue Feb 1 08:58:42 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA05554 for ; Tue, 1 Feb 1994 02:56:35 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07265; Tue, 1 Feb 1994 08:58:43 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27795; Tue, 1 Feb 1994 08:58:42 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402010758.AA27795@dxcoms.cern.ch> Subject: Re: IPAE To: ipng@cmf.nrl.navy.mil Date: Tue, 1 Feb 1994 08:58:42 +0100 (MET) In-Reply-To: <94Jan31.105452pst.12171@skylark.parc.xerox.com> from "Steve Deering" at Jan 31, 94 10:54:41 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: 1041 >--------- Text sent by Steve Deering follows: > > Fellow Directorate Members, > > I suggest that people who have criticisms, concerns, or questions about > IPAE raise them on the SIPP list, where there are people more expert than > me and more responsible than me in responding to email, and where the > discussion is open to all participants, not just the Chosen of the > Directorate. It is beyond the time I can allocate to IPng to read all the mail on all the lists. I think it is quite appropriate to discuss feasibility/ applicability of IPAE (etc) on the ipng list. I agree that once it gets into bugs and modifications, it belongs on the SIPP (etc) list. John Curran and Ross seem to share the worry I have that IPAE transition is going to require just too much table maintenance for the number of human beings available. (I focussed on the C bit, but there is more to it than that obviously.) This is a general message to the SIPP team: get rid of anything that needs manual table/DNS maintenance. (Should be easy :-) Brian From jcurran@nic.near.net Tue Feb 1 07:31:08 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id HAA06031 for ; Tue, 1 Feb 1994 07:29:15 -0500 Message-Id: <199402011229.HAA06031@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa13641; 1 Feb 94 7:31 EST To: bound@zk3.dec.com cc: Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-reply-to: Your message of Mon, 31 Jan 1994 23:55:42 -0500. <9402010455.AA18338@xirtlu.zk3.dec.com> Date: Tue, 01 Feb 1994 07:31:08 -0500 From: John Curran -------- ] From: bound@zk3.dec.com ] Subject: Re: Proposal history ] Date: Mon, 31 Jan 94 23:55:42 -0500 ] ... ] Someone will define the prefixes for providers and intra-subscribers. ] I am assuming that with CIDR lessons learned we will use aggregation ] on some part of the chosen address space and solution. I will get those ] aggregates from an authoritarian site and build a translation mask and ] assign prefixes based on site determination. An authoritative site? One which has the ability to control SIPP prefixes such that they're hierachical and may be aggregated? You've just created an entity which maintains a IPv4->SIPP prefix table on behalf of the Internet as a whole, and the size of the table is approximately the same order of magnitude as the IPv4 routing table. Not that the current IPv4 routing table is barely manageable and while pieces of it (such as the NSFNET policy-routing db) are managed via configuration, this is becoming more and more difficult to maintain. Much of the current IPv4 routing is handled entirely via tagged prefix exchange using routing protocols such as BGP3 and BGP4. In this manner, each provider maintains their own portion of the routing table, and the routes propogate as needed. Given CIDR and the dramtic growth of the Internet, it is unlikely that a centrally-mananged IPv4->SIPP prefix table can be deployed with any chance of success. It would be similiar to reverting from DNS to host tables for IPng. ] Why is this so hard to manage as opposed to subnets today within a Class ] A address. It just gets multiplied. Today we have routing protocols to exchange such information with other providers. We have no protocol to tell our SIPP neighbors what our IPv4 to SIPP prefix table looks like. We don't use routing protocols becuase we like to use link bandwidth on update pdu's, we use routing protocols so that routing in IPv4 can scale. I've intentionally omitted several meta-issues such as routing security, database authentication on update requests, and the realities of new table deployment and the resulting histogram. Many of these could be worked around if sites didn't mind waiting a month or so so that their routing change (i.e. SIPP prefix change) could be validated and propogated as necessary. This will make provider changes _very_ interesting, with some datagrams following old tables and some following new for quite some time. Currently, we siwtch sites over to new providers over 15-30 minutes, and rely on dynamic routing to update the routing tables. The IPv4->SIPP prefix mapping table is a routing table, and deploying such without a dynamic routing support is inconceivable to me. ] ... ] Second I just process it like anyother DNS record and send it out as the ] destination address. It enters the IPng SIPP transport accomodating ] 64bit addresses and goes on down to the integrated network layer module ] where the c-bit is checked. ] ] If its on its for IPv4. If its not in this site its sent to the next ] hop router. If that router has an IPv4 path to this destination with ] this prefix it is taken. If it must traverse SIPP domain then its ] encapsulated in a SIPP packet towards that prefix address. There may or ] may not be any translation take place. How do you know _which_ SIPP prefix address should be used during the encapsulation? You look it up in a very large table? How often does this table get updated?? If my provider changed yesterday, does your table know about this change? ] If we cannot use a single prefix then I agree its gets complicated and ] IPAE will work on my end. I see your point but its not clear to me as a ] provider what you think will not work. ] ] Is it the DNS update or starting the entries? No. ] We can't maintain the aggregates? Correct. ] We need an additional management interface for the network? "An additional management interface?" No, I'd rather not have whatever this turns out to be... (unless, by chance, it happens to be a dynamic update protocol for mapping tables.) ] We cannot coordinate a central place to ftp the aggregates? Please... run your internal corporate network off a centralized ftpable host table (rather than DNS or NIS or directoray services) for a month or so, and then my concerns will be much clearer. /John p.s. Shall we move this entire thread off to the SIPP list? From Robert_Ullmann.LOTUS@CRD.lotus.com Tue Feb 1 08:19:44 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id IAA06169 for ; Tue, 1 Feb 1994 08:12:06 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA16107; Tue, 1 Feb 94 08:16:28 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA00204; Tue, 1 Feb 94 08:19:44 EST Date: Tue, 1 Feb 94 08:19:44 EST Message-Id: <9402011319.AA00204@Mail.Lotus.com> Received: by DniMail (v1.0); Tue Feb 1 08:19:42 1994 EDT To: CRD::unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: Proposal history > moi: >IPAE does this by encapsulating the datagram in a new "transport layer", >while CATNIP moves the extra addressing into an IP option. > Jim: > WHAT. I am beginning to question if you have read IPAE in depth and just > hacking at the strategy. What transport layer. I can't parse this?? Picture an IPv4 datagram arriving at a router that is configured to do protocol filtering. The router looks at the "Protocol" (transport layer protocol identifier) in the datagram, and says: "hmmm, TCP is 6, UDP is 17; I know these, I know what to do." Then an IPAE datagram arrives. What does it look like to the router? Answer: An unknown transport layer protocol. > Jim: > Also please be specfic with black holes? Where and please define your > interpretation of black holes. A datagram transmitted on a subnetwork interface with the expectation that it will be received that disappears because of a configuration mis-match or SNPOA change has fallen into a "black hole". I've never heard any other definition (within networking :-) > Jim: > I am honestly trying to understand but I have to say all I hear is > handwaving around IPAE. Maybe it should be taken to the SIPP list > because we cannot get people to just say technically or architecturally > what is wrong with IPAE. I raise this as an objection to this process > and its unfair to the engineers who built and architected IPAE. I'm sorry, I thought I was being very detailed. I was, of course, assuming close familarity with the protocols, such as the idea that an IPAE datagram is identified by a well known value of the TLPID. Maybe I should not skip wavecrest-to-wavecrest in the arguments, and add the intervening details, even if only reminding the reader of what is in the specs? It would be more coherent. I'll try to do better. ---- I think we all ought to be very careful to remember that our own inability to understand some point is a much more likely explanation than an attempt to try to obfuscate the issues. I am quite sure we are all trying to communicate. Remember Clarke's Law: Any sufficiently advanced Technology is indistinguishable from Magic. The first time I saw the DNS specification (for the DNS itself, not the possible uses of it for NAT-like mappings), I thought it was utterly impossible. In fact, it has problems, including the ones I was thinking of; but it proves to mostly work. ---- Of course, you have to also keep in mind Kallis's Corollary to Clarke's Law: Any sufficiently advanced Magic is indistinguishable from Technology. If you want to invoke DNS magic (or central file stores, etc) ask yourself this: How do you restart the Network after a crash? (Not a router or host crash; a *network* crash.) ----- Take the "draft-ietf-sip-ipae-transition" document, and (conceptually) delete all the refences to IPAE itself, keeping the IPv4<->SIPP translation. I think you will find the result is simper, complete, and suspiciously similar to TP/IX-CATNIP-IPv7. (please read section 8 of the CATNIP -02 draft.) Assume SIPP can operate directly on the compatibility addresses, and there are a couple of other details to tweak. Best Regards, Robert (please forgive the atrocious pun supra. thank you.) From bound@zk3.dec.com Tue Feb 1 10:22:03 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA01316 for ; Tue, 1 Feb 1994 10:23:58 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA27769; Tue, 1 Feb 94 07:22:11 -0800 Received: by xirtlu.zk3.dec.com; id AA04077; Tue, 1 Feb 1994 10:22:09 -0500 Message-Id: <9402011522.AA04077@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-Reply-To: Your message of "Tue, 01 Feb 94 07:31:08 EST." <9402011233.AA27658@decvax.dec.com> Date: Tue, 01 Feb 94 10:22:03 -0500 X-Mts: smtp John, I sent your mail to SIPP list. Most are off writing code is my guess but we can see if a response is generated. After reading your mail here is what I have deduced: ??? There is a question regarding the IPAE specification concerning the update of prefixes in a volatile address environment, and whether that functionality can be administratively implemented. ??? Fair ??? In the IPAE spec how this is administratively done is not specified. I am assuming it could be accomplished not that it would be easy or without great coordination and complexity, but it could be done. The reason this may not work I am hearing is because some may believe the Internet infrastructure and administration cannot pull this off ?? Its not an IPAE technical problem its a question whether it can be done? I think if we can hone in on this issue that would be good and positive and valid to feedback to IPAE spec. /jim From bound@zk3.dec.com Tue Feb 1 10:27:20 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA01374 for ; Tue, 1 Feb 1994 10:28:41 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA28161; Tue, 1 Feb 94 07:27:31 -0800 Received: by xirtlu.zk3.dec.com; id AA04356; Tue, 1 Feb 1994 10:27:26 -0500 Message-Id: <9402011527.AA04356@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-Reply-To: Your message of "Tue, 01 Feb 94 07:31:08 EST." <9402011233.AA27658@decvax.dec.com> Date: Tue, 01 Feb 94 10:27:20 -0500 X-Mts: smtp John, Also: of course I would not run my corporate network from FTP mapping tables I would use those tables to update DNS. I agree a dynamic protocol would have much benefit. As a bind client I have told my node to resolve all addresses with my bind server so it would be transparent to me. I agree if I started getting host unreachable or no such user at this address to often I would complain to my network manager. And if everyone complained all the t because of this I realize this would be horrible for network providers like yourself. I do see your issue and the customer problem if this is not done well. /jim From jcurran@nic.near.net Tue Feb 1 10:48:08 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA01614 for ; Tue, 1 Feb 1994 10:45:32 -0500 Message-Id: <199402011545.KAA01614@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa18742; 1 Feb 94 10:48 EST To: bound@zk3.dec.com cc: Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-reply-to: Your message of Tue, 01 Feb 1994 10:22:03 -0500. <9402011522.AA04077@xirtlu.zk3.dec.com> Date: Tue, 01 Feb 1994 10:48:08 -0500 From: John Curran -------- ] From: bound@zk3.dec.com ] Subject: Re: Proposal history ] Date: Tue, 01 Feb 94 10:22:03 -0500 ] ] John, ] ] I sent your mail to SIPP list. Most are off writing code is my guess ] but we can see if a response is generated. ] ] After reading your mail here is what I have deduced: ] ] ??? ] There is a question regarding the IPAE specification concerning the ] update of prefixes in a volatile address environment, and whether that ] functionality can be administratively implemented. ] ??? ] ] Fair ??? Seems like a fine summary. ] In the IPAE spec how this is administratively done is not specified. I ] am assuming it could be accomplished not that it would be easy or ] without great coordination and complexity, but it could be done. The ] reason this may not work I am hearing is because some may believe the ] Internet infrastructure and administration cannot pull this off ?? ] ] Its not an IPAE technical problem its a question whether it can be ] done? It's a question of the burden placed upon network operation and configuration _as a result_ of the technical choices made. Note that this has also direct impact on IPAE reliability, since the ability to configure implies the ability to misconfigure. Further, the _requirement_ to configure will result in a statistical model for correct network configuration. /John From Greg_Minshall@Novell.COM Tue Feb 1 08:10:52 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA02268 for ; Tue, 1 Feb 1994 11:14:40 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA03250; Tue, 1 Feb 94 09:21:22 MST Received: from [130.57.64.146] by WC.Novell.COM (4.1/SMI-4.1) id AA11326; Tue, 1 Feb 94 08:10:53 PST Date: Tue, 1 Feb 94 08:10:52 PST Message-Id: <9402011610.AA11326@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: Brian's paper/Translation Cc: ipng@cmf.nrl.navy.mil Jim, >You have convinced me though to stop working on my Host White Paper its >too early, I could do nothing more than propose requirements without >giving away trade secrets so to speak based on the prototype work. This >would be viewed as biased and right now I am not really up to the flame >mail I have seen on this mailing list and really don't feel like putting >up with it anymore. Thats about as nice as I can say it. I would love to see you do a white paper on "one host's perspective". I just don't think there is a unified Host perspective. I am certainly not trying to flame; i am trying to make a point. >Also I spent time with our routing architects and we each have different >problems to solve (Host vs Router). For the Host we also get to do >BIND Servers/Reslovers, Network Management Stations, Translators (yes I am >convinced we need to build them no matter who wins), and a Host is faced >with mucho installed base of applications that must keep on ticking. >If you bothered to realize this, it is why I am staying with AF_INET because >I will break less. AF_INET versus AF_WHATEVER is not, of course, all that germane to IPng the protocol. But, it is of interest since it would be nice if the programming interface looked the same all around. My assumption is that there would be an AF_INET which would plug into the "dual" stack through the IPv4 side (thus preserving ALL existing applications, at least for a while). I would guess there might be an AF_INETng or some such thing which would plug in via the IPng side. And, i would wish/hope/whatever that there would be a AF_WHATEVER which would accept *tagged* (as to internet protocol type) addresses and then cause the right thing to happen to either AF_INET or AF_INETng. You are right that the devil is in the details. So, trying to get all the ioctl()'s, etc., right is likely to be a real pain. But, socket(), close(), listen(), bind(), connect(), send(), receive() should all work. Greg ps - Actually, the silly API thing is a *REAL* issue, because just looking at sockets, if DEC does it one way, SUN does it another way, we do it a third way, Microsoft does it a fourth way, etc., it is going to be a royal pain. Unfortunately, the IETF has kept away from API issues, so *i* don't know any way to resolve this stuff. I guess the main hope is that there is an annointed, public domain, release of IPng which includes a full socket interface. From bound@zk3.dec.com Tue Feb 1 11:40:24 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA02735 for ; Tue, 1 Feb 1994 11:42:32 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA03994; Tue, 1 Feb 94 08:40:31 -0800 Received: by xirtlu.zk3.dec.com; id AA06335; Tue, 1 Feb 1994 11:40:30 -0500 Message-Id: <9402011640.AA06335@xirtlu.zk3.dec.com> To: Robert_Ullmann.LOTUS@CRD.lotus.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-Reply-To: Your message of "Tue, 01 Feb 94 08:19:44 EST." <9402011319.AA00204@Mail.Lotus.com> Date: Tue, 01 Feb 94 11:40:24 -0500 X-Mts: smtp > moi: >IPAE does this by encapsulating the datagram in a new "transport layer", >while CATNIP moves the extra addressing into an IP option. > Jim: > WHAT. I am beginning to question if you have read IPAE in depth and just > hacking at the strategy. What transport layer. I can't parse this?? >>Picture an IPv4 datagram arriving at a router that is configured >>to do protocol filtering. >>The router looks at the "Protocol" (transport layer protocol identifier) >>in the datagram, and says: "hmmm, TCP is 6, UDP is 17; I know these, >>I know what to do." >>Then an IPAE datagram arrives. What does it look like to the router? >>Answer: An unknown transport layer protocol. Its the proto ID in the network layer datagram and not a new transport layer, which is what I was objecting too. IPAE does not define a new transport layer was my point. If SIPP is in the proto ID then its an encapsulated SIPP packet in IPv4. Just forward it as an IPv4 packet once it encounters a SIPP router or SIPP host then the process of handling SIPP will be done. > Jim: > Also please be specfic with black holes? Where and please define your > interpretation of black holes. >>A datagram transmitted on a subnetwork interface with the expectation >>that it will be received that disappears because of a configuration >>mis-match or SNPOA change has fallen into a "black hole". >>I've never heard any other definition (within networking :-) Well fax me a copy of your dictionary where this is defined. And there are other reasons why a datagram may disappear. This is not the point though. My fault in the way I quickly phrased it. Where will a black hole result because of the IPAE spec? p.s. I have read all of your new spec. /jim From bound@zk3.dec.com Tue Feb 1 11:52:56 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA02908 for ; Tue, 1 Feb 1994 11:55:06 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA04875; Tue, 1 Feb 94 08:53:03 -0800 Received: by xirtlu.zk3.dec.com; id AA06634; Tue, 1 Feb 1994 11:53:02 -0500 Message-Id: <9402011653.AA06634@xirtlu.zk3.dec.com> To: jallard@microsoft.com Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: AF_IPNG In-Reply-To: Your message of "Mon, 31 Jan 94 23:07:15." <9402010710.AA23703@netmail2.microsoft.com> Date: Tue, 01 Feb 94 11:52:56 -0500 X-Mts: smtp >>>On a Host most OSI implementations are under the AF_ISO comm domain. The >>>IP is under the AF_INET domain. I figure the best way right now is to >>>implement IPng under AF_INET domain where the infrastructure will change >>>the least. >>I think that overloading AF_INET with IPng stuff is probably a mistake. >>Probably AF_WHATEVER, or some such, with the socket *actually* getting >>bound at connect() or bind() time. (Sorry, APIs again.) >i second the motion. using the mbz area of the sockaddr_in is sheer >badness, esp with pc implementations. under windows nt for example, we >allow 3rd parties to extend our sockets interface w/o src, but only w/ >different addr families. an implementation as you describe abv would >require single vendor support for ipv4 and ipng on the same system in a >dual stack config. pls don't. The sa_family attribute of a socket sets the communications domain. At this point I do not think the IETF should get into this API business or how router or host kernels configure their IPng stack. What is important for the IETF to accept as an engineering consideration and discuss is the effect of a new network layer protocol on existing applications infrastructure. If that new infrasructure requires changes to the transport interface then the degree of those changes can effect the amount of code that application developers have to deal with to move to IPng. All proposals will not be equal to solving this problem. Some may provide a way for IPv4 applications to maintain binary compatibility once the Transport Interface has changed, which could be construed as a benefit. I believe that we should not specify anything that forces a host vendor to have to support both IPv4 and IPng on the same machine. I am convinced though doing this is not a funtionality of the address family, but a function which network layer protocol is bound by the transport for connections. But this is an architecture implementation decision. /jim From bound@zk3.dec.com Tue Feb 1 12:02:11 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA03021 for ; Tue, 1 Feb 1994 12:04:05 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA05526; Tue, 1 Feb 94 09:02:18 -0800 Received: by xirtlu.zk3.dec.com; id AA06879; Tue, 1 Feb 1994 12:02:17 -0500 Message-Id: <9402011702.AA06879@xirtlu.zk3.dec.com> To: Greg Minshall Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Brian's paper/Translation In-Reply-To: Your message of "Tue, 01 Feb 94 08:10:52 PST." <9402011610.AA11326@WC.Novell.COM> Date: Tue, 01 Feb 94 12:02:11 -0500 X-Mts: smtp Greg, Points are all valid. I hope we can have a common socket interface too or least propose one to X/Open or POSIX some day. On the White Paper there is no way to do this other than really just listing requirements and in addition each implementation of the network protocol will have a different effect on the host whether its SIPP, TUBA, or CATNIP. Hence, without some requirements I would be openning myself up to selecting that which I think is important for each proposal. I agree this would be a great paper but too much work on my end. But, once we can agree on the Directorate about some requirements then I can hone in on just those requirements and keep updating the paper as the requirments evolve. For example if we believe PMTU is important for all proposals and in addition fragmenation eventually goes away someday with IPng that has some design issues on the host. But if a proposal uses IPng encapsulated in IPv4 then I still have to write the fragmentation code for the IPng protocol because IPv4 still does fragmentation. I did have to build a list for Digital as to what are the perceived alterations for Hosts (unix, vms, pcs, etc..). Would that list be useful maybe as a discussion point? /jim From Greg_Minshall@Novell.COM Tue Feb 1 09:11:36 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA03168 for ; Tue, 1 Feb 1994 12:15:16 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA06698; Tue, 1 Feb 94 10:22:02 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB11553; Tue, 1 Feb 94 09:11:36 PST Date: Tue, 1 Feb 94 09:11:36 PST Message-Id: <9402011711.AB11553@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: Brian's paper/Translation Cc: ipng@cmf.nrl.navy.mil Jim, >I did have to build a list for Digital as to what are the perceived >alterations for Hosts (unix, vms, pcs, etc..). Would that list be >useful maybe as a discussion point? Quite possibly. Greg From Robert_Ullmann.LOTUS@CRD.lotus.com Tue Feb 1 12:28:15 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA03297 for ; Tue, 1 Feb 1994 12:20:36 -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 AA20129; Tue, 1 Feb 94 12:24:59 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA12624; Tue, 1 Feb 94 12:28:15 EST Date: Tue, 1 Feb 94 12:28:15 EST Message-Id: <9402011728.AA12624@Mail.Lotus.com> Received: by DniMail (v1.0); Tue Feb 1 12:28:13 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: Proposal history Jim. A typical "security" filter in a router at the edge of an organization that is operating on the protocol numbers will go something like this: (this is in the inbound direction) permit ICMP any permit TCP with dest port > 1024 permit TCP with dest port = 25 (incoming mail) permit UDP with dest port > 1024 permit UDP with dest port = 63 (domain system) DENY everything else This router, when given an IPAE datagram, will evaluate it as APPEARING (very heavy stress on that word!) to be a transport protocol not known to the router; the datagram will be discarded (black holed) (Note that I tried really hard to indicate that it was only in APPEARANCE by quoting "transport layer" in the original note.) Simply adding: permit IPAE any will disable the filter (allow an IPAE host to bypass it; from a security standpoint this is broken.) Doing better than that requires that the router become SIPP/IPAE knowledgeble (so it can look further into the packet) and this creates the undesireable deployment sequence constraint that I referred to. By contrast, TUBA, CATNIP, and direct SIPP<->IPv4 translation leave the transport protocol and port number in the positions expected by an unmodified IPv4 router. --- *most* organizations seem to have such filters in place, to one degree or another. Rob . From pvm@ISI.EDU Tue Feb 1 14:36:19 1994 Return-Path: pvm@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA07992 for ; Tue, 1 Feb 1994 17:34:19 -0500 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 1 Feb 1994 14:36:50 -0800 Message-Id: <199402012236.AA00104@zephyr.isi.edu> To: Greg Minshall Cc: ipng@cmf.nrl.navy.mil Reply-To: pvm@ISI.EDU Subject: Re: Brian's paper In-Reply-To: Your message of Tue, 01 Feb 1994 14:10:52 -0800. <9402012210.AB12382@WC.Novell.COM> Date: Tue, 01 Feb 94 14:36:19 PST From: Paul Mockapetris > > F) Smart DNS. > > > > It is clear that DNS has to get smarter. The dual stack requirement > > implies that DNS has to reply with both an IPv4 and IPng address for > > dual-stacked hosts, or with a single reply that encodes both. > > I *thought* (not being a DNS person) that this was how DNS worked. I.e., > that the client could say "if you find something, give me back this that > and the other kind of information". And/or(?) the server could > spontaneously give back things *it* thought were useful. There's always various issues like getting updated info and servers in place, but adding a new type and being able to retrieve it isn't rocket science, its easy. The harder part may be setting up an efficient [address, endpoint ID, whatever new term was invented today] to host name mapping, particularly for addresses that are really routes. Having said that it isn't a problem, there are various proposals that ask the DNS to behave in ways that are incompatible with its model. Not to pick on anyone here, but a long-forgotten X.400 mail routing proposal asked the DNS to change its case-insensitivity rules, and that might run into opposition, and should not be assumed. paul From brian@dxcoms.cern.ch Wed Feb 2 08:47:51 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA11036 for ; Wed, 2 Feb 1994 02:45:23 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23040; Wed, 2 Feb 1994 08:47:53 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16185; Wed, 2 Feb 1994 08:47:52 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9402020747.AA16185@dxcoms.cern.ch> Subject: Re: Brian's paper To: ipng@cmf.nrl.navy.mil Date: Wed, 2 Feb 1994 08:47:51 +0100 (MET) In-Reply-To: <9402012210.AB12382@WC.Novell.COM> from "Greg Minshall" at Feb 1, 94 02:10:52 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1756 Greg, >--------- Text sent by Greg Minshall follows: > > Herewith, some actual thoughts/ramblings on Brian's paper... ... > >ATM > > > > The networking industry is investing heavily in ATM. No IPng proposal > > will be plausible (in the sense of gaining management approval) > > unless it is "ATM compatible", i.e. there is a clear model of how it > > will run over an ATM network. A document equivalent to the imminent > > "Classical IP and ARP over ATM LANs" RFC is needed. > > This isn't really a comment (of mine) about ATM, but about which documents > *need* to be written before an IPng proposal can be considered "complete > for review". I would suggest that for everything we think is "key" (ICMP, > multicast, ARP, etc.), if the way to acheive that function follows the same > model in IPng as in IPv4 (some troff macro or some such mechanical > translation), and if no one (directorate or otherwise) is saying "No! I > don't think that will actually *work* with this IPng proposal", THEN THERE > SHOULD BE NO NEED TO WRITE THE DOCUMENT EARLY IN THE PROCESS. All those > documents should, in my humble opinion, be written *AFTER* "we" have > selected "the" IPng. (I just don't think there is any need to create loads > of makework as pro-forma hurdles for people to jump over.) > The reason I made a special point of ATM is that given the level of industry hype, I am convinced that corporate management will look for "ATM compatibility" as a vital characteristic. I agree with you that there is no point in doing the detailed work too soon; it is quite sufficient to say that the IPoverATM models apply equally to IPng, if it is true. (For example, RFC 1577 relies on an ARP server model - does this work for IPng?) Brian From ericf@atc.boeing.com Wed Feb 2 01:23:38 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id EAA11462 for ; Wed, 2 Feb 1994 04:19:43 -0500 Received: by atc.boeing.com (5.57) id AA21274; Wed, 2 Feb 94 01:23:38 -0800 Date: Wed, 2 Feb 94 01:23:38 -0800 From: Eric Fleischman Message-Id: <9402020923.AA21274@atc.boeing.com> To: Greg_Minshall@Novell.COM, bound@zk3.dec.com Subject: Re: Brian's paper/Translation Cc: ipng@cmf.nrl.navy.mil In regards to Greg Minshall's comment that "Unfortunately, the IETF has kept away from API issues, ..." concerning preserving the current API interfaces within IPng: Greg is, of course, entirely correct. However, we cannot afford "business as usual". If Sockets and XTI cannot be preserved -- or at least consistently redefined with a very small delta -- then that will be a *VERY BIG* strike against IPng. This is a very important transition point which cannot be shirked: we must have existing user-written code be readily portable to an IPng environment if IPng is going to fly. Sincerely yours, --Eric Fleischman