From owner-Big-Internet@munnari.oz.au Thu Apr 1 06:54:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07844; Thu, 1 Apr 1993 06:54:38 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07839; Thu, 1 Apr 1993 06:54:31 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA12953; Wed, 31 Mar 93 12:54:19 -0800 Message-Id: <9303312054.AA12953@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 29 Mar 93 15:12:46 -0500. <9303292012.AA09253@ginger.lcs.mit.edu> Date: Wed, 31 Mar 93 12:54:19 -0800 From: Dave Crocker X-Mts: smtp Noel, About 8 years ago, I got quite confused about the terms "virtual circuit" and "packet switching", too. The productive outcome of that was some very clear definitions: ---- Included message: Perhaps the problem lies with mismatched definitions of "virtual circuit"; I don't think developing one everyone can agree with is a useful goal, but perhaps you could tell me if your definition differs from mine, which is *roughly*: - i) the only service model offered to the user is a circuit setup - ii) critical state is stored in the network - iii) the burden of reliable delivery is borne by the network substrate, not the end-points X.25 has packet aspects and circuit aspects. Packet swtiching has to do with chunking data and routing it according to information that is contained in each chunk. Circuit switching has to do with prior establishment of the path to be taken, so that the data that travels the path contains reference to the path info, rather than simply specifying the destination. Hence, Circuit Switching is not mutually exclusive of Packet Switching. Please also note that reliability was not mentioned. There is a common myth, for example, that X.25 provides end-to-end reliability. While it does have reliability services, they vary greatly. In fact, the X.25 RESET is their way of declaring that the level of attempted reliability just got exceeded. TCP, for example, has no such escape hatch. Further, the nature of the data buffering in X.25 switches varies. In the old Arpanet, the message was held in the originating IMP until the final IMP declared the message delivered. Hence, there was end-to-end (at the IMP level) buffering, as well as hop by hop. X.25 switches have that feature only as an option, since it is expensive in buffering.) A circuit-switched service with no reliability is entirely plausible (and was, in fact, one of the characteristics I was told about in the original frame relay/ATM-category of services.) Of course, none of this has anything to do with using EID's, as far as I can tell. D/ So does POTS, if you look inside the network, what with stat muxes, etc. However, by the measures I used above, X.25 is pretty much on the VC end of things. So does Frame Relay. All that distinguishes ATM is it's fixed cell siz e. Frame relay is roughly contemporaneous with ATM, and seems to have many of the same properties. (I forget whether it is reliable or not; I seem to recall that it isn't.) I didn't mean to exclude it; I gues I should have used "ATM/FR" every place I said "ATM" in the original note. Having dispensed with all these minor, surface, points, I don't see any deb ate about my basic argument; i.e. i) that the future belongs to "flows", at bot h the physical network layer as well as the internetwork, ii) if that's so, w e won't be "routing" each packet, and iii) if so, we don't need the "location " name in every packet. Could you please point out which of these steps is in error, and what is wr ong with it? Noel From owner-Big-Internet@munnari.oz.au Thu Apr 1 07:05:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08024; Thu, 1 Apr 1993 07:05:32 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08014; Thu, 1 Apr 1993 07:05:24 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA13003; Wed, 31 Mar 93 13:05:19 -0800 Message-Id: <9303312105.AA13003@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 29 Mar 93 09:26:31 -0500. <9303291426.AA06310@ginger.lcs.mit.edu> Date: Wed, 31 Mar 93 13:05:19 -0800 From: Dave Crocker X-Mts: smtp Noel, ---- Included message: I wish people would stop thinking that supporting mobile hosts is the reaso n for adding EID's. It's not, it's just an *example* of the *kind of thing* E ID's allow you to do. The next person who makes this error I am going to serious ly flame (so when it happens, don't say you weren't warned :-). Well, let's get this out of the way... For a thing to be useful, it's uses need to be understood. One approach to achieving that understanding is case analysis. This is particularly helpful when the thing is being offered for extremely general use. If none of the offered cases is demonstrated to be adequate, one is left to extrapolate a general lack of utility for the thing, unless and until some other example is offered which stands up to scrutiny. In this matter, I'm afraid, the burden of proof is on the side that is offering to impose extra overhead on the system. In other words, Noel, the EID constituency has tended to claim the need for EID's for a set of reasons. As nearly as I can tell, there are strongly plausible (i.e., adequate) alternatives that solve each case, without the use of EIDs. Unless some "killer application" for EIDs is forthcoming, then one is left to conclude that they are an appealing idea which would impose significant computational and communication and management overhead and which are not ESSENTIAL to increased performance, scaling, etc. The ball iss in your court. Dave From owner-big-internet@munnari.oz.au Thu Apr 1 18:27:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08147; Thu, 1 Apr 1993 18:27:50 +1000 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17171; Thu, 1 Apr 1993 11:16:44 +1000 (from kre@munnari.OZ.AU) To: Dave Crocker Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... In-Reply-To: Your message of "Wed, 31 Mar 1993 13:05:19 PST." <9303312105.AA13003@Mordor.Stanford.EDU> Date: Thu, 01 Apr 1993 11:16:32 +1000 Message-Id: <8040.733626992@munnari.OZ.AU> From: Robert Elz Date: Wed, 31 Mar 93 13:05:19 -0800 From: Dave Crocker Message-ID: <9303312105.AA13003@Mordor.Stanford.EDU> For a thing to be useful, it's uses need to be understood. I would agree with that. But its possible for something to be potentially useful without having any demonstrated current known uses, it can just show lots of potential. That's what I (and I think others) believe EIDs have - lots of potential. In this kind of case we need to look at the likely costs of adding the potential good, and weigh those against the possible benefits - the costs here are pretty clear I think... appealing idea which would impose significant computational and communication and management overhead which is reasonable - I'd actually say *insignificant* computational overhead (just what does writing one extra 64 bit field in a packet cost computationally? DNS lookups are being done anyway, an extra field in the answer is no big problem.) Certainly the packet headers will be a bit bigger, how much will depend on just what the protocol is that carries the EID, but for the EID itself we can say 64 bits. Management is the big one - that is the one real drawback with the extra level of naming, the real test will be to see if we can find some offsetting mangement benefit to counteract this. Fortunately, we can start with some zero (or something) extended form of an IP address for an EID, so there's no big startup management cost, just the incremental cost of having one more thing to look after. Potential uses... well, I will mention mobile hosts, not because I think they're a very important potential use, but because of ... As nearly as I can tell, there are strongly plausible (i.e., adequate) alternatives that solve each case, Personally, I see the mobile host "solutions" as totally inadequate - ingenious yes, probably the only way to work at all in IPv4, but still very very ugly. They appeared the way they did because of the constraints imposed by IPv4. No-one (no-one at all) ever responded to an earlier message where I explicitly asked for anyone who believed that the way the proposals were written would be the way they would be written if there was an open slate to start with. They're reasonable for local area motion, and absurd for long term frequent long distance motion. The adequate solution in this case is kind of like if someone has found a way to keep the leaning tower (in Pisa) from falling down (I have no idea if there is a solution or not yet), and then architects in the future claiming that they don't need to burdened with providing supports for buildings, as should one show signs of falling down the leaning tower solution can always be applied - there is an adequate alternative. But there are better uses for EIDs - one is the one I mentioned the other day, that using something other than net level addresses for the TCP pseudo-header checksum allows different IP level protocols, along with different addressing schemes to be used without needing to fiddle TCP yet again. This allows reasonable IP-layer (net layer) translation gateways to operate to allow the old to interoperate with the new, without imposing any constraints at all on the new - and will help prepare for possible revolutions in the way the net layer actually works. An even better application of EIDs is to allow easy renumbering of networks (entire regions, not just hosts or sites). Mobile hosts come out of this as an accidental, but useful, side effect, not as the driving force. There seem to be two problems with dynamic renumbering -- how to make sure other hosts know the new number, and how to reconfigure all the hosts that are being altered. The first of those is a non-problem, the DNS does this already, addresses change all the time without preventing major problems (better DNS implementations would reduce the ones that do occur). The only issue left is timeliness, how quickly the new info will propogate, which also isn't an issue for net renumbering (it may be more so for mobile hosts), the old address can simply be left in place long enough for old DNS cache information to fade away (a week or two, a meaningless extra burden when compared with what can be gained by altering addressing to match shifting topology). The other half is currently the real problem - there's no good way to update all the hosts, even less to do it dynamically without breaking connections that are established (and will remain established even after the old addresses have faded away from the DNS and have stopped being advertised). If mass renumbering is to be possible, and I think its something we should aim for, we have to solve this problem. EIDs provide much of the solution, with them, existing connections don't care what address they're using - all that's needed is a mechanism to tell the transport level to go look up the address again (see TUNE for one way that could be done). Further, once the applications don't care what addresses they're using, the hosts don't care either - sure they need to find an address to put in the packets (or some of them if Noel's architecture was to be adopted someday) but that's just a transitory knowledge needed for long enough to construct the packets, and which can easily be obtained again from the DNS if lost, but that's all they need. Note they don't need any knowledge whatever of their own address, only their peer needs that one, which means there doesn't need to be anything to reconfigure in the hosts at all in order to change their address, they don't know it - the packet's source address, assuming there is one, can be constructed dynamically (and yes I know there are ideas from PIP in here). This I think is the potential management win that more than offsets the cost of having to manage one extra identifier per endpoint. I don't know if any of this counts as your "killer application" or whether someone else can perhaps think of one - but nor do I much care, I don't believe that "prove this is useful or we ignore it" is the best approach, its a very easy way to keep the status quo until cataclysmic change is required when its suddenly realised that things have broken badly, even though no-one was ever able to prove that some suggested change was essential, but its not the way to promote graceful evolution, which is a much gentler way to plan for the future. That basically means trying out new mutations to see if they help, or if they prove useful for survival. Some will succeed, some will fail, and perhaps leave vestigal baggage to carry around for a long time. This shouldn't be seen as a needless waste of resources, but rather as being part of the cost that must be bourn in order to keep the network functioning in an environment that's changing. Further, there aren't many opportunities with the current structure to make evolutionary changes, most attempts have no chance of success because of the weight of inertia against them. The change we soon have to make to the net layer, and consequently to the TCP/net-layer interface now is an opportunity too good to miss to provide some small support for the kinds of evolutionary change that the net will continue to need into the future, and avoid the need for another radical disruptive change in the future. The potential for gain is immense, the costs are really pretty low (if EIDs turn out to be useless, their management costs can be put aside and ignored, someone may even find a use for what would be some basically useless bytes in the packet headers). Another analogy... ignoring EIDsEven better would be like ignoring someone telling you that there's gold lying on the ground just a mile over that way - the cost to go see if its true is pretty small, you can believe that there is no evidence the gold is really there, avoid ever paying that cost, and never really know if you missed anything or not. Or you can go look - you might just encounter a goldmine. kre From owner-Big-Internet@munnari.oz.au Fri Apr 2 00:29:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20895; Fri, 2 Apr 1993 00:29:29 +1000 (from owner-Big-Internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20891; Fri, 2 Apr 1993 00:29:14 +1000 (from teldoc@itu.arcom.ch) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA21174; Thu, 1 Apr 93 09:30:42 -0500 Date: Thu, 1 Apr 93 09:30:42 -0500 Message-Id: <9304011430.AA21174@worldlink.worldlink.com> From: David Piscitello To: big-internet@munnari.oz.au Subject: New Project Proposal This is to inform you that a New Project proposal has been accepted by the CCITT: Question VII/64 - Use of Simple Internet Protocol (SIP) to provide the connectionless network service (replacement protocol for CCITT X.233-1992, (also ISO/IEC 8473, 1993). (Note: consistent with acronyms currently associated with the OSI network layer, the protocol shall hereafter be recognized by the CCITT as S-CLNP) Proposed based text may be obtained electronically from the ITU repository by sending an email request to "teldoc@itu.arcom.ch" with subject line of "VII/64//SIP/proposedBaseText" In conjunction with this new proposal, ISO/IEC TR 9577, "Network layer protocol identification", will be amended as follows: 1) deprecate Inactive Network Layer Protocol identifier (00), assign to SIP 2) A new AFI (BCD 00) will be added to CCITT Recommendation X.231 ISO/IEC 8348-2, 1993, "OSI Network layer addressing" for SIP addresses See also the related New Project proposal: Question VII/69 - RIPu2, an intra-domain routeing exchange protocol for use in conjunction with SIP (S-CLNP) (Note: consistent with acronyms currently associated with the OSI network layer, the protocol shall hereafter be recognized by the CCITT as RIP-ISIS-2) (Internet email -- SMTP/822 only; sorry, no X.400 available at this time) From owner-big-internet@munnari.oz.au Fri Apr 2 02:30:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25528; Fri, 2 Apr 1993 02:30:11 +1000 (from owner-big-internet) Return-Path: Received: from [131.125.10.3] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23563; Fri, 2 Apr 1993 01:38:17 +1000 (from AL@TURBO.kean.edu) Received: from TURBO.Kean.EDU by squirt.kean.edu (4.1/SMI-4.1) id AA02090; Thu, 1 Apr 93 10:47:44 EST Message-Id: <9304011547.AA02090@squirt.kean.edu> Received: (from user AL) by TURBO.Kean.EDU; 01 Apr 93 10:40:18 EST To: big-internet@munnari.oz.au From: Al Costanzo Organization: Kean College of New Jersey Security: -- none -- Comment: Sender Phone# (908) 527-2061 Comment: Sender Fax# (908) 527-0391 Subject: address vs. EDI revisited Date: 01 Apr 93 10:40:18 EST Hmm. I really don't see why we need this naming space. RFC1154bis (yet to be released) handles EDIFACT and EDI-X12 as Encoded mail messages. We have be working with EDI services provides to make this task look seemless. As long as you are able to read and send mail and that mailer comforms to the spec. all will be fine. Regards Al Costanzo PS: Please send flames and other interesting remarks directly to me at this email address Regards. From owner-Big-Internet@munnari.oz.au Fri Apr 2 04:29:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29680; Fri, 2 Apr 1993 04:29:16 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29676; Fri, 2 Apr 1993 04:29:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11574; Thu, 1 Apr 93 13:28:52 -0500 Date: Thu, 1 Apr 93 13:28:52 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304011828.AA11574@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the side that is offering to impose extra overhead on the system. Clarification: do you think there is going to be extra overhead in the processing of normal user data packets, or are you just referring to the management costs and other overhead of another name space? there are strongly plausible (i.e., adequate) alternatives that solve each case.... Unless some "killer application" for EIDs is forthcoming.. As a general argument, proving that other mechanisms *can* do something is not very powerful to me. If it were, all our computers would have the instruction set of the minimal Turing machine! :-) In studying and thinking about system design, I find that the further you drag some mechanism away from its designed use, the less well it does the extra things. Sure, you can beat it into doing them, but eventually the pain level is real high. Sure, you can sort of make other things do what EID's do, but it gets more and more painful over time. The ball iss in your court. The question to me, with EID's, is "are they going to be sufficiently useful, going forward as the system grows and evolves into doing things *we cannot yet forsee*, to make the cost of adding them worth it"? Since this question implicitly includes things we don't know, there can't be a definitive answer. As such, it is a matter of judgement, and yours clearly does not match mine. I just don't think I can give a better answer than the one I have given in the past: "Endpoints seem to me to be a fundamental object in networking. I think that we need a namespace for them, with a guaranteed one-one mapping from names to endpoints. I conclude this based upon analysis of past system designs, and the reasons they failed; correct and accurate naming of fundamental objects is a necessary attribute of a successful, long-lived system. At a lower level, I think that the name ought to be one which can be put in every packet, i.e. a fixed length shortish binary string. I conclude this since I think we ought to have an identifier of the endpoint in each packet, and I think addresses (i.e. the names of network interfaces) are both a) the wrong thing to have in packets, and b) will become too long and complex to put in each packet (for overhead reasons)." If this doesn't satisfy you, I am berift of suggestions on how to satisfy you, and suggest we try and agree to disagree in a productive fashion. I don't think there's any way to reach agreement, short of time and experience with both possible answers. (No, pistols at 20 paces at dawn is *not an option! :-) Noel From owner-big-internet@munnari.oz.au Fri Apr 2 05:06:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01125; Fri, 2 Apr 1993 05:06:58 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27880; Fri, 2 Apr 1993 03:36:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11383; Thu, 1 Apr 93 12:36:29 -0500 Date: Thu, 1 Apr 93 12:36:29 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304011736.AA11383@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Packet swtiching has to do with chunking data and routing it according to information that is contained in each chunk. Circuit switching has to do with prior establishment of the path to be taken, so that the data that travels the path contains reference to the path info, rather than simply specifying the destination. When I first read this, I thought we were OK, but the more I thought about it, the more it seems all our definitions are skeewack. I'm not trying to be difficult ("Oh right", I'll bet you're thinking! :-), but unless we have agreed terminology, we're never going to get anywhere. The first one points out the salient characteristic of "packet switching"; viz, it is done on packets, not a continuous data stream. (I use "datagram" interchangably with "packet".) To me, packet switching simply means the data comes in chunks, which you switch through ("forward") based on information in the chunks, be it a circuit ID, the destination address, whatever. However, by "routing it", do you mean "making a decision on where to send this packet" or simply "forwarding"? If the former, I think it's too restrictive. Likewise, the second doesn't capture what I then of when I think of "circuit switching", since I apply that term to continuous streams; i.e. the inverse of packet switching. Your definition seems to be a definition of a particular style of making the routing decision component of forwarding; i.e. some prior decision has been made about the path this stream of data is to take, and state about that stream has been stored in the network. We need a term for this (maybe "setup routing"?) The real problem here is the word "routing". It has too many damn meanings (just like "address")! It seems to mean: i) the process of sending packets through a router (I'd like to see the term "forwarding" used exclusively for this, please) ii) the process of making a decision about which path user data should follow, whether that decision is made a) in one place or several ("source" vs "distributed" routing), or b) once, or for each packet (and we don't have terms for these - maybe "setup" and "per packet" would do). Note that a) and b) are pretty much orthagonal: - "source" and "per packet" -> IP Strict Source Route option - "source" and "setup" -> flow setup - "distributed" and "per packet" -> current basic IP model (is this what we mean by "hop-by-hop"?) - "distributed" and "setup" -> distributed flow setup iii) The process of the routers interchanging data on where things are, via routing protocols. Hence, Circuit Switching is not mutually exclusive of Packet Switching. This only makes sense if I take "Circuit Switching" to mean "setup routing" and "Packet Switching" means "the data comes in chunks, which you forward based on information in the chunks". Is this what you meant? Please also note that reliability was not mentioned. Ah, yes, we never did get to defining "virtual circuit"! To me, virtual circuit doesn't mean a single thing, but rather a system with a number of (admittedly orthagonal) characteristics. It's not a pure datagram *service* (I don't care much what's *inside* the X.25/whatever switches), since there is a circuit setup. The routing (at the X.121 level) is sort of "source" and "setup", using the terms above. It also means various decisions along the reliability and resource allocation axes, which are also orthagonal to each other (and the two routing axes). So, what is a "virtual circuit"? Good question, but it's pretty safe to say that it's a system which has made *different* decisions along each of these axes from the TCP/IP model (whatever class that is an example of :-). I will note that the common thread among almost all of these axes is "how much state is stored in the network". TCP/IP deliberately attempted to store as little state in the network as possible (in reaction to a number of systems, including both X.25 and the ARPANet, which stored a lot). In hindsight, perhaps that was wrong; it seems that doing some things needed more state in the network, something we probably didn't fully understand in 1977. We now seem to be working toward a model where we don't store any *critical* state in the nework, which I think is probably the right approach. There is a common myth, for example, that X.25 provides end-to-end reliability. While it does have reliability services, they vary greatly. I assume you are referring to the fact that the X.25 checksums do not cover the data from the source application to the destination, yes? It does attempt to provide more reliability than IP does; whether or not it's *useful* reliability is a different argument! Of course, none of this has anything to do with using EID's, as far as I can tell. True! I was just attempting to describe my vision of the future, and why EID's made sense in that future, and we tripped up on some of the terms I used to describe that future. Noel From owner-Big-Internet@munnari.oz.au Fri Apr 2 05:25:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01813; Fri, 2 Apr 1993 05:25:13 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01810; Fri, 2 Apr 1993 05:25:04 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA03852; Thu, 1 Apr 93 11:24:52 -0800 Message-Id: <9304011924.AA03852@Mordor.Stanford.EDU> To: Al Costanzo Cc: big-internet@munnari.oz.au Subject: Re: address vs. EDI revisited Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of 01 Apr 93 10:40:18 -0500. <9304011547.AA02090@squirt.kean.edu> Date: Thu, 01 Apr 93 11:24:51 -0800 From: Dave Crocker X-Mts: smtp Al, Are you referring to an "EDI" discussion or the "EID" discussion? d/ From owner-big-internet@munnari.oz.au Fri Apr 2 07:43:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07180; Fri, 2 Apr 1993 07:43:18 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01701; Fri, 2 Apr 1993 05:21:39 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA03717; Thu, 1 Apr 93 11:21:25 -0800 Message-Id: <9304011921.AA03717@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 01 Apr 93 13:28:52 -0500. <9304011828.AA11574@ginger.lcs.mit.edu> Date: Thu, 01 Apr 93 11:21:25 -0800 From: Dave Crocker X-Mts: smtp Noel, ---- Included message: Clarification: do you think there is going to be extra overhead in the processing of normal user data packets, or are you just referring to the management costs and other overhead of another name space? I was making as general a comment as possible. Extra mechanism means extra work. I think we should not waste bandwidth, shouldn't waste administrative effort, shouldn't make management more complicated, etc., without very good cause. Robert Elz suggests that EIDs simply seem like a good idea, even if we can't think of concrete, required uses for them, now. My own sense of Internet experience is that features work best when we have a very good idea why we need them and how they are going to be used. When we try to be farsighted, but don't anchor the sight in present need, we seem to do less well. The SNMPv1 security field is a classic example of the problem. there are strongly plausible (i.e., adequate) alternatives that solve e ach case.... Unless some "killer application" for EIDs is forthcoming.. As a general argument, proving that other mechanisms *can* do something is not very powerful to me. If it were, all our computers would have the instructi on set of the minimal Turing machine! :-) Noel, I used the word "adequate" intentionally. I'm not trying to get into the detailed comparison between each possible use of EIDs and each possible alternative to their use. I will note, in fact, that I haven't seen much of such critical analysis being done on this list. In particular, I haven't seen it from the EID constituency. The question to me, with EID's, is "are they going to be sufficiently usefu l, going forward as the system grows and evolves into doing things *we cannot yet forsee*, to make the cost of adding them worth it"? Since this question Noel, I definitely agree that this is the realm in which we are debating. My own, summary experience is that while our community contains many folk who are not only bright but creative, we have a lousy track record planning for the unknown. As I said above, when we get too far away from the immediate, concrete, understood need, we seem not to do very good work. When we take i/c/u/need and do a direct extrapolation, we tend to produce excellent work, which generalizes quite well. Hence, unless there are some killer applications for EIDs, they fall into the realm of vibes and good feeling, rather than engineering solutions for real problems. Being from California, I can get into the warm fuzzies of good feelings, but I don't confuse that activity with delivery-oriented engineering. "Endpoints seem to me to be a fundamental object in networking. I think t hat we need a namespace for them, with a guaranteed one-one mapping from name s to endpoints. I conclude this based upon analysis of past system designs, an I agree! But so far, domain names look like they serve the requirement just fine. At a lower level, I think that the name ought to be one which can be put in every packet, i.e. a fixed length shortish binary string. I conclude this Well, here is the point of departure. You state some beliefs and I believe the statements to be clear and to the point. What I keep failing to hear is a specification of the problems they solve and the ways they will solve them. My only "technical" reaction is to say that a packet which contains only a name and not an address has just placed a much higher burden on the routing software of the net. Not being an routing wizard (or even a routing competent) I'm entirely open to being wrong here. (Sure. I'm open to being wrong anytime. Right...) But this leaves the pedagogical requirement that EID proponents teach me (and others) about the technical basis for all of this. For warm fuzzies, I can wander down to Carmel. For Internet engineering, I need a vitamin infusion of concrete detailed justification. So, I agree that we have probably reached closure for this stage of discussion. Dave From owner-Big-Internet@munnari.oz.au Fri Apr 2 09:02:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10036; Fri, 2 Apr 1993 09:02:43 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304012302.10036@munnari.oz.au> Received: from TURBO.Kean.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10029; Fri, 2 Apr 1993 09:02:35 +1000 (from AL@TURBO.Kean.EDU) Received: (from user AL) by TURBO.Kean.EDU; 01 Apr 93 18:04:41 EST To: big-internet@munnari.oz.au From: Al Costanzo Organization: Kean College of New Jersey Security: -- none -- Comment: Sender Phone# (908) 527-2061 Comment: Sender Fax# (908) 527-0391 Subject: Opps! Date: 01 Apr 93 18:04:41 EST Yup, My mistake all! Thanks Dave. (Too much Ale at the IETF meeting I think for me... -al From owner-big-internet@munnari.oz.au Sat Apr 3 01:19:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21800; Sat, 3 Apr 1993 01:19:52 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19397; Sat, 3 Apr 1993 00:16:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18855; Fri, 2 Apr 93 09:15:53 -0500 Date: Fri, 2 Apr 93 09:15:53 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304021415.AA18855@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu My own sense of Internet experience is that features work best when we have a very good idea why we need them and how they are going to be used. When we try to be farsighted, but don't anchor the sight in present need, we seem to do less well. ... when we get too far away from the immediate, concrete, understood need, we seem not to do very good work. When we ... do a direct extrapolation, we tend to produce excellent work, which generalizes quite well. In general, I agree. What I have perhaps failed to make clear is that EID's are in fact a direct result of experience gained with the Internet. In other words, I reckon they exactly fit your bill of something where "we have a very good idea why we need them". On a number of issues, such as multi-homed hosts, dual-MAC interfaces, etc, etc extending over 15 years now (I have deliberately left out mobile hosts), we have been hampered by the fact that we did not separate out the name of the place the communicating entity is connected to the Internet (i.e. the interface "address") from the name of the communicating entity itself. They are *clearly* two very different things. The proposal to start naming the entities directly is a direct and simple response to this problem. But so far, domain names look like they serve the requirement just fine. No, they won't work, because we wish to distinguish between the concept of endpoint and interfaces *at the internetworking layer*. (I.e., effectively divide that layer into two sublayers.) I could make a legalistic argument and say that this alone make DNS names unsuitable since they don't belong to that layer, but that's clearly a cop-out. I could also complain that DNS names don't name endpoints, they just name DNS translation entries; you could attempt to administratively enforce a one-one binding from DNS names to endpoint, but I think we all know that with anything which is enforced that way (as opposed to being built into the protocols), people just ignore those restrictions. The form of a name is almost as important as what it names; the name is usually structured to make something you do with the name easier. DNS names are structured a) to be easy for humans to use, and b) to enable them to be looked up all the time in a distributed, hierarchically organized database; efficiency of use, and minimal size, are not a big concern. None of these are true for EID's. My only "technical" reaction is to say that a packet which contains only a [endpoint] name and not an address has just placed a much higher burden on the routing software of the net. For the 79th time, EID's contain *no* information about where the object is in the network, and you *do not* (cannot!) route upon them! Routing operates on addreses (of interfaces) as it always has. Interface addresses do not need to be in every packet of a flow, only those which need to be routed. I won't go back over the whole dissertation on which packets need to contain both, how and in what circumstances you need to translate between EID's and addresses, how we can interoperably introduce them, etc, etc. But this leaves the pedagogical requirement that EID proponents teach me (and others) about the technical basis for all of this. We've been going over this on this list for almost a year now, but apparently (based on your comment about routing packets with only an endpoint name in them) it hasn't helped. In the circumstances, I can only conclude that further effort won't be of any noticeable use. I don't expect further debate will change any minds. For warm fuzzies, What 'warm fuzzies'? EID's are a small, concrete step forward based on analysis of 15 years of problems with an operational, deployed system. Noel From owner-Big-Internet@munnari.oz.au Sat Apr 3 02:09:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23887; Sat, 3 Apr 1993 02:10:04 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23876; Sat, 3 Apr 1993 02:09:50 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA02149; Fri, 2 Apr 93 11:06:28 -0500 Date: Fri, 2 Apr 93 11:06:28 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9304021606.AA02149@er.doe.gov> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au From following this particular incarnation of this argument there seems to be several points of agreement. First some identifier of network endpoint is important which is different from the routing significant address. This enables change of topology and routing changes without perhaps touching all the hosts on the net. Depending on your point of view the domain name or some new EID would fill this need need. However, a single domain name can refer to multiple endpoints and is not suitable for inclusion in each packet. One question which seems to be important is why EID's need to be in each packet or whether flow id's are what should be in packets. There is also a near term applications engineering problem to make either EID's or DNS names useful in this context by modifying internet applications so they only rely on the endpoint and not the routing address. Dan Hitchcock From owner-big-internet@munnari.oz.au Sat Apr 3 08:12:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07043; Sat, 3 Apr 1993 08:12:17 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03620; Sat, 3 Apr 1993 06:30:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22943; Fri, 2 Apr 93 15:30:25 -0500 Date: Fri, 2 Apr 93 15:30:25 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304022030.AA22943@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, hitchcoc@oerv01.er.doe.gov, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu However, a single domain name can refer to multiple endpoints Well, since the concept of 'endpoint' doesn't really exist in IP at the moment, I'm not sure about this. It is certainly true that a single DNS name can map to multiple IP addresses, which are both interface addresses and unique host binary identifiers at the moment. I reckon it would be useful to have a single DNS name map to multiple endpoints, but that's a future question. why EID's need to be in each packet or whether flow id's are what should be in packets. Note that the concatenation of a globally unique source (or destination) EID plus and endpoint-locally unique flow ID gives you a globally unique flow ID... a near term applications engineering problem to make either EID's or DNS names useful in this context by modifying internet applications so they only rely on the endpoint and not the routing address. When working on the deployment plan for Nimrod, I suggested that if we reinterpret the existing 32-bit fields in IPv4 packets as EID's, you would get this for free. Nimrod needed new addresses anyway (since the existing 32-bit things are worthless), so this gets the most function for the minimal amount of implementation cost. Of course, the 32 bits will still run out some day, but I reckon we'll get a higher utilization before we do. You only have allocation breakage, not also breakage caused by having to have topologically meaningful structure in there too. Noel From owner-big-internet@munnari.oz.au Mon Apr 5 11:03:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09890; Mon, 5 Apr 1993 11:03:59 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04161; Mon, 5 Apr 1993 08:47:55 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA18155; Sun, 4 Apr 93 15:47:28 -0700 Message-Id: <9304042247.AA18155@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 02 Apr 93 09:15:53 -0500. <9304021415.AA18855@ginger.lcs.mit.edu> Date: Sun, 04 Apr 93 15:47:28 -0700 From: Dave Crocker X-Mts: smtp Noel, First a checkpoint: it is unlikely that either of us is going to convince the other, at least at this stage. On the other hand, we do not yet seem to be tilling old details, so I'm willing to keep trying to thrash through this until we hit a fundamental wall and/or one of us is reduced to repeating the same language. Now, on to those details: ---- Included message: What I have perhaps failed to make clear is that EID's are in fact a direct result of experience gained with the Internet. In othe I appreciate the fact that the "feeling" for them derives from experience. My point, however, was that that experience needs to be applied to produce a clear sense of the details that are involved in the "use" of the thing. I.e., there needs to be a concrete list of the ways that EIDs will get used, so that each item on the list clearly describes the long-standing (or short-standing) problem that it solves. On a number of issues, such as multi-homed hosts, dual-MAC interfaces, etc, These, as well as mobile hosts, are all valid topics. No debate with the presence of a desire to fix/work on them. we have been hampered by the fact that we did not separate out the name of This is the step that you take which jumps to a specific conclusion about the problem for which I do not see justification. I cite media-level mechanisms for "local" mobility and DNS-based mechanisms for "long-haul" as examples of alternative approaches which could reasonable serve in place of the EID-based solution. (Don't launch into criticism of them. I am mentioning them as examples. Your explanations of the benefits of EIDs should take into account the counter-arguments for using alternate mechanisms.) By the way, on the matter of host-vs-interface reference, I'll note that nothing in that topic says that the host reference can't/shouldn't also be a kind of address, albeit one which has less "grain" than the precision of an interface address. Again, just raising a counter- point in all of this. The proposal to start naming the entities directly is a direct and simple response to this problem. I believe that we differ on the details about WHEN a name is needed, but do agree that names are important things, distinct from addresses. Determining the WHEN decides whether domain names are sufficient. But so far, domain names look like they serve the requirement just fine No, they won't work, because we wish to distinguish between the concept of endpoint and interfaces *at the internetworking layer*. I'm aware that that is your conclusion. What I don't see is the justification. I.e., you cite this as a requirement, rather than provide a discussion of the ways that it is to be used, which cannot be handled by an address or which cannot be handled by "occasional-use" names such as a DNS string. DNS names are structured a) to be easy for humans to use, and b) to enable them to be looked up all the time in a distributed, hierarchically organized database; efficiency of use, and minimal size, are not a big concern. None of these a re true for EID's. Noel, this is only important if the usage requirements for the name exceed the dns characteristics. I believe the key issue, here, is the reason you need a name in every packet. My only "technical" reaction is to say that a packet which contains onl y a [endpoint] name and not an address has just placed a much higher burden on the routing software of the net. For the 79th time, EID's contain *no* information about where the object is in the network, and you *do not* (cannot!) route upon them! Routing operates o Quite true. That is exactly my point. (I believe you misread my above state- ment.) My comment was that if you put a name into every packet and use that for developing your packet-forwarding behavior, then the thing making that decision (the router) has to work harder -- much harder -- than if the thing in the packet is an address and contains information about the location of the destination. addreses (of interfaces) as it always has. Interface addresses do not need to be in every packet of a flow, only those which need to be routed. I won't g Huh? "only those which need to be routed"?? Ummm. How to the other packets get from the source to the destination? back over the whole dissertation on which packets need to contain both, how and in what circumstances you need to translate between EID's and addresses how we can interoperably introduce them, etc, etc. Pity. I suspect that that is the core of the issue. We've been going over this on this list for almost a year now, but apparent ly (based on your comment about routing packets with only an endpoint name in them) it hasn't helped. In the circumstances, I can only conclude that furt her effort won't be of any noticeable use. I don't expect further debate will change any minds. Noel, the reason that I'm engaging in this exchange is that I finally came to the conclusion that the debate over the last year simply did not contain enough firm, critical analysis and that -- worse -- those who participated believed they had developed an Internet consensus on the need. I've heard several speakers make that claim. Further, I polled around and found that there were a few other, cantankerous souls -- who happen to know a hell of a lot more about this layer than I do -- who also believe EIDs are a bad idea. So, we can all give up. We can all complain about not having participated earlier. Or we can try to use the constructive give-and-take that is now engaged to see how well the idea stands up. If there were a paper I could go read, I would. But I don't recall hearing of one. After a year+, this fact bother me, but it certainly isn't a show-stopper. Dave From owner-Big-Internet@munnari.oz.au Mon Apr 5 12:25:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13401; Mon, 5 Apr 1993 12:26:11 +1000 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13392; Mon, 5 Apr 1993 12:25:57 +1000 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA23419); Sun, 4 Apr 93 21:25:46 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9304050225.AA23419@is.rice.edu> Subject: Re: address vs. EID, revisited... To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Sun, 4 Apr 93 21:25:46 CDT Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: <9304042247.AA18155@Mordor.Stanford.EDU>; from "Dave Crocker" at Apr 4, 93 3:47 pm X-Mailer: ELM [version 2.3 PL11] Dave Crocker I had an interesting conversation last week. The two arguements that seemed to carry some weight for EID support follow: 1. Inventory control - I think this needs an EID thingie 2. If (a big one) there is ever a perceived need to have EIDs, and if we have NOT made allowances for them, we hamstring ourselves. From owner-big-internet@munnari.oz.au Mon Apr 5 15:22:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21144; Mon, 5 Apr 1993 15:22:46 +1000 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17255; Mon, 5 Apr 1993 13:52:51 +1000 (from kre@munnari.OZ.AU) To: Dave Crocker Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... In-Reply-To: Your message of "Sun, 04 Apr 1993 15:47:28 MST." <9304042247.AA18155@Mordor.Stanford.EDU> Date: Mon, 05 Apr 1993 13:52:34 +1000 Message-Id: <9132.733981954@munnari.OZ.AU> From: Robert Elz Date: Sun, 04 Apr 93 15:47:28 -0700 From: Dave Crocker Message-ID: <9304042247.AA18155@Mordor.Stanford.EDU> I cite media-level mechanisms for "local" mobility and DNS-based mechanisms for "long-haul" as examples of alternative approaches which could reasonable serve in place of the EID-based solution. Could you please forget mobility - its becoming evident that one of the worst mistakes made by the pro-EID people was happening to mention in passing that a side effect of some advantages of EIDs might be that mobility might be easier to do - now it seems that any possibile alternative mobility scheme is a reason not to do EIDs. (Don't launch into criticism of them. I am mentioning them as examples. Your explanations of the benefits of EIDs should take into account the counter-arguments for using alternate mechanisms.) This is a bit unfair - Noel is supposed to supply counter examples without criticising your suggested alternatives to EIDs ? I believe the key issue, here, is the reason you need a name in every packet. There is nothing about EIDs as such that require that they be carried in every packet. That's one approach, one possible lower layer way of communicating them, but its certainly not required by the concept itself. All that's required of EIDs is that each end of a conversation knows the EID of the other end - perhaps a TCP may send them in SYN packets, with the other end remembering the EID that it received for this connection. Huh? "only those which need to be routed"?? Ummm. How to the other packets get from the source to the destination? You don't seem to have read Noel's Nimrod stuff, which is obviously what he was referring to there. Unfortunately the I-D's on that seem to have expired. Noel can say it better, but I believe his definition of "routing" is making a decision on which path the packet should follow, which doesn't need to be done for every packet, all packets must be "forwarded", but the decision on which outgoing path can be made based on information left behind from a previous routing decision. Packets which are only being forwarded just need a key to enable the router to use the correct previously calculated forwarding path - an EID in every packet - instead of the address, could serve this role (since its unique per destination it clearly can't be ambiguous). Since EIDs will certainly be no longer than addresses (there is at least one address per EID, and the address has to contain topological information not required in the EID) at this point I should ask you to justify putting an address in every packet? Concrete examples of why they're required which can't be done by alternative means please. But to make this message not entirely content free, I thought I'd given one example of one real use for EIDs repeating one that I thought I'd given in enough detail in my last message - but obviously not. With EIDs I can arrange to permit addresses to change, en masse, without upsetting live connections - ie: hosts networks or entire regionals (and all their customers) can have their addresses changed to suit changing topology needs. Note: this is not a "might be able" or something, its a definite can be done. It would allow, as an example, BARRNET to switch from being an NSFnet customer to an Alternet customer, while at all times using addressing that permits optimal routing down the correct path to reach them (optimal here means as optimal as routing ever is with CIDR type address coalescing). The desire to do this kind of thing is to keep routing databases small, while not locking end sites, or regionals, into some kind of fixed interconnection rules (as the metropolitan addressing schemes require). I think you'll agree that the ability to useful, probably even necessary. Now show us the alternative scheme that permits this kind of mass renumbering without using EIDs, and which permits transport level connections to remain alive for months, long after the addresses that were previously assigned have been allocated to others, who are now communicating with the same endpoints as a system that has been renumbered. You may assume that the DNS modifications needed can be made (as I do). Note that the key feature of EIDs here is the isolation of the transport level (TCP, UDP, etc - any of them) from network level (route carrying) addresses - something which, with hindsight, should never have been mixed into TCP. This in itself is all I need to convince me that EIDs are right, they provide the mechanism needed to make this separation in functionality - the "addressing" needed at the TCP level is 100% topology independant, all that's needed is an identifier that uniquely identifies the peer entity, it shouldn't have topology related noise (necessary in network level addresses) bound up in with it. kre From owner-Big-Internet@munnari.oz.au Tue Apr 6 02:06:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14803; Tue, 6 Apr 1993 02:06:27 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14787; Tue, 6 Apr 1993 02:06:07 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA09194; Mon, 5 Apr 93 12:02:39 -0400 Date: Mon, 5 Apr 93 12:02:39 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9304051602.AA09194@er.doe.gov> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au I'm going to make the following assumptions: 1) Topology changes in the net are inevitable and changing addresses will be essential to keep routing databases manageable. 2) The current setup where you have to touch every host on the site to readdress is not palatable to users. 3) You are not allowed to break open connections or flows when you re- address. 4) You have a lot of applications which think they need both address and name to work. Two Scenarios: DNS Name = EID In this case you can cetrtainly satisfy 1. To satisfy 2 requires some way for hosts to "learn" their address from the DNS by bootstrap. Note that you are not allowed to assume that the DNS server closest to the host is on the same ethernet or whatever. This is perhaps doable but pretty complicated. 3) is a bear because of cache consistency, old addresses, new addresses, time to live, time to die... etc. Perhaps doable but difficult. 4) is also very difficult because there is a lot of code constructed this way which all has to be modified to listen to DNS or whatever Scenario 2: DNS # EID and EID initially old IPv4 address This can satisfy 1,2,and 3 because endpoint is different from routing. Note that in this case renumbering is logically similar to what happens in TCP when a link breaks so its handled the same way. Note that for this choice of EID much of the old code works still because it has the two things it needs a name and 32bit number and the packet forwarder is all that needs to be changed. Dan Hitchcock P.S. there are many holes and vaguenesses in this but perhaps it could form the basis for a rational discussion of pro's and con's. From owner-Big-Internet@munnari.oz.au Tue Apr 6 04:06:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19670; Tue, 6 Apr 1993 04:06:52 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19649; Tue, 6 Apr 1993 04:06:45 +1000 (from kasten@ftp.com) Received: by ftp.com id AA20141; Mon, 5 Apr 93 14:06:37 -0400 Date: Mon, 5 Apr 93 14:06:37 -0400 Message-Id: <9304051806.AA20141@ftp.com> To: dcrocker@Mordor.Stanford.EDU Subject: Re: address vs. EID, revisited... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Dave, et al, The security folks have, in the past, indicated a strong desire to have EIDs in packets. This provides them with some magic that they apparently need. I do not pretend to understand exactly what it is they want -- have you polled some of them? Are there any out there that can contribute? > Noel, the reason that I'm engaging in this exchange is that I finally came to > the conclusion that the debate over the last year simply did not contain > enough firm, critical analysis and that -- worse -- those who participated > believed they had developed an Internet consensus on the need. I've heard > several speakers make that claim. Further, I polled around and found that > there were a few other, cantankerous souls -- who happen to know a hell of a > lot more about this layer than I do -- who also believe EIDs are a bad > idea. > > So, we can all give up. We can all complain about not having participated > earlier. Or we can try to use the constructive give-and-take that is > now engaged to see how well the idea stands up. If there were a paper I > could go read, I would. But I don't recall hearing of one. After a year+, > this fact bother me, but it certainly isn't a show-stopper. > > Dave > -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Tue Apr 6 04:08:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19823; Tue, 6 Apr 1993 04:09:00 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19816; Tue, 6 Apr 1993 04:08:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27350; Mon, 5 Apr 93 14:08:45 -0400 Date: Mon, 5 Apr 93 14:08:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304051808.AA27350@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, dcrocker@mordor.stanford.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If ... there is ever a perceived need to have EIDs, and if we have NOT made allowances for them, we hamstring ourselves. Well, not necessarily. For instance, in SIP, which has only these 64 bit fields in the packet, you could always use the hack I'm planning on using for deploying Nimrod in IPv4, and re-interpret those 64 bit fields as EID's; they are just the right length! All the additional deployment stuff (how you deal with unmodified hosts) would work the same as well. This should not be interpreted to mean either a) I think the Internet should switch to SIP, or b) I think we should put off adding EID's. Noel From owner-Big-Internet@munnari.oz.au Tue Apr 6 04:10:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19859; Tue, 6 Apr 1993 04:10:44 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19855; Tue, 6 Apr 1993 04:10:35 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA13567; Mon, 5 Apr 93 11:10:18 -0700 Message-Id: <9304051810.AA13567@Mordor.Stanford.EDU> To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 05 Apr 93 14:06:37 -0400. <9304051806.AA20141@ftp.com> Date: Mon, 05 Apr 93 11:10:17 -0700 From: Dave Crocker X-Mts: smtp Frank, The security community's requirement is for a global, unique, end-to-end identifier. From each conversation I've had, I've been told that the current IPv4 address serves that purpose just fine. I.e., the security community does not seem to be imposing a new requirement on us. Dave From owner-Big-Internet@munnari.oz.au Tue Apr 6 08:19:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28837; Tue, 6 Apr 1993 08:19:59 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28832; Tue, 6 Apr 1993 08:19:53 +1000 (from kre@munnari.OZ.AU) To: Dave Crocker Cc: kasten@ftp.com, big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... In-Reply-To: Your message of "Mon, 05 Apr 1993 11:10:17 MST." <9304051810.AA13567@Mordor.Stanford.EDU> Date: Tue, 06 Apr 1993 08:19:42 +1000 Message-Id: <9406.734048382@munnari.OZ.AU> From: Robert Elz Date: Mon, 05 Apr 93 11:10:17 -0700 From: Dave Crocker Message-ID: <9304051810.AA13567@Mordor.Stanford.EDU> I.e., the security community does not seem to be imposing a new requirement on us. I don't know much about security either, but some kind of identifier is all I've ever heard is needed - but you might want to ask what kind of lifetime the identifier is assumed to have - and in particular, whether an identifier that is subject to change, and reassignment to another entity, which is the kind of property addresses should have, will be good enough. ie: the security community may not be imposing new requirements, but it may turn out that if we satisfy their requirements without something new, then we hamstring ourselves. kre From owner-Big-Internet@munnari.oz.au Tue Apr 6 08:35:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29268; Tue, 6 Apr 1993 08:35:40 +1000 (from owner-Big-Internet) Return-Path: Received: from asylum.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29257; Tue, 6 Apr 1993 08:35:31 +1000 (from dab@asylum.sf.ca.us) Received: from dab.gate.epilogue.com by asylum.sf.ca.us via PCMAIL with DMSP id AA11223; Mon, 5 Apr 93 18:35:23 -0400 (EDT) Date: Mon, 5 Apr 93 18:35:23 -0400 (EDT) Message-Id: <9304052235.AA11223@asylum.sf.ca.us> To: dcrocker@MORDOR.STANFORD.EDU Subject: Re: address vs. EID, revisited... From: dab@asylum.sf.ca.us (David Bridgham) Reply-To: dab=replies@EPILOGUE.COM Cc: big-internet@MUNNARI.OZ.AU Sender: dab@asylum.sf.ca.us Repository: asylum Originating-Client: gate.epilogue.com > I appreciate the fact that the "feeling" for them derives from experience. My > point, however, was that that experience needs to be applied to produce a clear > sense of the details that are involved in the "use" of the thing. I.e., there > needs to be a concrete list of the ways that EIDs will get used, so that > each item on the list clearly describes the long-standing (or short-standing) > problem that it solves. My feeling for EIDs comes from the repeated times over the past years that I've been trying to get something to work and I notice that my life would be a lot easier if these damn machines had only one address. What I really wanted was separation of end-point identification and routing. Since I couldn't get that I settled for yet another kludge. We have enough kludges already. > I'm aware that that is your conclusion. What I don't see is the justification. > I.e., you cite this as a requirement, rather than provide a discussion of the > ways that it is to be used, which cannot be handled by an address or which > cannot be handled by "occasional-use" names such as a DNS string. You could forward based on the address, but an EID is easier. EIDs are smaller, fixed length, and generally more computer friendly than addresses. Also, machines which change addresses mid-connection (either mobile or re-addressed due to automatic address assignment) would probably find it easier to stay in communication if the forwarding is based on something that still identifies them (i.e. an EID). Again, kludges could make it work anyway but who needs more kludges? > Quite true. That is exactly my point. (I believe you misread my above state- > ment.) My comment was that if you put a name into every packet and use that > for developing your packet-forwarding behavior, then the thing making that > decision (the router) has to work harder -- much harder -- than if the > thing in the packet is an address and contains information about the location > of the destination. If you require each router to route every packet in a flow then you're right. But then, wouldn't it be easier to include the route in every packet instead of the address? Even better, wouldn't it make sense to route the packet stream once and let the packets just follow that route from then on? Engineering issues then are how to handle route failure (detection of failure triggers a reroute) or superior route availability (same solution but detection seems harder (but harder than routing every packet?)). The reason we think it's easy to route on addresses is that we've equated routes and addresses. It *is* easy to route on routes. In the current internet, addresses equal routes. In most of the proposed routing and addressing architectures for IPv7, addresses equal routes. Of course machines that live under multiple providers need multiple addresses, there are multiple routes to those machines. AN ADDRESS IS NOT A ROUTE! If we can't split those two things apart we're never going to have a network that can grow with any flexibility. The kludge tower will grow combinatorially with the network. Many more network administrators will be needed to be trained, hired, and put to work keeping the tower from toppling (or more likely fragmenting). > back over the whole dissertation on which packets need to contain both, how > and in what circumstances you need to translate between EID's and addresses > how we can interoperably introduce them, etc, etc. > > Pity. I suspect that that is the core of the issue. Not really. The core is the abstract part. The concrete details certainly do help though in focusing ones thoughts though. Has the ID really timed out? > Further, I polled around and found that > there were a few other, cantankerous souls -- who happen to know a hell of a > lot more about this layer than I do -- who also believe EIDs are a bad > idea. This is interesting. I don't think I've heard anyone yet say that EIDs were a *bad* idea, just that they weren't necessary didn't buy you anything and so why bother. What makes them bad? Dave Bridgham From owner-Big-Internet@munnari.oz.au Tue Apr 6 10:51:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05511; Tue, 6 Apr 1993 10:52:08 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05503; Tue, 6 Apr 1993 10:51:56 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09491; Mon, 5 Apr 93 20:51:49 EDT Date: Mon, 5 Apr 93 20:51:49 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304060051.AA09491@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: EIDs and Security We can do security _fine_ without EIDs and having only something similar to an IPv4/IPv6/IPv7 address (I don't really understand PIP yet, despite Paul's best efforts, so am not commenting on PIP.) I personally think it is high time that an Internet Draft appeared explaining why EIDs are needed. It should be written so that normal IETF folks can understand. I've seen lots of words pass by on this list and I haven't seen the need for a separate EID yet. Now I'm not a routing/addressing person so maybe there is a good reason to have EIDs. All I'm saying is that this justification and explanation (including a working definition of an EID) really needs to be set down in detail in something like Internet Draft format so the rest of us can read/review/understand why some folks think they are needed. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Tue Apr 6 11:40:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07361; Tue, 6 Apr 1993 11:40:54 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07358; Tue, 6 Apr 1993 11:40:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03841; Mon, 5 Apr 93 21:40:42 -0400 Date: Mon, 5 Apr 93 21:40:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304060140.AA03841@ginger.lcs.mit.edu> To: atkinson@itd.nrl.navy.mil, big-Internet@munnari.oz.au Subject: Re: EIDs and Security Cc: jnc@ginger.lcs.mit.edu I personally think it is high time that an Internet Draft appeared explaining why EIDs are needed. It should be written so that normal IETF folks can understand. As I indicated in my long reply today to Dave Crocker, having a document is probably a good idea. However, I seriously doubt that the existence of this document is going to make a difference, in terms of changing many minds about whether EID's are needed. I've seen lots of words pass by on this list and I haven't seen the need for a separate EID yet. If you've read those words, and still aren't convinced, I am frankly doubtful that a document is going to make you change your mind. Now I'm not a routing/addressing person so maybe there is a good reason to have EIDs. EID's have very little to do with routing and addressing; it's more an issue of naming of end-end entities. Noel From owner-big-internet@munnari.oz.au Tue Apr 6 12:09:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08770; Tue, 6 Apr 1993 12:10:46 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304060210.8770@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04879; Tue, 6 Apr 1993 10:37:34 +1000 (from ULLMANN@PROCESS.COM) Date: Mon, 5 Apr 1993 20:37 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: (ex) re: EIDs... Noel, I was sorry to hear that you weren't at the IETF (forgive me if that is wrong; but I don't recall seeing you either ;-). I had thought you would find the IPv7 presentation interesting. [aside to others not at the IETF: note that IPv7 specifies one particular proposal, that doesn't have a cute acronym (RIP being taken :-). SIP is v6, PIP is v8, TUBA v9, except that it doesn't really need a number. These are IANA assignments.] IPv7 provides a forward route/flow identifier, as well as source and destination "addresses". Over time, the addresses can be more and more re-interpreted as EID's (as they are in TCP), although what we think of as "one host" will probably persist in having more than one in cases where other (local) routers are too inflexible. The IPv7 addressing structure provides for administrative assignmnet of "addresses" (used loosely again)so that some aggregation continues to be useful as we move from IPv4 to IPv7 and into using even more powerful routing. If the routing ever gets to the point where EIDs can be used purely (still assuming EID->something->route mapping), they can be only administrative. Most importantly, we can get there from here without any abrupt transition. (Assuming we are capable of letting go of things like the strict catenet model and 1-1 address- interface mapping as we develop; this means no reactionaries ;-) Please don't try to reply to this prima facie without reading the IDs. The IDs were re-issued March 26th; make sure you have the current versions please. Best Regards, Robert From owner-big-internet@munnari.oz.au Tue Apr 6 12:09:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08750; Tue, 6 Apr 1993 12:09:48 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29704; Tue, 6 Apr 1993 08:44:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03267; Mon, 5 Apr 93 18:43:58 -0400 Date: Mon, 5 Apr 93 18:43:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304052243.AA03267@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu On the other hand, we do not yet seem to be tilling old details .... [until we are] reduced to repeating the same language. Sigh, I think we are close to that point, though. there needs to be a concrete list of the ways that EIDs will get used, so that each item on the list clearly describes the long-standing ... problem that it solves. ..... Your explanations of the benefits of EIDs should take into account the counter-arguments for using alternate mechanisms. Recognizing the existence of endpoints as a distinct class of entities from interfaces, and naming them explicity with EID's, doesn't solve anything directly. Rather, these steps are a critical component in *architecturally clean* solutions to a wide range of problems: all those problems, in fact, which require recognition, at the internetwork and transport layers, of the fact that a particular communicating entity is not interchangably and indissolubly bound to a particular network interface. (I'd say something about "architecturally clean", but I don't want to make this too long; that's a lecture in itself.) As long as we only have one name, at the internetwork and transport layers, for an interface *and* the communicating entity behind it, we'll *never* have clean solutions to problems which require that they be dealt with *separately*. It is that realization which makes people who favor EID's back them so strongly, without *needing* worked examples in detail. It's just obviously impossible to distinguish between two distinct things if you only have one name for both of them! You seem to not dispute the first part of the point here, which is that we must modify the internetworking model to communicate between endpoints, not interfaces, but don't go for the second part, use of a new namespace (EID's) to name endpoints. You keep insisting that the DNS name is an appropriate name to use for endpoints. To be brutally frank, I have a hard time seeing your clinging to DNS names as the correct names to use for endpoints as anything but a desperate rear-guard action against explicit introduction of endpoints into the internetworking layer of the architecture. It seems like you are fighting about the *form* of the correct name for endpoints, since the case for separate recognition of endpoints and addresses is pretty strong. For DNS names to be even *conceivably* useful as endpoint names, it would require a major change to the IP architecture; to wit, making the DNS name the name which is used by all internetworking and transport layer code. This would be a massive upheaval of monumental proportions. Right now, DNS names are a whole separate subsystem, which is entirely unknown through the IP and TCP layers; they operate entirely in terms of IP addresses. Indeed, if we were willing to type in things in decimal, we could turn off the DNS tomorrow and the network would continue to function. On the grounds of the difficulty of introduction alone, it makes sense to make the endpoint name be a short, binary fixed length string (i.e. the EID), as this allows us to reinterpret existing fields in every packet (and all the existing internetwork and transport code). How can you agree on the need for distinct naming of endpoints, but then propose a name which is going to be monumentally difficult to use for that purpose? No, they won't work, because we wish to distinguish between the concept of endpoint and interfaces *at the internetworking layer*. I'm aware that that is your conclusion. What I don't see is the justification. I.e., you cite this as a requirement, rather than provide a discussion of the ways that it is to be used, which cannot be handled by an address or which cannot be handled by "occasional-use" names such as a DNS string. Look, there are many problems (the multi-homed host and mobile host among them) which cannot be solved: i) by the DNS (since the DNS lookup step is invoked only when the connection is opened, after which the TCP connection, IP packets, etc are in terms of the IP address), or: ii) the IP address, without making the complexity and cost of routing much worse than it already is, which is pretty damn bad. (Anyway, if it were possible to fix it with the address, we'd have done it years ago! :-) Source routing of packets (i.e. not using the IP destination address in the packet as the thing to route on), the usual last resort of the desperate, is *exactly* transforming the interpretation of the 32 bit "IP address" field from a address to an EID. There *is* a separate "destination address" field in those packets, it's just in the SR option. It's just a kludge (and once again, I don't want to lumber this message up with a homily on architectural cleanness, and the way systems die design- entropy/warts/bags-on-the-side death, and how to prevent that). I propose that instead of enshrining this kludge in the architecture, we fix the mistake we made to begin with. My comment was that if you put a name into every packet and use that for developing your packet-forwarding behavior, then the thing making that decision (the router) has to work harder -- much harder -- than if the thing in the packet is an address and contains information about the location of the destination. Depends on your model of how routers are going to forward packets. I don't think they are going to look up in a routing table for each packet they see; hell, no commerical router does this now! If they retain some cached information, or especially if we have flows, this piece of information is *exactly* what they need. KRE has explained the latter case (flows) in more detail. I've heard several speakers make that claim. Not me, I hope: I know better! :-) Further, I polled around and found that there were a few other, cantankerous souls -- who happen to know a hell of a lot more about this layer than I do -- who also believe EIDs are a bad idea. They should speak up, or at least have their names provided. Without that, this statement is of zero value. If there were a paper I could go read, I would. But I don't recall hearing of one. Try: Jerome H. Saltzer; "On the Naming and Binding of Network Destinations"; in Local Computer Networks, North-Holland Publishing; 1982. I've mentioned this on this list before, if I recall correctly. It doesn't explicity talk about EID's (or even endpoints as distinct from hosts, endpoints being due in large part to Dave Oran, and I don't know if he has a reference), but it does ably explain why we need a separate namespace for the communicating entities which is separate from the namespace of interfaces. This is not currently available online as an RFC, but I have talked with Jerry about so doing. He's agreeable, and he doesn't think there are any copyright issues, but it needs to be typed in (which I will undertake). After a year+, this fact bother me, but it certainly isn't a show-stopper. Well, as usual, Jerry was a long way ahead of the rest of us; so far ahead we tend to forget he was there. However, I agree, we could use a paper which talks about how flows, endpoints, resource allocation/reservation, etc, all tie together. So far, nobody has done so since everyone is working on their own little slice of the problem. Noel From owner-Big-Internet@munnari.oz.au Tue Apr 6 12:53:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10682; Tue, 6 Apr 1993 12:53:31 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10658; Tue, 6 Apr 1993 12:53:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04203; Mon, 5 Apr 93 22:53:08 -0400 Date: Mon, 5 Apr 93 22:53:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304060253.AA04203@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, kre@munnari.oz.au Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Could you please forget mobility - its becoming evident that one of the worst mistakes made by the pro-EID people was happening to mention in passing that a side effect of some advantages of EIDs might be that mobility might be easier to do - now it seems that any possibile alternative mobility scheme is a reason not to do EIDs. Amen! There is nothing about EIDs as such that require that they be carried in every packet. That's one approach, one possible lower layer way of communicating them, but its certainly not required by the concept itself. All that's required of EIDs is that each end of a conversation knows the EID of the other end.. Exactly. I propose that we have them in all packets for several reasons. First, it's an easy, interoperable, transition using existing IPv4 packet formats and TCP software. With a large, functional, system, this kind of consideration is of extreme importance. Second, even with a pure datagram model (i.e. no flows) it will be reasonably efficient with absolutely unmodified hosts, and with one very minor change (in the get_host_by_name module), it will be as efficient as the current system. Moreover, it would allow introduction of a new interface address (and routing architecture), to replace the current 32 bit kludges, as an adjunct to the current IP layer (and this could be anything, e.g. NSAP's and IDRP, not just Nimrod). Third, if we go to a flow-based system, theoretically you could get rid of both the address *and* EID in most packets, once the flow was set up. However, you'd still need to identify which flow each packet belonged to; you'd either have to make the flow id be a locally assigned numbers in each router, in which case you'd have to remap this at every router, or you'd need a global flow id. The latter can be trivially produced using the EID as part of it; it makes sense to have the EID in every packet since you need a flow-id in each packet anyway. Unfortunately the I-D's on that seem to have expired. Yah, I need to get them put back up. I'm supposed to update the Nimrod I-D to carry the latest thinking before so doing; I hope this debate stops soon so I can get to it! You don't seem to have read Noel's Nimrod stuff ... Noel can say it better.. Actually, your explanation was very good. I'd explained some of this in the long message to Big-I this weekend about definitions; it's not really talked about in the Nimrod documents. Noel From owner-Big-Internet@munnari.oz.au Tue Apr 6 14:53:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16227; Tue, 6 Apr 1993 14:54:25 +1000 (from owner-Big-Internet) Return-Path: Received: from postoffice1.psc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16094; Tue, 6 Apr 1993 14:53:41 +1000 (from boone@psc.edu) Received: by postoffice1.psc.edu (5.57/Ultrix3.0-C 02/11/93 boone) id AA14868; Tue, 6 Apr 93 00:53:27 -0400 Date: Tue, 6 Apr 93 00:53:27 -0400 From: boone@psc.edu (Jon Boone) Message-Id: <9304060453.AA14868@postoffice1.psc.edu> To: big-internet@munnari.oz.au Subject: Forwarded post (sorry, it's late) Gee, it's so late, I forgot to reply to the message via mail (we gateway the mail into a newsgroup.) Here's the post! :( --------------- fwd'd message follows --------------- Path: news.psc.edu!boone From: boone@psc.edu (Jon Boone) Newsgroups: psc.pscnet.maillists.ietf.big-internet Subject: Re: address vs. EID, revisited... Date: 6 Apr 1993 04:45:31 GMT Organization: Pittsburgh Supercomputing Center, Pittsburgh PA, USA Lines: 121 Message-ID: <1pr1tbINNc17@postoffice1.psc.edu> References: <9304021606.AA02149@er.doe.gov> NNTP-Posting-Host: postoffice1.psc.edu X-Newsreader: TIN [version 1.1 PL8] Warning! I have not read more than 1/2 of this thread. I am only attemtping to supply another example of the *usefullness* of EIDs as a concept. Please excuse any glaring ignorance that I demonstrate. Note that this is my opinion and does not necessarily reflect the opinion of anyone else at the PSC nor PSC offical policy. (Being a low-man-on-the-totem-pole in the networking group, I may well get something wrong!) On with the example! On Fri, 2 Apr 93 11:06:28 -0500 in <<9304021606.AA02149@er.doe.gov>> Dan Hitchcock (hitchcoc@oerv01.er.doe.gov) wrote: :>First some identifier of network endpoint is important which is :>different from the routing significant address. This enables change :>of topology and routing changes without perhaps touching all the :>hosts on the net. :> :>Depending on your point of view the domain name or some new EID :>would fill this need need. However, a single domain name can refer :>to multiple endpoints and is not suitable for inclusion in each :>packet. We have attempted to address this sort of issue here at the PSC in our internal network design. We have our YMP at a site approximately 30 miles from where we have our offices and NSFnet connection. We had 3 distinct paths between the two sites, as well as 3 or 4 routers which were on 2 or more of the paths. In this manner, we hoped to always have a backup path to the YMP. To make things easier on the users, we decided to try to use the DNS name as the EID for the YMP. That way, when our networks roled over due to link failure, they could continue some semblance of their work. (The packets would still be addressed to the interface on the down link, but they would be routed through the backup link(s), all without the user noticing that the network topology had changed under their feet! In order to do this, we created a DNS-name (YMP-ALL) that had an A-Rec for the loopback address of the YMP. We also had each interface address set up to return the cname YMP-ALL. So, we had the EID put in and since all the connections were centered around the loopback/YMP-ALL pair, we had an almost workable system. There were, however, some problems. First, not all applications took kindly to this sort of futzing with DNS names (there were claims that some kinds of apps expected the incoming packets to have the same IP adddress as the end-point. Secondly, it required a kernel hack to support assigning a non-127.0.0.1 IP address to the loopback. Imagine a world in which EIDS are a seperate layer from the addressing. In that world, our problems are solved, since we can assign an EID to the YMP and it doesn't matter what the network topology is to get from your machine to the YMP --- you only have to use the EID to get there! And we can then change routing while you're working. And when you have a machine that is in use 24hrs a day, 7 days a week, it is much better to not lose connections due to routing instability. Now, clearly, the DNS/IP-ADDRESS hack worked (to some extent). But, it was difficult to support, it required too many kernel/application mods (remember, each time the O/S was upgraded, more patches!), it confused the users to no end ("Why doesn't it work when I try to contact YMP-ALL sometimes, but sometimes it does?"), and all just to provide a more reliable connection. I think that EIDs solve most (if not all) of these problems (apps/kernels will support them, no confusion for the users beyond that which they already experience when using TCP/IP, and added reliability in the face of network failures). After all, "Only the end-point matters; why should the user care what network path they take to get there?" :>There is also a near term applications engineering problem to make either :>EID's or DNS names useful in this context by modifying internet applications so :>they only rely on the endpoint and not the routing address. Indeed. But imagine this senario. I had a machine, called mailer. It became unrelaible and got renamed hotline. A machine called marlin (which was masquerading at the address assignd to norvelt) got renamed mailer for a few months. Now, a machine which was called postoffice2 is now mailer and marlin/norvelt/mailer is netcomm-dmz, while netcomm is ckp. Mailer is still hotline. I followed that; did you? Most people lose it about the second renaming of marlin. Or was that hotline? Or netcomm-dmz? Who's postoffice2? But, with EIDs, foobar is foobar is foobar. The "name" doesn't matter, only the EID. But we use names as shorthand for IP addresses. Now you want us to start using them as EID's for machines. So what happens when a machine changes IP address? Well, the name goes with it! So how do you get to the IP address that the machine *used* to be at? Well, memorize it; after all, you'll have to memorize the EID's if they aren't DNS names. Well, not *quite* true. With the new E-REC for DNS (coming to a net near you!), we can cons up a string to match with the E-REC that takes the place of DNS names as strings for IP addresses. So then mailer becomes mailer (CNAME) / futz (E-REC). Hotline becomes hotline / mailer. Alternatively, you could re-interpret the CNAME as an alias for the EID, and cons up an ANAME that is a shorthand for the address. Like, net1 (128.45), net2 (128.46), net3 (128.47), etc. So the ANAME might be net2.sub1.1, or net1.sub2.2 or net3.sub74.244. Then you preserve the functionality that I use dns names for and the functionality that you would have us use DNS names for and we don't have to rely on something as unreliable as a nameserver. I hate it when the nameserver here goes down and people can't get anywhere because (although the network is working fine), they don't know the address of anything they want to get to. This problem won't go away by introducing EIDs (indeed, I think that there will be a necessary addition to DNS to support alias strings for EIDs, like CNAMES), but at least we won't be making the network more unreliable by *forcing* people to use DNS names. (I hope that this article proves to be somewhat coherent and relevant. It took longer than I thought it would to say what I wanted to say and it's now quite late. I'm afraid the quality might have diminished by the end... :( ) Jon Boone -- /*****************************************************************************/ /* Jon `Iain` Boone Network Systems Administrator boone@psc.edu */ /* iain+@cmu.edu Pittsburgh Supercomputing Center (412) 268-6959 */ /* I don't speak for anyone other than myself, unless otherwise stated!!!!!! */ /*****************************************************************************/ From owner-Big-Internet@munnari.oz.au Tue Apr 6 21:06:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01840; Tue, 6 Apr 1993 21:06:59 +1000 (from owner-Big-Internet) Return-Path: Received: from cnaf43.infn.it by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01825; Tue, 6 Apr 1993 21:06:39 +1000 (from VISTOLI@infn.it) Date: Tue, 6 Apr 1993 13:06:44 +0200 (WET-DST) From: VISTOLI@infn.it To: big-internet@munnari.oz.au Cc: VISTOLI@infn.it Message-Id: <930406130644.3ac01520@infn.it> Subject: add mailing list request could you add me in your mailing list? vistoli@infn.it i'm from national institute for nuclear physics italy. regards, cristina vistoli From owner-Big-Internet@munnari.oz.au Tue Apr 6 22:35:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05012; Tue, 6 Apr 1993 22:35:42 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05007; Tue, 6 Apr 1993 22:35:33 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA03232; Tue, 6 Apr 93 05:35:16 -0700 Message-Id: <9304061235.AA03232@Mordor.Stanford.EDU> To: ULLMANN@PROCESS.COM (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Re: (ex) re: EIDs... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 05 Apr 93 20:37:00 -0400. <9304060210.8770@munnari.oz.au> Date: Tue, 06 Apr 93 05:35:16 -0700 From: Dave Crocker X-Mts: smtp Robert, During your IETF presentation, I found myself deciding that your proposal was for a protocol that had the merits of being neat, clean and similar to IPv4. It was, in fact, a case of deja vu. I could not determine any meaningful difference between your proposal and SIP. Hence, I'd appreciate your elaborating. Thanks. Dave From owner-Big-Internet@munnari.oz.au Wed Apr 7 02:02:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13628; Wed, 7 Apr 1993 02:02:53 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304061602.13628@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13625; Wed, 7 Apr 1993 02:02:36 +1000 (from ULLMANN@PROCESS.COM) Date: Tue, 6 Apr 1993 11:57 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au, wagner@munnari.oz.au Subject: Re: (ex) re: EIDs... Hi, Major points (these were 3 and 4 on the Trouble with Tribbles slide): TCP/IPv7 updates TCP to deal with the new time-speed-delay domains we are getting into. This is actually a current problem, not a near future one. On TCP/IPv4, we either have to cheat the window, or use the [RFC1323] options; on the next generation (1994-96) of systems in the 200-1Kmip/100m-1Gbit range we have to do this all the time, not just in special cases. Since we have to touch the transport layer anyway in conversions (*see next point) this is the time to do it. TCP/IPv7 also provides for direct interoperation with v4; this is an imperative; anything that can't be deployed at will as an upgrade to arbitrarily chosen systems (i.e. systems the customers choose under other constraints) simply won't fly. IPAE->SIP does not provide this mandatory flexibility and continued full interoperation with v4 under arbitrary configurations. Other points have to do with keeping the addressing administrative, not topology-coercive, and not doing odd things like overloading the TLPID (SIP's "payload" looks pretty confused to me.) There are also some field size issues (e.g. FrID/FlowID) with differing rationale. I encourage you (all) to read the drafts; there is a lot of detail there. Best Regards, Robert From owner-Big-Internet@munnari.oz.au Wed Apr 7 02:58:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15924; Wed, 7 Apr 1993 02:58:25 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15916; Wed, 7 Apr 1993 02:58:08 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA13406; Tue, 6 Apr 93 09:57:57 -0700 Message-Id: <9304061657.AA13406@Mordor.Stanford.EDU> To: ULLMANN@PROCESS.COM (Robert L Ullmann) Cc: big-internet@munnari.oz.au, wagner@PROCESS.COM Subject: Re: (ex) re: EIDs... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 06 Apr 93 11:57:00 -0400. <9304061602.AA12976@Mordor.Stanford.EDU> Date: Tue, 06 Apr 93 09:57:57 -0700 From: Dave Crocker X-Mts: smtp Robert, Hmmmmmmmm. Please be patient. I'm kinda slow on some of this... ---- Included message: TCP/IPv7 updates TCP to deal with the new time-speed-delay domains we First, modifications to TCP are entirely orthongonal to the IPv4 routing and addressing crisis. That's not to say that there isn't benefit to be accrued, but I would assume that any changes to TCP apply equally well to ANY of the IPng (next generation) alternatives. If THAT assumption isn't true, please correct me quickly because it will cause a major "tilt" message in my architectural model. Second, I was under the impression that the TCP Large Windows folks had a working, accepted, installed enhancement. I'm easily convinced that there are better, native solutions, but not sure they will work with the installed base. In truth, however, I'd just as soon defer any discussion about TCP and keep the focus on IPng. (Well, ok, not 'defer' as much as move it to a separate discussion.) TCP/IPv7 also provides for direct interoperation with v4; this is an imperative; anything that can't be deployed at will as an upgrade to arbitrarily chosen systems (i.e. systems the customers choose under other constraints) simply won't fly. IPAE->SIP does not provide this mandatory flexibility and continued full interoperation with v4 under arbitrary configurations. Just to make sure that no one misses a key affiliative issue, I chair the IPAE working group. IPAE is devoted to the question of transition. SIP is the target protocol; IPAE is the set of transition techniques. Having said that, I have to assert that your own assertion is simply and, I believe completely, wrong. We spent many months going over interaction scenarios. We think we've got the topic locked down solidly. I'm eager to hear of specific failings -- so we can fix them -- but suspect they won't be forthcoming. Other points have to do with keeping the addressing administrative, Addressing looks increasingly like a topic generic to all the alternatives. By and large, I believe any of them can be required to adopt whatever strategy the IETF determines is required. Each has taken its own stab at what it thinks is best, but I don't believe any are set in concrete, yet. Dave From owner-Big-Internet@munnari.oz.au Wed Apr 7 05:49:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22008; Wed, 7 Apr 1993 05:50:09 +1000 (from owner-Big-Internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22005; Wed, 7 Apr 1993 05:49:58 +1000 (from @yonge.csri.toronto.edu:chk@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14427>; Tue, 6 Apr 1993 15:49:44 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA09945 (5.65a/IDA-1.4.2 for big-Internet@munnari.oz.au); Tue, 6 Apr 93 15:38:20 -0400 Received: by dino.alias.com id AA13638 (5.65a/IDA-1.4.2 for big-Internet@munnari.oz.au); Tue, 6 Apr 93 15:38:18 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9304061938.AA13638@dino.alias.com> Subject: Re: EIDs and Security To: big-Internet@munnari.oz.au Date: Tue, 6 Apr 1993 16:38:15 -0400 In-Reply-To: <9304060140.AA03841@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 5, 93 09:40:42 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 749 MetaComment: For every sample issue that comes up here, there are two solutions offered by the list membership. One uses EIDs and the other uses some other existing system, or some sort of kludge. Personally, I would rather have *one* solution to many problems, rather than many solutions to many problems. Especially given that EIDs seem useful enough to be applicable to problems we haven't even thought of yet. My $0.02, -- Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON action, there is an equal | chk@alias.com (work-related mail) and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address) program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet) From owner-Big-Internet@munnari.oz.au Wed Apr 7 06:38:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23681; Wed, 7 Apr 1993 06:38:29 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23678; Wed, 7 Apr 1993 06:38:21 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-Internet@munnari.oz.au; Tue, 6 Apr 93 16:38:11 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for chk@alias.com; Tue, 6 Apr 93 16:38:10 EDT Date: Tue, 6 Apr 93 16:38:10 EDT From: francis@thumper.bellcore.com (Paul Francis (formally Paul Tsuchiya)) Message-Id: <9304062038.AA03223@tsuchiya.bellcore.com> To: big-Internet@munnari.oz.au, chk@alias.com Subject: Re: EIDs and Security > > For every sample issue that comes up here, there are two solutions offered > by the list membership. One uses EIDs and the other uses some other existing > system, or some sort of kludge. > I agree with this. It does appear that one can do anything without EIDs that one can do with EIDs. In many cases doing it "without" an EID involves adding what essentially is an EID.... For me, the issue is not to avoid EIDs if there is any other way to do it, but rather to consider what is the benefit and cost of an EID versus various custom solutions. In designing various features into Pip, I have found time and time that the EID makes things easier. A general statement I can make is that it gives me complete freedom to play around with the "addressing" information (that is, the routing directive). What are the costs of an EID? In the case of Pip, the main cost is including them in every packet. This isn't a forwarding cost, since the router doesn't look at the EID unless it has to. Rather, it is a header size cost. Given that we have to do header compression for slow links anyway, I don't see the larger header as prohibitive. Another cost that has come up is the cost of administering another number space. But, it seems that this cost must be borne to administer the multicast group IDs anyway, so I'm not sure that this represents additional cost over the non-EID case. Also, the same organizations that assign addresses can assign EIDs, so it is not as though you are duplicating every aspect of administration. Then, there is the general cost of dealing with the EID--in DNS, in routers, and so on. My intuition is that this cost is worth the benefit...... PX From owner-big-internet@munnari.oz.au Wed Apr 7 07:01:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24573; Wed, 7 Apr 1993 07:01:54 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304062101.24573@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19195; Wed, 7 Apr 1993 04:26:33 +1000 (from ULLMANN@PROCESS.COM) Date: Tue, 6 Apr 1993 14:22 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au, wagner@sirius.process.com Subject: Re: (ex) re: EIDs... Hi Dave, Okay, I'll be patient. Forgive me if I continue to suspect you haven't read ipv7-03 yet. (;-) I'm going to try to answer, but please let's keep in mind the bandwidth problems of email forae, and the idiots-at-odds problem ... first: **TILT** :-) The TCP extensions are okay as proof of concept; they show that TCP (the abstract method, not the v4 protocol) works in the domains under consideration. It now needs to be built in; we don't want to continue to run extensions in an ever increasing number of cases. We will interoperate with the installed base of course, using exactly the same technique as we use between v4 and v7 at the IP layer. --- When you say you "spent many months going over interaction scenarios" that is what worries me: it looks like it is about 2 orders of magnitude too complicated, and probably (IMHO) too complex to get right (consider Godel for a moment :-). Our systems are already complex enough that their complexity is _not_ bounded; it behooves us to strive for the maximum simplicity at the start. IPv7 doesn't _need_ an "IPAE". (Funny, there is this IPv4 option by that name ... :-) Can a single-stack SIP-native host talk directly to an IPv4 host, calling a stateless conversion for each IPv4 datagram that happens to arrive, and calling the opposite conversion just prior to sending the datagram to the unmodified IPv4 host? Can unmodified (i.e. _not_ recompiled) v4 software run on the SIP-native host? --- Remember, I'm not bashing anything, just pointing out things. We don't need rebuttal wars; the readers can go see for themselves :-) --- While you are considering scenarios, look at this one: (we'll call it, say, "The Real World" :-) Your customer has 10,000 TCP/IP hosts installed, perhaps 50% are PCs and such that weren't even installed by any "corporate" center. They come from at least a dozen vendors, including you, and the other vendors are not going to coordinate deployment schedules with you. This customer is not a network company. They manufacture things. The net is a tool. They don't want to understand it. More to the point, they want _not_ to understand it. They have other work to do. You need to ship out a new software version, that now does TNG, without placing any constraints on what order the upgrades of your customer's systems occur, because they won't tolerate any. Most of the systems will be upgraded by people with no knowledge that the world is changing down in the depths somewhere. The v4 hosts must continue to work with no changes, either software or configuration, and the (now) TNG hosts must work _with_the_configuration_ they had before the upgrade. At the same time, this customer expects your upgraded software to take them all the way into the next generation of networks, where there will be semi-continuous use of 2-5Mbytes/second of bandwidth per seat. (If that last is too abstract, picture your average Joe sitting on his couch channel-surfing. That is what the Internet looks like in 5 years. Not that soon you say? In that case the Internet is going to be choking on the dust of whatever _is_ doing it ... :-) Best Regards, Robert From owner-big-internet@munnari.oz.au Wed Apr 7 09:14:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29874; Wed, 7 Apr 1993 09:14:07 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27178; Wed, 7 Apr 1993 08:08:42 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-Internet@munnari.oz.au; Tue, 6 Apr 93 18:08:21 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for jnc@ginger.lcs.mit.edu; Tue, 6 Apr 93 18:08:20 EDT Date: Tue, 6 Apr 93 18:08:20 EDT From: francis@thumper.bellcore.com (Paul Francis (formally Paul Tsuchiya)) Message-Id: <9304062208.AA03695@tsuchiya.bellcore.com> To: big-Internet@munnari.oz.au, chk@alias.com, francis@thumper.bellcore.com, jnc@ginger.lcs.mit.edu Subject: Re: EIDs and Security > > Ah, but if PIP had flows, then you could leave out the addresses and do cache > lookups using the EID as a tag, and as KRE pointed out, the EID will usually > be *shorter* than the address (and the EID is fixed length to boot :-). I > know, I know, you don't agree, but I couldn't resist the chance to hassle > you! :-) > Well, I do agree......just not 100%..... But, for scaling reasons you want to be able to manage flows both with per-flow tracking and with "flow-buckets" tracking. For the latter, you still need the hierarchical address.... PX From owner-big-internet@munnari.oz.au Wed Apr 7 09:40:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01302; Wed, 7 Apr 1993 09:40:57 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26852; Wed, 7 Apr 1993 08:03:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12624; Tue, 6 Apr 93 18:02:54 -0400 Date: Tue, 6 Apr 93 18:02:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304062202.AA12624@ginger.lcs.mit.edu> To: big-Internet@munnari.oz.au, chk@alias.com, francis@thumper.bellcore.com Subject: Re: EIDs and Security Cc: jnc@ginger.lcs.mit.edu In many cases doing it "without" an EID involves adding what essentially is an EID.... Exactly. As I mentioned, all the schemes which use the IP SR Option to do mobility basically makes the destination IP 'address' in the packet an EID, and the 'real' destination address is in the SR Option. In designing various features into Pip, I have found time and time that the EID makes things easier. Again, no surprise here. As a general system design principle, the closer you keep each mechanism to the purpose it was designed for, the better it works. Addresses were designed to be used by the routing, not identify moving hosts, etc, etc, etc. This isn't a forwarding cost, since the router doesn't look at the EID unless it has to. Ah, but if PIP had flows, then you could leave out the addresses and do cache lookups using the EID as a tag, and as KRE pointed out, the EID will usually be *shorter* than the address (and the EID is fixed length to boot :-). I know, I know, you don't agree, but I couldn't resist the chance to hassle you! :-) My intuition is that this cost is worth the benefit...... Me too, but it's hard to quantify for people who want things quantified. Producing a good result using intuition based on long study of the art is is the challenge of system design.... Noel From owner-big-internet@munnari.oz.au Wed Apr 7 13:13:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10721; Wed, 7 Apr 1993 13:13:21 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02064; Wed, 7 Apr 1993 10:00:31 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA23902; Tue, 6 Apr 93 17:00:14 -0700 Message-Id: <9304070000.AA23902@Mordor.Stanford.EDU> To: ULLMANN@PROCESS.COM (Robert L Ullmann) Cc: big-internet@munnari.oz.au, wagner@sirius.process.com Subject: Re: (ex) re: EIDs... Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 06 Apr 93 14:22:00 -0400. <9304061826.AA15177@Mordor.Stanford.EDU> Date: Tue, 06 Apr 93 17:00:13 -0700 From: Dave Crocker X-Mts: smtp Robert, It's probably worth noting that the debate that you and I are having -- or the "clarification" -- is clearly pertaining to basic points of intention in which we seem to be in full agreement, i.e., the need to minmize the impact on the installed base. I believe that the approaches that you SIP/IPAE are taking, in that regard, are far more similar than different, particularly in contrast with TUBA or PIP. ---- Included message: The TCP extensions are okay as proof of concept; they show that My understanding was that the TCP work was intended as considerably more than proof of concept. I thought, infact, that Large Windows had formal status. Having said that, I will skip all further conversation about TCP. It is unrelated to the routing and addressing crisis, and I'm not competent on the new TCP work. Both are compelling points, for me... When you say you "spent many months going over interaction scenarios" that is what worries me: it looks like it is about 2 orders of magnitude too complicated, and probably (IMHO) too complex to Well, I didn't say the months were all fun and games. In fact, we were not pleased to see the level of requirement that careful attention to transition imposed on us. Since I had been heavily involved in designs for TCP-to-OSI transition, none of this came as a surprise. Still, the details definitely were burdensome. As to the belief that the details are not needed, I will first comment that we had forceful proponents for your point of view throughout the debates. And the concern for the complexity was revisited a number of times. Each time, the decision was that the various pieces nailed down one or several kinds of transition support that would be unreasonable to leave out. Can a single-stack SIP-native host talk directly to an IPv4 host, calling a stateless conversion for each IPv4 datagram that happens to arrive, and calling the opposite conversion just prior to sending the datagram to the unmodified IPv4 host? The simple answer is yes. That is exactly what it can do. That is what at least 3 of the existing implementations already do. Better still, the nature of the destination address, even if it is a SIP address, will tell it whether the destination is IPv4 native or supports SIP. I should note, however, that there is a curious wrinkle that impinges on TCP, and that pertains to the checksum calculation. So, SIP has the SIP TCP make the right calculation, if the destination uses IPv4 or SIP. Now for truth in labeling: I will note that a host which can do what you describe is not technically "single stack" since you've specified that it can handle SIP and IPv4. Can unmodified (i.e. _not_ recompiled) v4 software run on the SIP-native host? This is primarily a function of the application programming interface and not a matter of protocol support. I believe that one or two of the existing SIP/IPAE implementations support unmodified apps. While you are considering scenarios, look at this one: (we'll call it, say, "The Real World" :-) Hope it's ok if I don't pursue the detail of your example. SIP/IPAE were driven almost entirely by our view of the needs of the various user bases (end-user, sys admin, net ops, product support, ...). Dave From owner-big-internet@munnari.oz.au Wed Apr 7 14:02:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13393; Wed, 7 Apr 1993 14:02:58 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05162; Wed, 7 Apr 1993 11:09:07 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11942>; Tue, 6 Apr 1993 18:08:32 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 6 Apr 1993 18:08:29 -0700 To: ULLMANN@process.com (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Ullmann's IPv7 (was Re: (ex) re: EIDs...) In-Reply-To: Your message of "Tue, 06 Apr 93 08:57:00 PDT." <9304061602.13628@munnari.oz.au> Date: Tue, 6 Apr 1993 18:08:26 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Apr6.180829pdt.12171@skylark.parc.xerox.com> Robert, I like your IPv7; it is very similar in philosophy and in important details to SIP. However, I think that your claim that IPv7 requires no transition plan whereas SIP has a complicated transition plan (IPAE) is quite misleading. As far as I can tell (and I have read each of your internet drafts), IPv7 as you have specified it does *not* address the primary problem that is motivating the urgent adoption of a new IP! That problem is the exponentially increasing routing overhead in the national and international backbone routers. (The problem of eventual exhaustion of the IP network number space is also important, but less urgent.) You specify that IPv4 address are translated to IPv7 addresses by adding 4 bytes of constant: a prefix of 126.0.0 and a penultimate byte of value 1. Thus, you make the addresses larger, but don't add any useful hierarchy to them. Under your proposal, the backbone routers will still need to maintain routes to the existing 10,000 IPv4 networks, plus the 10,000 more that will be installed next year, plus the 20,000 in the year after that, and so on. So, IPv7 can do stateless translation, but at the cost of not solving the main problem! SIP obviously could do (or, rather, not do) the same. The only stateful part of SIP/IPv4 interoperation is the cache of mappings from IPv4 network numbers to SIP address prefixes, which serves the purpose of aggregating the tens of thousands of IPv4 network numbers into a smaller number of higher-level clusters, upon which wide-area routing can be done more efficiently. Now, perhaps you think that backbone routing overhead is not really a problem, and can be handled simply by applying "more thrust" for the next five years, while all systems requiring global connectivity are upgraded to IPv7. If so, I think you have a major selling job to do to convince the rest of the community (especially the backbone providers) that that is a viable approach. It would be great if you succeeded in convincing them, because then we could eliminate the mapping cache from IPv4-SIP translation -- we don't like it any more than you do. The other significant difference between IPAE's and IPv7's approaches for IPv4 interoperation is that we use encapsulation for tunneling through IPv4 infrastructure, whereas you use a new IPv4 option to accomplish the same end. I would claim that encapsulation is safer (are you *sure* that no existing routers will discard packets with unknown options, or mangle their contents, or crash?) and more efficient (yes, handling of IPv4 packets with options really *is* much less efficient than handling of packets with no options, in many existing routers). Back to scaling issues, your IPv7 addresses have a 3-byte adminstrative domain (AD) prefix, but you say "it is only an administrative device. Most routing will be done on the entire 48 bit AD+network number, ...". It sounds like you really are an advocate of very large, flat global routing tables in the long term (i.e., not just during the transition). If so, that ought to be made very clear to anyone trying to evaluate your proposal, relative to the other proposals for IPng, and you need to justify that approach. If not, you need to explain how an adminstrative-only (non- "topology-coercive") 3-byte prefix will enable efficient, scalable routing. (Yes, I did read your RAP draft too, and I didn't find the answer there.) Regarding TCP improvements, those are orthogonal to, and independent of, any IP-layer improvements. If you can get TCP improvements added to the list of "Official Next Generation IP Requirements", and convince everyone that your interoperable TCP extensions are significantly better than the already implemented (Jacobson/Braden) interoperable TCP extensions, fine. We can adopt your TCP extensions for use over any of the IPng candidates. Finally, you said, "SIP's 'payload' looks pretty confused to me". Would it help to clear up the confusion if the Payload Type field were renamed "Next Header Type", or is there some deeper problem that you perceive there? Steve From owner-big-internet@munnari.oz.au Wed Apr 7 21:45:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04155; Wed, 7 Apr 1993 21:45:32 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304071145.4155@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB27571; Wed, 7 Apr 1993 18:44:14 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Apr 1993 09:43:40 +0100 To: Dave Crocker Cc: ULLMANN@PROCESS.COM (Robert L Ullmann), big-internet@munnari.oz.au, wagner@PROCESS.COM Subject: Re: (ex) re: EIDs... In-Reply-To: Your message of "Tue, 06 Apr 93 09:57:57 PDT." <9304061657.AA13406@Mordor.Stanford.EDU> Date: Wed, 07 Apr 93 09:43:37 +0100 From: Jon Crowcroft >First, modifications to TCP are entirely orthongonal to the IPv4 routing >and addressing crisis. not true - for instance TCP depemnds on MSL enforcement in IP _ SIP and PIP have different TTL mechanisms... other problems may arise unforeseen... >Second, I was under the impression that the TCP Large Windows folks >had a working, accepted, installed enhancement. sure, but only for window scaling - the timestamp selack stuff isnt stable/decided - plus also what about multicast TCP ? one possibile implkementaiton is to use the IPv7 level to collect acks rarther than have an implosion - that would be a RADICAL change to ipv7 >Addressing looks increasingly like a topic generic to all the >alternatives. By and large, I believe any of them can be required to the number of connections also affects PCB Lookup strategies...as does the size of the address (e.g. used to hash ipv7 src+dst + ports into a PCB location)... at least... jon From owner-Big-Internet@munnari.oz.au Thu Apr 8 00:53:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10964; Thu, 8 Apr 1993 00:53:52 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10953; Thu, 8 Apr 1993 00:53:41 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA15001; Wed, 7 Apr 93 10:50:08 -0400 Date: Wed, 7 Apr 93 10:50:08 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9304071450.AA15001@er.doe.gov> To: big-Internet@munnari.oz.au, chk@alias.com, francis@thumper.bellcore.com Subject: Re: EIDs and Security From owner-Big-Internet@munnari.oz.au Tue Apr 6 18:22:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23681; Wed, 7 Apr 1993 06:38:29 +1000 (from owner-Big-Internet) Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23678; Wed, 7 Apr 1993 06:38:21 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-Internet@munnari.oz.au; Tue, 6 Apr 93 16:38:11 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for chk@alias.com; Tue, 6 Apr 93 16:38:10 EDT Date: Tue, 6 Apr 93 16:38:10 EDT From: francis@thumper.bellcore.com (Paul Francis (formally Paul Tsuchiya)) Message-Id: <9304062038.AA03223@tsuchiya.bellcore.com> To: big-Internet@munnari.oz.au, chk@alias.com Subject: Re: EIDs and Security > > For every sample issue that comes up here, there are two solutions offered > by the list membership. One uses EIDs and the other uses some other existing > system, or some sort of kludge. > I agree with this. It does appear that one can do anything without EIDs that one can do with EIDs. In many cases doing it "without" an EID involves adding what essentially is an EID.... For me, the issue is not to avoid EIDs if there is any other way to do it, but rather to consider what is the benefit and cost of an EID versus various custom solutions. In designing various features into Pip, I have found time and time that the EID makes things easier. A general statement I can make is that it gives me complete freedom to play around with the "addressing" information (that is, the routing directive). What are the costs of an EID? In the case of Pip, the main cost is including them in every packet. This isn't a forwarding cost, since the router doesn't look at the EID unless it has to. Rather, it is a header size cost. Given that we have to do header compression for slow links anyway, I don't see the larger header as prohibitive. Another cost that has come up is the cost of administering another number space. But, it seems that this cost must be borne to administer the multicast group IDs anyway, so I'm not sure that this represents additional cost over the non-EID case. Also, the same organizations that assign addresses can assign EIDs, so it is not as though you are duplicating every aspect of administration. Then, there is the general cost of dealing with the EID--in DNS, in routers, and so on. My intuition is that this cost is worth the benefit...... PX In fact one advantage of EID's is that they can be assigned in some sense by different organizations... at least at some level in the hierarchy. This avoids the battle between the network providers and the end sites over control of the address/eid. DH From owner-Big-Internet@munnari.oz.au Thu Apr 8 01:16:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11773; Thu, 8 Apr 1993 01:16:29 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11765; Thu, 8 Apr 1993 01:16:21 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-Internet@munnari.oz.au; Wed, 7 Apr 93 11:16:03 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for hitchcoc@oerv01.er.doe.gov; Wed, 7 Apr 93 11:16:01 EDT Date: Wed, 7 Apr 93 11:16:01 EDT From: francis@thumper.bellcore.com (Paul Francis (formerly Paul Tsuchiya)) Message-Id: <9304071516.AA04794@tsuchiya.bellcore.com> To: big-Internet@munnari.oz.au, chk@alias.com, francis@thumper.bellcore.com, hitchcoc@oerv01.er.doe.gov Subject: Re: EIDs and Security > > In fact one advantage of EID's is that they can be assigned in some sense > by different organizations... at least at some level in the hierarchy. > > This avoids the battle between the network providers and the end sites over > control of the address/eid. > DH > I agree, it may help. If an organization has it's own ID space, it might lessen the sensitivity to non-organizational (provider-rooted) addresses. The plan is for Pip EIDs to be assigned organizationally..... PX From owner-Big-Internet@munnari.oz.au Thu Apr 8 02:27:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14656; Thu, 8 Apr 1993 02:31:37 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14412; Thu, 8 Apr 1993 02:27:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16700; Wed, 7 Apr 93 12:21:54 -0400 Date: Wed, 7 Apr 93 12:21:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304071621.AA16700@ginger.lcs.mit.edu> To: ULLMANN@process.com, deering@parc.xerox.com Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu As far as I can tell ... IPv7 as you have specified it does *not* address the primary problem that is motivating the urgent adoption of a new IP! That problem is the exponentially increasing routing overhead in the national and international backbone routers. ... you make the addresses larger, but don't add any useful hierarchy to them. Steve, this is a bit unfair, isn't it? CIDR is going to help tremendously with the routing overhead scaling problem by allowing many more layers of abstraction; this is true of IPv4 addresses, and thus should be true of his transitional IPv7 addresses. True, CIDR isn't going to fix every routing problem (there are still all the policy routing issues), but it will help a lot with the scaling. The problem of eventual exhaustion of the IP network number space is also important, but less urgent. It seems to me that this is the real issue which is driving replacement of IPv4. The 32 bits just isn't going to be enough sooner (if interpreted as an address, with consequent wastage, even with CIDR) or later (if interpreted as an EID). If eventually (once IPv7 is reasonably widely deployed) IPv7 address prefixes can assume values other than 126.0.0, won't this provide enough room to grow? The only stateful part of SIP/IPv4 interoperation is the cache of mappings from IPv4 network numbers to SIP address prefixes, which serves the purpose of aggregating the tens of thousands of IPv4 network numbers into a smaller number of higher-level clusters, upon which wide-area routing can be done more efficiently. Once again, you seem to be assuming CIDR won't have any impact, perhaps because you think people won't renumber? I suggest that since CIDR is being deployed today (with BGP and the various IGP's which suport masks, including OSPF and RIP-2), when the routing s### *really* hits the fan, people will pick this up and use it as the only *available* deployed tool, even at the cost of renumbering their hosts. All of the above should not be taken as being endorsement of his IPv7; just trying to understand exactly what is going on. Noel From owner-Big-Internet@munnari.oz.au Thu Apr 8 02:42:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15081; Thu, 8 Apr 1993 02:43:07 +1000 (from owner-Big-Internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15078; Thu, 8 Apr 1993 02:42:52 +1000 (from minshall@wc.novell.com) Received: from mitl.MITL.Research.Panasonic.COM by wc.novell.com (4.1/smi4.1.1.v91190) id AB19964; Wed, 7 Apr 93 09:42:33 PDT Date: Wed, 7 Apr 93 09:42:33 PDT Message-Id: <9304071642.AB19964@wc.novell.com> To: big-internet@munnari.oz.au From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com Subject: Re: address vs. EID, revisited... Just my penny's worth of thought, here (and fairly sketchy, too): We have a mechanism for assigning EID's which appear in every packet, now. Which is to say, IPv4 addresses. The address space may not be big enough, but (... nimrod'ish sentiments here, if i understand nimrod). What the mobility proposals point to is vaguely a situation in which there is an "address" and an EID. The only thing is that the EID has, if you will, "fall back" topological significance. I.e., if you can't quite figure out where that pesky host has gotten to, you can try routing via the EID. Hosts that are in their "home" subnet have EID == address. Multi-homed hosts can, using "existing" mechanisms, choose an EID out of all of their interfaces, then use "mobility" to snarf up packets on their other interfaces (though this works well only in the "mobility" scheme of propagating host routes). Greg Minshall From owner-Big-Internet@munnari.oz.au Thu Apr 8 03:38:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17150; Thu, 8 Apr 1993 03:38:50 +1000 (from owner-Big-Internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17145; Thu, 8 Apr 1993 03:38:41 +1000 (from dab@berserkly.cray.com) Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.17) id AA25017; Wed, 7 Apr 93 12:38:35 CDT Received: by frenzy.cray.com id AA15431; 4.1/CRI-5.6; Wed, 7 Apr 93 12:38:59 CDT Date: Wed, 7 Apr 93 12:38:59 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9304071738.AA15431@frenzy.cray.com> To: dcrocker@Mordor.Stanford.EDU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: (ex) re: EIDs... Cc: big-internet@munnari.oz.au, ULLMANN@PROCESS.COM, wagner@PROCESS.COM > >Second, I was under the impression that the TCP Large Windows folks > >had a working, accepted, installed enhancement. > > sure, but only for window scaling - the timestamp selack stuff isnt > stable/decided - plus also what about multicast TCP ? TCP Window scaling and Timestamps are stable. The selective ACK is the only piece that is still in process. My understanding is that SACK will be stable once real data is available from current implementation experiments. These changes take TCP well into the near future of gigabit networks, and faster. For dealing with faster future networks, TCP only has problems due to fundamental issues that TCP can't do anything about. Fixing them will probably require a different or modified transport protocol, that operates very different from TCP today... (I'm eluding to transfering large chunks of data, megabytes to gigabytes, where the data set can be transfered in less than one RTT, due to high speed, long delay networks...) Multicast TCP is a separate transport. It might look a lot like TCP, but it is a different beast. -David Borman, dab@cray.com From owner-Big-Internet@munnari.oz.au Thu Apr 8 04:02:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17912; Thu, 8 Apr 1993 04:03:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304071803.17912@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17894; Thu, 8 Apr 1993 04:02:35 +1000 (from ULLMANN@PROCESS.COM) Date: Wed, 7 Apr 1993 13:57 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Cc: wagner@sirius.process.com Subject: IPv7 ... Hi, Interesting. I had not realized how profoundly different the philosophies were between IPv7 and SIP. And how it shows up in the little details, even though they look similar on the surface. Things like SIP intentionally making a SIP host distinguishable from an IPv4 host by address, and building explicit mechanism on it, while IPv7 is designed to make IPv4 and IPv7 addresses indistinguishible and prohibits use of a distinction except when determining (at link/ARP layer) if the _adjacent_ host is not capable of dealing with the v7 format. -- Dave C.: I was making a distinction between a host (a) that actually runs the protocol modules of two stacks, and (b) a host that runs only the modules in one stack, and then converts the PDUs (possibly after leaving the host) to get something that looks like the "other stack". I called (a) "dual-stack", and (b) "not-dual-stack", since the essential distinction of (b) is that it doesn't actually ever do the "other" stack as a protocol machine. Since you have weakened our vocabulary by demanding that both be called "dual-stack", exactly what terminology would you suggest to make this critical distinction? -- If there is *any* problem orthogonal to addressing, it is routing. Attempting to fix a routing "crisis" by building something into addresses is exactly the wrong direction to go. Even the class system built into IPv4 ended up getting in the way. We want to instead push "addresses" further and further toward being just the EIDs. (I say "crisis" in quotes because I find it amusing that 10K or 20K nets is considered a problem. Those numbers are small. Very small. You are going to have to do better. It isn't difficult to design entirely flat routing for 10^9 nets if you get serious about network planning and administration, and it is only going to get easier.) -- TCP: Note that TCP/IPv7 doesn't replace the TCP performance extensions, (specifically: you want to use SACK and the improved RT options as needed; I didn't try to define the formats for v7 yet.) What it does do is clean up the window scaling and sequence-space-wrap problems by providing proper field sizes. It is slightly annoying that the v4-v7 conversion can't convert the (v4) scale extension to the equivalent window on v7, but the state information just isn't there. Best Regards, Robert From owner-big-internet@munnari.oz.au Thu Apr 8 05:46:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21780; Thu, 8 Apr 1993 05:54:07 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19147; Thu, 8 Apr 1993 04:39:30 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12099>; Wed, 7 Apr 1993 11:38:40 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 7 Apr 1993 11:38:33 -0700 To: Jon Crowcroft Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: (ex) re: EIDs... In-Reply-To: Your message of "Wed, 07 Apr 93 01:43:37 PDT." <9304071145.4155@munnari.oz.au> Date: Wed, 7 Apr 1993 11:38:21 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Apr7.113833pdt.12171@skylark.parc.xerox.com> > >First, modifications to TCP are entirely orthongonal to the IPv4 routing > >and addressing crisis. > > not true - for instance TCP depemnds on MSL enforcement in IP... TCP may depend on it, but IP isn't providing it, at least not in the current Internet. Steve From owner-Big-Internet@munnari.oz.au Thu Apr 8 07:03:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24631; Thu, 8 Apr 1993 07:03:58 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24624; Thu, 8 Apr 1993 07:03:40 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12168>; Wed, 7 Apr 1993 14:03:29 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 7 Apr 1993 14:03:26 -0700 To: ULLMANN@process.com (Robert L Ullmann) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: IPv7 ... In-Reply-To: Your message of "Wed, 07 Apr 93 10:57:00 PDT." <9304071803.17912@munnari.oz.au> Date: Wed, 7 Apr 1993 14:03:24 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Apr7.140326pdt.12171@skylark.parc.xerox.com> > ...IPv7 is designed to make IPv4 and IPv7 addresses indistinguishible and > prohibits use of a distinction except when determining (at link/ARP layer) > if the _adjacent_ host is not capable of dealing with the v7 format. Robert, Please explain how things work when an IPv7 host in one administrative domain wants to send a packet to an IPv7 host in a different AD, and the path must pass through IPv4-only hosts. Exactly what does the IPv4 packet originated by the IPv7 source contain in its address fields and any added IPv4 options? > If there is *any* problem orthogonal to addressing, it is routing. This is what the OSI folks apparently thought too, when NSAPs were first invented. If you want to assign addresses without concern for their "routability", you'll either have to do global, flat routing or put something else in packets that helps the routing, such as an explicit source route or a "frotz" (Dave Clark's term for the thing that serves the role of an "address" once you have tuned addresses into EIDs.) I don't see any frotzes in IPv7, so are you suggesting that IPv7 should be handled by doing global, flat routing? > Attempting to fix a routing "crisis" by building something into addresses > is exactly the wrong direction to go. Even the class system built into > IPv4 ended up getting in the way. This is something that puzzled me in your draft. You claimed that the IPv4 address "class" system was designed to aid routing. Where did you get that idea? The "class" system simply allowed there to be more than 256 (minus 1 or 2) IP network numbers, essentially increasing the size of the flat network number space. > (I say "crisis" in quotes because I find it amusing that 10K or 20K nets is > considered a problem. Those numbers are small. Very small. You are going to > have to do better. It isn't difficult to design entirely flat routing for > 10^9 nets if you get serious about network planning and administration, and > it is only going to get easier.) I'm willing to believe that. (I have myself advocated doing flat routing to tens of millions of sites within a metro area.) But just saying "it isn't difficult" is not sufficient. Please tell us exactly how networks should be planned and administered such that flat routing to 10^9 nets is feasible, and how we are going to move from our current technology base (in which 10,000 nets *is* a problem) to your proposed infrastructure, before the Internet melts. (Please treat this as a request for education, not a disagreement.) Steve From owner-Big-Internet@munnari.oz.au Thu Apr 8 08:05:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26740; Thu, 8 Apr 1993 08:05:40 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304072205.26740@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26736; Thu, 8 Apr 1993 08:05:19 +1000 (from ULLMANN@PROCESS.COM) Date: Wed, 7 Apr 1993 18:03 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, wagner@sirius.process.com Subject: Re: IPv7 ... Hi, Please explain how things work when an IPv7 host in one administrative domain wants to send a packet to an IPv7 host in a different AD, and the path must pass through IPv4-only hosts. Exactly what does the IPv4 packet originated by the IPv7 source contain in its address fields and any added IPv4 options? IP host delta.process.com (126.0.0.192.42.95.1.68) sending to (some imaginary host) 104.5.6.200.1.1.1.17. When the datagram runs into the first IPv4 host/router, it becomes: source: 192.42.95.68 dest: 200.1.1.17 AE option (104.5.6/1, 126.0.0/1) And this is routed in the IPv4 world. Note that (sect 10.1) IPv7 srip: "An IPv7 host will be able to connect to another IPv7 host anywhere in the internet even though most of the paths and routers are IPv4, and still use the full addressing. This will continue to work until non-unique network numbers are assigned, by which time most of the infrastructure should be IPv7." I.e. as long as the "backbone" infrastructure is IPv4, the network numbers still need to be unique. (But then that is almost a tautology :-) -- the role of an "address" once you have tuned addresses into EIDs.) I don't see any frotzes in IPv7, so are you suggesting that IPv7 should be handled by doing global, flat routing? Ah, could be. But I'm not exactly fond of that. More like binding EID->routing info->FrI/FlowI setup. (You understand Nimrod, right? Like nearly everyone else? :-) Better to say that there will end up being some backstop at AD level (AD foo is NANP LATA 617/508*, it mostly should be routed toward Eastern Massachusetts :-); a max of 10^7 flat within and across ADs, and whatever local magic within each network. (*note that a LATA is an _administrative_ entity, within the delegation rooted in ITU authority.) -- This is something that puzzled me in your draft. You claimed that the IPv4 address "class" system was designed to aid routing. Where did you get that idea? The "class" system simply allowed there to be more than 256 (minus 1 or 2) IP network numbers, essentially increasing the size of the flat network number space. Because it did something non-obvious at the time: represented the catenet structure in the addresses. We take that for granted now, but it was an explicit statement of: "we aren't going to route all IMPS flat any more, there will be multiple catenated nets, and that structure will be represented _thusly_." Then we found there ought to be subnets, and supernets, and that the catenet model was too limited, and with some pain eradicated the assumptions built in to do catenet routing (static or whatnot.) -- I'm willing to believe that. (I have myself advocated doing flat routing to tens of millions of sites within a metro area.) But just saying "it isn't difficult" is not sufficient. Please tell us exactly how networks should be planned and administered such that flat routing to 10^9 nets is feasible, and how we are going to move from our current technology base (in which 10,000 nets *is* a problem) to your proposed infrastructure, before the Internet melts. (Please treat this as a request for education, not a disagreement.) There are a few dozen different combinations, depending on what sort of network you are using to do your backbone. (Which means it will be done different ways :-) With something like SMDS, you might use RFC1183/sect3 DNS. With. say, the ISDN telephone net at a lower layer: (I will ask a small understanding from people familiar with the NANP routing area; I sin by oversimplifying, but I don't have the time to write the 200 page treatise needed to do justice ;-). The NANP (North American Numbering Plan) area of the telephone network consists of about 200,000 exchanges. (first simplification; we assume the pre-NXX system is full, and treat multiple co-located exchanges as distinct.) Each exchange has up to 10,000 physical subscriber circuits. Just for fun: suppose you were using the physical inter-exchange cable plant of the combined NANP area to provide direct IPv7 service, where each address was 48:16 (net:host) with no internal syntax in the net number? (We'll assume exactly 10^9 net access points.) We can share it with the voice service, until the voice service is all running _over_ IP. We look only at the "border problem": how do you locate all the connected networks. Ma Bell already solved the (easier) interior problem: we have all those lines labeled and routed. You want your number routed? Fine, it will cost you $25/year admin fee for each candidate access point (you want more than one, unless you are a single residence, plugged to a single exchange), plus $10 for each change order. Note these don't change fast, they change as physical access lines are turned up or transit policies administratively altered. Just register it at least one hour in advance. Send an EDI message. Revenue: 25 Billion Dollars/Year. Distribute the map of network number->circuit number (aka interior net number:subscriber line) to all switches. Total information: 16 bytes * 1G entries is 16 Gbytes. Use a DS3-rate spanning tree, replay the whole table to all exchange centers every hour. Datagrams are routed toward the nearest (in interior view) candidate access point for the leaf network. If the access point selected is down, "tunnel" (target-route) the traffic to another candidate access point for the net. Best Regards, Robert From owner-Big-Internet@munnari.oz.au Thu Apr 8 08:28:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27610; Thu, 8 Apr 1993 08:28:44 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27607; Thu, 8 Apr 1993 08:28:33 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12214>; Wed, 7 Apr 1993 15:28:04 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 7 Apr 1993 15:28:00 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, ULLMANN@process.com, deering@parc.xerox.com Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) In-Reply-To: Your message of "Wed, 07 Apr 93 09:21:54 PDT." <9304071621.AA16700@ginger.lcs.mit.edu> Date: Wed, 7 Apr 1993 15:27:45 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Apr7.152800pdt.12171@skylark.parc.xerox.com> > Steve, this is a bit unfair, isn't it? CIDR is going to help tremendously > with the routing overhead scaling problem by allowing many more layers of > abstraction; ... Noel, I don't think that IPv4 renumbering will happen, so I don't think CIDR will do anything except reduce the *rate of growth* of backbone overhead. All the existing routes will still need to be maintained, plus lots of new ones. For CIDR to make a big difference, you have to convince a significant majority of sites to renumber *all* of their IP boxes, to numbers that are (or appear to be) less "portable" than their current numbers (since the new ones will contain provider prefixes). I just don't think that will fly. If, instead, we deployed SIP/IPAE translating routers (or some other kind of routers that translated IP network numbers into more hierarchical numbers) in only the border and backbone routers, we could immediately cut the backbone routing overhead to a fraction of the current load, without changing any subscriber addresses. That would eliminate the routing overhead problem, and we could proceed to deal with the longer-term IPv4 network number exhaustion problem by upgrading those subscriber hosts and routers that require global connectivity to use the new version of IP. Boxes that don't require global connectivity need never be upgraded, and need never have their IP addresses changed. This is an approach that I think could work, because it does not require changes to a huge number of end hosts in a very short period of time. > If eventually (once IPv7 is reasonably widely deployed) IPv7 address > prefixes can assume values other than 126.0.0, won't this provide enough > room to grow? Of course, I believe that 64 bits will provide enough room to address all the IP systems in the universe. That's not an issue that distinguishes IPv7 from SIP. The important question is how those addresses are structured and what the consequences of that structure are for routing, both during the transition and in the long term. Robert is placing his faith in our ability to handle flat routing to orders of magnitude more destinations than we currently do. The SIP/IPAE proposal does not depend on that ability. Steve From owner-Big-Internet@munnari.oz.au Fri Apr 9 03:22:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12011; Fri, 9 Apr 1993 03:23:00 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12008; Fri, 9 Apr 1993 03:22:49 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA29553; Thu, 8 Apr 93 10:22:40 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA27872 for big-internet@munnari.oz.au; Thu, 8 Apr 93 13:24:22 -0400 Message-Id: <9304081724.AA27872@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: big-internet@munnari.oz.au Subject: Re: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) In-Reply-To: Your message of "Thu, 08 Apr 93 12:58:21 EDT." Date: Thu, 08 Apr 93 13:24:22 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp >From: US1RMC::"deering@parc.xerox.com" "Steve Deering" 7-APR-1993 22:10 >To: jnc@ginger.lcs.mit.edu (Noel Chiappa) >CC: big-internet@munnari.oz.au, ULLMANN@process.com, deering@parc.xerox.com >Subj: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) > > ... > >Noel, > >I don't think that IPv4 renumbering will happen, so I don't think CIDR will >do anything except reduce the *rate of growth* of backbone overhead. All >the existing routes will still need to be maintained, plus lots of new ones. A quibble: I thought someone had done some checking and found that CIDR will permit at least a factor of two reduction in routing tables at backbone node right now. Admittedly that's more much in the long run but getting a year's breathing room seems like it's worth quite a bit with the current IPv4 situation. > > ... > >Steve Donald From owner-Big-Internet@munnari.oz.au Fri Apr 9 05:12:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15922; Fri, 9 Apr 1993 05:13:12 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15916; Fri, 9 Apr 1993 05:12:55 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA04322; Thu, 8 Apr 93 12:12:48 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA22200; Thu, 8 Apr 93 15:12:46 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA12997; Thu, 8 Apr 93 15:12:45 EDT Date: Thu, 8 Apr 93 15:12:45 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9304081912.AA12997@fenway.andr.UB.com> To: big-internet@munnari.oz.au, dee@skidrow.ljo.dec.com Subject: CIDR net table reductions (was Re: Re: Ullmann's IPv7) >A quibble: I thought someone had done some checking and found that >CIDR will permit at least a factor of two reduction in routing tables >at backbone node right now.. Actually, I was just working up some shell scripts to generate an estimate on that now. I still have to hack on it a bit more before I give a more precise number, but right now it should represent almost a drop of one-third (7333 networks covering 10693 net numbers). One should note, however, that this assumes that the tables will only be compressed. It seems entirely possible, however, that the opposite could occur. For example: the machine that I'm sending this message from is on the East Coast of the US within a Class B network number. Our connection to the Internet is off on the West Coast. Once CIDR is deployed, it should be possible for the East Coast subnets to be announced just as widely as the West Coast Class B number, with the "best-match" rules in routers making the distinction between the two. -- Frank From owner-Big-Internet@munnari.oz.au Fri Apr 9 05:29:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16496; Fri, 9 Apr 1993 05:30:06 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16490; Fri, 9 Apr 1993 05:29:53 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA08990; Thu, 8 Apr 93 12:29:27 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA28492 for big-internet@munnari.oz.au; Thu, 8 Apr 93 15:31:12 -0400 Message-Id: <9304081931.AA28492@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: solensky@andr.UB.com (Frank T Solensky) Cc: big-internet@munnari.oz.au, dee@skidrow.ljo.dec.com Subject: Re: CIDR net table reductions (was Re: Re: Ullmann's IPv7) In-Reply-To: Your message of "Thu, 08 Apr 93 15:12:45 EDT." <9304081912.AA12997@fenway.andr.UB.com> Date: Thu, 08 Apr 93 15:31:12 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: solensky@andr.UB.com (Frank T Solensky) >One should note, however, that this assumes that the tables will only >be compressed. It seems entirely possible, however, that the opposite >could occur. For example: the machine that I'm sending this message >from is on the East Coast of the US within a Class B network number. >Our connection to the Internet is off on the West Coast. Once CIDR is >deployed, it should be possible for the East Coast subnets to be announced >just as widely as the West Coast Class B number, with the "best-match" >rules in routers making the distinction between the two. Sounds like ever stronger arguments for charging people money for route advertisements or otherwise doing *something* to push back on such expansion... > -- Frank Donald From owner-Big-Internet@munnari.oz.au Fri Apr 9 07:22:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20278; Fri, 9 Apr 1993 07:23:12 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304082123.20278@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20273; Fri, 9 Apr 1993 07:22:40 +1000 (from ULLMANN@PROCESS.COM) Date: Thu, 8 Apr 1993 17:19 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: IPAE(s) Hi Steve, To go back to another question you asked, about the IPv4 AE option: We haven't run real extensive tests since the option number (147) wasn't assigned by IANA until two weeks ago; I didn't think sending out datagrams with an invented option number was polite, even if they were always well-formed. You can telnet to port 25 on 126.0.0.192.42.95.1.68 (delta.process.com) if you want to see some IPv4+AE option datagrams come back to you. The option field should read 93 0a 7e 00 00 01 7e 00 00 01 (00 00). If you try to ping it, you may notice that at least one ping client makes at least one invalid assumption (and doesn't recognize the replies.) Why 25 (SMTP), and not something like 13 (DAYTIME)? That brings me to the question for you. (And Dave C., who thinks I can't come up with an interoperation problem for IPAE/SIP ;-) So you have these SIP datagrams being tunneled around. What happens when you run into an IPv4 router with security filters? -- Those datagrams from Delta carry the TL-PID and port numbers in the places expected by the IPv4 routers. Best Regards, Robert From owner-Big-Internet@munnari.oz.au Fri Apr 9 09:04:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23826; Fri, 9 Apr 1993 09:05:21 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23815; Fri, 9 Apr 1993 09:04:54 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA14624; Thu, 8 Apr 93 16:04:40 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA22857; Thu, 8 Apr 93 19:04:37 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA13448; Thu, 8 Apr 93 19:04:37 EDT Date: Thu, 8 Apr 93 19:04:37 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9304082304.AA13448@fenway.andr.UB.com> To: big-internet@munnari.oz.au, ULLMANN@PROCESS.COM Subject: Re: IPAE(s) >So you have these SIP datagrams being tunneled around. What happens >when you run into an IPv4 router with security filters? If you've got your router configured to drop IPAE packacts, exactly what you'd _want_ to happen. What's the problem? From owner-big-internet@munnari.oz.au Fri Apr 9 12:40:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02521; Fri, 9 Apr 1993 12:40:33 +1000 (from owner-big-internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29085; Fri, 9 Apr 1993 11:12:29 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA19666; Thu, 8 Apr 93 18:12:23 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA23069; Thu, 8 Apr 93 21:12:21 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA13683; Thu, 8 Apr 93 21:12:21 EDT Date: Thu, 8 Apr 93 21:12:21 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9304090112.AA13683@fenway.andr.UB.com> To: big-internet@munnari.oz.au, ULLMANN@PROCESS.COM Subject: Re: IPAE(s) I'm going to take the liberty of assuming that Rob had intended to CC: the rest of the list in case anyone else out there might have also missed the point he was making an earlier message.. -- Frank ----- Begin Included Message ----- From ULLMANN@PROCESS.COM Thu Apr 8 20:18:47 1993 Return-Path: Date: Thu, 8 Apr 1993 20:14 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: solensky@andr.UB.com Subject: Re: IPAE(s) Content-Length: 278 X-Lines: 9 So it fails-safe. That's good. Except: I'm going to have trouble using a local SIP host to talk a permitted protocol (e.g. 25) to a remote SIP host, because there isn't anything to tell them that they have to revert to pure IPv4 to get through. IPv7, by contrast, works. Rob ----- End Included Message ----- I still contend, however, that this is a configuration error if you have a local host uses SIP and your router prevents these packets from getting through.. Also, any router that is SIP-capable should also be able to receive a SIP packet and encapsulate it inside an IP packet if that's the only way to get through. -- Frank From owner-Big-Internet@munnari.oz.au Sat Apr 10 00:08:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02227; Sat, 10 Apr 1993 00:08:32 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02224; Sat, 10 Apr 1993 00:08:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29307; Fri, 9 Apr 93 10:08:17 -0400 Date: Fri, 9 Apr 93 10:08:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304091408.AA29307@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, minshall@wc.novell.com Subject: Re: address vs. EID, revisited... Cc: jnc@ginger.lcs.mit.edu What the mobility proposals point to is vaguely a situation in which there is an "address" and an EID. Pretty much true. Even the ideas in which you have a 'base station', and the packet gets sent there first, and wrapped up in *another* IP packet with the real current address for the host, the IP address in the inner packet is the "EID" and the IP address in the outer packet is the "address". There's always something which says where the host really is (the "address") and something which uniquely identifies the host, no matter where it is (the "EID"). We have a mechanism for assigning EID's which appear in every packet, now. Which is to say, IPv4 addresses. ... Multi-homed hosts can, using "existing" mechanisms, choose an EID out of all of their interfaces, then use "mobility" to snarf up packets on their other interfaces... All of this is true. (If a mobile host mechanism is agreed upon and deployed, *some* multi-homed host problems could be solved by use of that. Others would not e.g. how do you choose *which* of a MH-host's addresses to use?) Where I part paths is i) the degree to which I want to *explicitly* separate the "address" and "endpoint identifier" functions, and ii) which of the two should be in the packet by default. I prefer an explicit split because I reckon it will provide more flexibility, and be less subject to confusion. (I.e. when is the "destination address" field an "address", and when is it an "endpoint name"?) If we don't have an explicit place to put the "address" functionality (when it is not in the "destination address" field of the packet), sooner or later some group of clowns who are designing some extended capabilty which needs to separate the "address" and "endpoint name" function will put this information in a *different* place from where some other extended capability (e.g. mobile hosts) put it. They will justify this on efficiency or some other grounds, local to their application. Then, whenever the "destination address" field is just an EID, you will have to look in one of several places to find the "address". It also allows us to introduce a new address format without changing all the hosts. I reckon the EID should be the thing that's in the packet by default, since increasingly people do not (and will not as flows come to pass), parse the address (as an address), and use it to look up stuff in the routing table, on each packet. Even now, the average commercial router does not look up the destination address in the full routing table on each packet. For efficiency reasons, they cache direct "destination"->"outbound local network header" entries. This is particularly true as we deploy "best match" routing (with variable length subnets, and CIDR), and you cannot rely on a single look into the routing table to give you the ultimate answer. This will become even more true in the future, as flows arrive, and as different flows to the same destination address, for policy, type of service, and resource allocation reasons, take different paths through the network. A shortish, fixed length cache tag for fast lookup in the flow database will be what we need, and a globally unique flow id constructed using EID's is that tag (and I don't believe shortish, fixed lenght addresses will be plausible for the global Internet). Sure, there will be packets which are not part of flows, which need to have the address in them as well (and I don't think routers will be doing EID-> address translations to handle those cases), but they will be the exception, not the rule. Finally, again, making EID's be the thing in every packet allows us to introduce a new address format without changing all the hosts. Noel From owner-Big-Internet@munnari.oz.au Sat Apr 10 00:25:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02862; Sat, 10 Apr 1993 00:25:09 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02859; Sat, 10 Apr 1993 00:25:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29378; Fri, 9 Apr 93 10:24:07 -0400 Date: Fri, 9 Apr 93 10:24:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304091424.AA29378@ginger.lcs.mit.edu> To: ULLMANN@process.com, big-internet@munnari.oz.au Subject: Re: IPv7 ... Cc: jnc@ginger.lcs.mit.edu If there is *any* problem orthogonal to addressing, it is routing. ... Attempting to fix a routing "crisis" by building something into addresses is exactly the wrong direction to go. ... We want to instead push "addresses" further and further toward being just the EIDs. ... It isn't difficult to design entirely flat routing for 10^9 nets if you get serious about network planning and administration, and it is only going to get easier. This is an interesting set of comments. My understanding is that routing (by which I mean the calculation of paths through the network) has an overhead cost of *greater than* O(D), where D is the number of destinations which are being tracked - i.e. I don't know of any routing algorithm which is even that efficient. Do you believe this, and if not, could you explain why? Most people seem to believe we need to get the overhead cost of routing to be something nearer O(logN), where N is the number of things in the network. (Heck, for purposes of argument, we could probably even make it O(N), but I think not everyone woudl agree with that.) Do you disagree with this? This pretty clearly seems to indicate that we can't use flat routing; i.e. we can't track every thing in the network as a separate destination. The only way anyone seems to know of to do that is to aggregate groups of things together, via hierarchical addressing, so that the number of destinations being tracked doesn't grow as fast as the number of things in the network. Can you comment on this in relation to your statements above? Noel From owner-Big-Internet@munnari.oz.au Sat Apr 10 01:33:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05811; Sat, 10 Apr 1993 01:33:42 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05808; Sat, 10 Apr 1993 01:33:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29798; Fri, 9 Apr 93 11:33:23 -0400 Date: Fri, 9 Apr 93 11:33:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304091533.AA29798@ginger.lcs.mit.edu> To: dee@skidrow.ljo.dec.com Subject: Re: CIDR net table reductions (was Re: Re: Ullmann's IPv7) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu >One should note, however, that this assumes that the tables will only >be compressed. It seems entirely possible, however, that the opposite >could occur. Ow. I hadn't thought of that. Since people tend to do anything the architecture just doesn't flat out not allow, we can look forward to this happening. Sounds like ever stronger arguments for charging people money for route advertisements or otherwise doing *something* to push back on such expansion... Yes, within CIDR for sure. Within pure topology based addressing schemes (such as Nimrod), this issue can be partially addressed explicity, allowing better control by costing. Noel From owner-big-internet@munnari.oz.au Sat Apr 10 02:22:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07721; Sat, 10 Apr 1993 02:22:30 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03935; Sat, 10 Apr 1993 00:51:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29497; Fri, 9 Apr 93 10:47:05 -0400 Date: Fri, 9 Apr 93 10:47:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304091447.AA29497@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Cc: jnc@ginger.lcs.mit.edu If, instead, we deployed SIP/IPAE translating routers (or some other kind of routers that translated IP network numbers into more hierarchical numbers) in only the border and backbone routers, we could immediately cut the backbone routing overhead to a fraction of the current load, without changing any subscriber addresses. Hmm, isn't this effectively a NAT scheme of the type classed as "end-map" and "large-map" in my NAT taxonomy document? (Sorry, the S-NAT name is already allocated! :-) I suppose not really, since the 32 bit numbers are still globally unique, and you don't translate them anywhere except in the IP header. Still, this is going to be an awful big table in each border router (or some other mechanism); you don't see the maintainence as an issue? Boxes that don't require global connectivity need never be upgraded, and need never have their IP addresses changed. I guess this is true, since the thing you are proposing isn't a true NAT; if it were, these boxes could communicate with anyone. Of course, I believe that 64 bits will provide enough room to address all the IP systems in the universe. Without taking issue with your claim, is it accurate to rephrase it as: "64 bits will provide enough room to address all the places IP systems will plug into the Internet, in addition to providing enough room to uniquely identify all the IP systems in the universe." Noel From owner-Big-Internet@munnari.oz.au Sat Apr 10 04:02:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11288; Sat, 10 Apr 1993 04:03:59 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304091803.11288@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11241; Sat, 10 Apr 1993 04:02:56 +1000 (from ULLMANN@PROCESS.COM) Date: Fri, 9 Apr 1993 14:00 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: IPAE(s) I'm going to take the liberty of assuming that Rob had intended to CC: the rest of the list in case anyone else out there might have also missed the point he was making an earlier message.. -- Frank Sorry, I know how to operate a mailer. The message was a private reply, not intended for the list. I had wanted people to think it through for themselves, and thus understand it better. (If you, dear reader, would like to do that, just stop reading _right_here_ ;-) ;-) -- I still contend, however, that this is a configuration error if you have a local host uses SIP and your router prevents these packets from getting through.. Also, any router that is SIP-capable should also be able to receive a SIP packet and encapsulate it inside an IP packet if that's the only way to get through. -- Frank So go fix the "error", add [permit TL-PID=SIP]. You've now entirely bypassed the security filters. Think about it some more please. The IPv4+AE <--> IPv7 conversion is designed to put the transport and application protocol numbers in exactly the places expected by the v4 filters, so they will operate properly. Best Regards, Robert From owner-Big-Internet@munnari.oz.au Sat Apr 10 05:20:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13999; Sat, 10 Apr 1993 05:20:43 +1000 (from owner-Big-Internet) Return-Path: Received: from eitech.eitech.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13993; Sat, 10 Apr 1993 05:20:34 +1000 (from ams@eitech.com) Received: from scuba.eitech.com by eitech.com (4.1/SMI-4.1) id AA00949; Fri, 9 Apr 93 12:16:02 PDT Date: Fri, 9 Apr 93 12:16:02 PDT From: ams@eitech.com (Allan M Schiffman) Message-Id: <9304091916.AA00949@eitech.com> To: jnc@ginger.lcs.mit.edu Subject: Re: IPv7 ... Cc: ULLMANN@process.com, big-internet@munnari.oz.au > Most people seem to believe we need to get the overhead cost of routing to be > something nearer O(logN), where N is the number of things in the network. > (Heck, for purposes of argument, we could probably even make it O(N), but I > think not everyone woudl agree with that.) Do you disagree with this? > > This pretty clearly seems to indicate that we can't use flat routing; i.e. we > can't track every thing in the network as a separate destination. The only > way anyone seems to know of to do that is to aggregate groups of things > together, via hierarchical addressing, so that the number of destinations > being tracked doesn't grow as fast as the number of things in the network. Seems to me that having hierarchical addressing with a fixed number of levels and a stable average fan-out for each level doesn't do anything to change the routing problem from O(N) -- all it does is change a constant in the cost calculation. Of course, if the constant is comparable to the upper bound for N, it might make all the difference. I think if you wanted to make a hierarchical routing algorithm O(log N) you'd have to arrange to make the product of the number of levels and the average fan-out scale with log N. Something close to this might happen anyway, I suppose. For example, one might predict that as the number of addresses double, the average size of networks double. But you could argue it the other way just as well. -Allan From owner-Big-Internet@munnari.oz.au Sat Apr 10 06:16:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16090; Sat, 10 Apr 1993 06:16:50 +1000 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16087; Sat, 10 Apr 1993 06:16:18 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA21078 (5.65/6.02); Fri, 9 Apr 93 16:13:39 -0400 Date: Fri, 9 Apr 93 16:13:39 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9304092013.AA21078@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: address vs. EID, revisited... In-Reply-To: <9304091408.AA29307@ginger.lcs.mit.edu> References: <9304091408.AA29307@ginger.lcs.mit.edu> < (If a mobile host mechanism is agreed upon and deployed, *some* > multi-homed host problems could be solved by use of that. Others > would not e.g. how do you choose *which* of a MH-host's addresses to > use?) I am going to comment just on this specific issue, which---although it is something of a tangent---might have something useful to add. First of all, I would note that you don't have to know which address to use; some router on the way to the other interface should send you an ICMP redirect if there's a better way. And despite everything I tell people about why they shouldn't run routing processes on hosts that aren't routers, this is one application where that can help. Secondly, there are name resolvers (like recent versions of BIND) which have a notion of ``preferred'' networks; for example, my configuration file specifies: sortlist 132.198.4.0 132.198.1.0 132.198.3.0 This means that, given a host with multiple A records, it should prefer the address on subnet 1 to the address on subnet 3 to the address on subnet 10 (because it's not listed). While it could use a bit more flexibility (I'd like to be able tell it `* 26.0.0.0'---i.e., avoid the MILNET at all costs), it's not a bad mechanism. The only problem, of course, is that it's a static configuration file. We need to develop a system whereby this information can be calculated and distributed automatically, based on site-specific criteria; alternatively, it should be possible to have this information fall directly out of the address (e.g., in PIP, pick the shortest address of the list). -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-big-internet@munnari.oz.au Sat Apr 10 09:25:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24339; Sat, 10 Apr 1993 09:26:15 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16176; Sat, 10 Apr 1993 06:20:44 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA08443 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Fri, 9 Apr 1993 16:19:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 9 Apr 1993 16:19:32 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 9 Apr 1993 16:19:32 -0400 Date: Fri, 9 Apr 1993 16:19:23 -0400 From: Dennis Ferguson Message-Id: <199304092019.AA50180@foo.ans.net> To: ULLMANN@process.com Subject: Re: FWD: Re: IPAE(s) Cc: big-internet@munnari.oz.au Robert, > So go fix the "error", add [permit TL-PID=SIP]. You've now entirely bypassed > the security filters. > > Think about it some more please. The IPv4+AE <--> IPv7 conversion is designed > to put the transport and application protocol numbers in exactly the places > expected by the v4 filters, so they will operate properly. No matter how I look at this, it seems to me that what you are describing is not a problem with SIP/IP encapsulation, but rather is a problem with an insufficiently general security filter. There are lots of neat things I can think of doing with IP-in-IP encapsulation, having nothing to do with SIP, that would also cause difficulties for security filters like this, but I don't think it is reasonable that I be prevented from doing them to preserve peoples' investment in security filters. Better would be to fix the security filters to accomodate the applications. Note that I have a security filtering router which drops packets carrying IP options to prevent people from doing funny things with source routed packets and the like. As shipping information you need to do the IPv4+AE-->IPv7 conversion as IP options breaks through my security filter it seems to me that one could use the same argument you are making to demonstrate that IPv7-IPv4 compatibility is defective as well. I don't think I'd buy the argument here either. Dennis Ferguson From owner-big-internet@munnari.oz.au Sat Apr 10 09:59:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25892; Sat, 10 Apr 1993 10:00:09 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16620; Sat, 10 Apr 1993 06:32:01 +1000 (from davin@phila.bellcore.com) Received: from phila.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 9 Apr 93 16:31:41 EDT Received: from localhost.bellcore.com by phila.bellcore.com (4.1/4.7) id for minshall@wc.novell.com; Fri, 9 Apr 93 16:32:45 EDT Message-Id: <9304092032.AA02709@phila.bellcore.com> From: "James R. (Chuck) Davin" To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, minshall@wc.novell.com Subject: Re: address vs. EID, revisited... In-Reply-To: Your message of Fri, 09 Apr 93 10:08:17 -0400. <9304091408.AA29307@ginger.lcs.mit.edu> Date: Fri, 09 Apr 93 16:32:43 -0400 Sender: davin@phila.bellcore.com Hi Noel, A tangential nit. While I agree with most of your reasons for isolating EID semantics from addressing, I wasn't sure I completely followed your comment about the role of the EID in identifying flows. It is clear that one could easily forge a globally unique flow id by combining a globally unique EID with some other locally unique cruft. It is also clear that one could easily forge a flow id that is (locally) unique to a particular link (and preserve that property end-to-end by successive, very cheap translations). Of course, one could also do both at the same time (not as gratuitous as it sounds, actually). What was not clear from your comment was whether or not you assumed that the "shortish fixed length cache tag" (below) was locally unique. A short, locally unique flow id requires indexing a table. A long, globally unique flow id requires a hash plus a few long name comparisons. An "almost unique" flow id (long id with precomputed hash hint) requires a few long name comparisons. Doesn't seem like the "almost unique" flow id gets you into a significantly better performance regime than just plain long flow ids. Certainly not as good as a short, locally unique id. There are lotsa good reasons for the EID/address split, but I'm not sure that fast flow lookup is at the top of my list. Indeed, it may be less attractive to use EIDs to disambiguate flow hash tags than it is to abbreviate EID information by locally unique flow ids. It is probably the case that a flowish paradigm makes EIDs cheaper, not vice versa. Regards, Chuck > Date: Fri, 9 Apr 93 10:08:17 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Message-Id: <9304091408.AA29307@ginger.lcs.mit.edu> > To: big-internet@munnari.oz.au, minshall@wc.novell.com > Subject: Re: address vs. EID, revisited... > Cc: jnc@ginger.lcs.mit.edu > I reckon the EID should be the thing that's in the packet by default, since > increasingly people do not (and will not as flows come to pass), parse the > address (as an address), and use it to look up stuff in the routing table, on > each packet. > Even now, the average commercial router does not look up the destination > address in the full routing table on each packet. For efficiency reasons, they > cache direct "destination"->"outbound local network header" entries. This is > particularly true as we deploy "best match" routing (with variable length > subnets, and CIDR), and you cannot rely on a single look into the routing > table to give you the ultimate answer. > This will become even more true in the future, as flows arrive, and as > different flows to the same destination address, for policy, type of service, > and resource allocation reasons, take different paths through the network. A > shortish, fixed length cache tag for fast lookup in the flow database will be > what we need, and a globally unique flow id constructed using EID's is that > tag (and I don't believe shortish, fixed lenght addresses will be plausible > for the global Internet). > > Noel From owner-Big-Internet@munnari.oz.au Sat Apr 10 19:43:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21394; Sat, 10 Apr 1993 19:43:47 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21391; Sat, 10 Apr 1993 19:43:37 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sat, 10 Apr 1993 02:43:16 -0700 Date: Sat, 10 Apr 1993 02:43:16 -0700 From: Tony Li Message-Id: <199304100943.AA11063@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au Subject: Re: CIDR (was other stuff...) In article <93Apr7.152800pdt.12171@skylark.parc.xerox.com> deering@parc.xerox.com (Steve Deering) writes: I don't think that IPv4 renumbering will happen, I'll take a really radical viewpoint: if it doesn't happen, then IPng doesn't ever happen either. Logic: IP:tng without renumbering will not fly, politically or commercially. If you do provider based addressing, you clearly need it for provider changes. Or you need it when your organization's internal topology changes. Or when your organization runs out of (your now conservatively allocated) address space. Whatever mechanism is developed to do renumbering for IP:tng, it will also be portable to IPv4. As the customer base ALREADY wants this technology, renumbering will be deployed for IPv4 long before IP:tng ever is. so I don't think CIDR will do anything except reduce the *rate of growth* of backbone overhead. Which is it's primary goal and will suffice for quite a while. One of the very nice additional properties that CIDR has is that it allows more efficient address space allocation. If I need the equialent of 30 class C's, I can get them, and it's no worse outside my provider than if I had a class B. This is a _big_ improvement. And because address allocation is now done thru the provider, I need not grab a whole bunch of extra space so that I can get it when I want it. I can just ask for it as I use it. Market pressure on the provider insures that my request is serviced promptly. All the existing routes will still need to be maintained, plus lots of new ones. Bzzt. There aren't a lot of new ones. And even if you're willing to ignore the aggregation of existing routes, that's NOT the problem. We know how to deal with the existing routes.... For CIDR to make a big difference, you have to convince a significant majority of sites to renumber *all* of their IP boxes, to numbers that are (or appear to be) less "portable" than their current numbers (since the new ones will contain provider prefixes). I just don't think that will fly. CIDR makes a big difference without any renumbering because it does fix the routing scaling problem. That's the first truck that is going to hit us. Of course, I believe that 64 bits will provide enough room to address all the IP systems in the universe. Even after lotsa bits get wasted on administrative stuff? I'm just not convinced that we can make _that_ much of a difference. Do you believe that we can really get >1% address utilization? If so, can you defend this? I certainly can't. Provocative thought for the day: I believe that CIDR (with help from other tools, such as renumbering, more thrust, NAT, etc.) can conceivably carry IPv4 for two decades. This is gut feeling, not something I can defend. If this is true, it is a significant chunk of the expected lifetime of IP:tng. And perhaps more importantly, it is long enough that we will discover new requirements for the network protocol. If this does happen, will we find ourselves contemplating IP:tng++ (IP:dsn? ;-) before IP:tng ever really gets off the ground? What is the point in even engineering IP:tng at this point? Shouldn't it be off in the IRTF? The emporer has no clothes. Tony From owner-Big-Internet@munnari.oz.au Sun Apr 11 02:51:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05951; Sun, 11 Apr 1993 02:51:15 +1000 (from owner-Big-Internet) Return-Path: Received: from shiva2.cac.washington.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05947; Sun, 11 Apr 1993 02:51:10 +1000 (from gray@cac.washington.edu) Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27802; Sat, 10 Apr 93 09:50:58 -0700 Date: Sat, 10 Apr 1993 09:19:51 -0700 (PDT) From: Terry Gray Sender: Terry Gray Reply-To: Terry Gray Subject: Re: CIDR (was other stuff...) To: Tony Li Cc: deering@parc.xerox.com, big-internet@munnari.oz.au In-Reply-To: <199304100943.AA11063@lager.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sat, 10 Apr 1993, Tony Li wrote: > > (Steve Deering) writes: > > > I don't think that IPv4 renumbering will happen, > > I'll take a really radical viewpoint: if it doesn't happen, then IPng > doesn't ever happen either. > > Logic: IP:tng without renumbering will not fly, politically or > commercially. If you do provider based addressing, you clearly need it for > provider changes. Or you need it when your organization's internal > topology changes. Or when your organization runs out of (your now > conservatively allocated) address space. Whatever mechanism is developed > to do renumbering for IP:tng, it will also be portable to IPv4. As the > customer base ALREADY wants this technology, renumbering will be deployed > for IPv4 long before IP:tng ever is. Tony and Steve, Putting my Service Provider hat on, my first choice is not having to change end systems *at all*, neither software nor addresses. But if I can't have that, the thing I would *most* like to see come out of IPNG --other than "painless migration"-- is an address/ID model with the following properties: 1. Either a. it uses MAC layer addresses for host IDs, or b. it gives me 32 bits of my own to assign as inefficiently as I want. 2. Changing the "upper bits" (e.g. a provider address) only requires changing *one* entry in DNS-NG. 3. It preserves the notion of "layer 3 firewalls" so that faults, broadcast storms, address assignment errors, etc, are contained to one network segment. I was under the impression that TUBA offered 1a and SIP offered 1b... no? I've just been toying with the new (for me) view that installing an entirely new stack with auto-configuration may prove to be easier than manually updating all the IP addresses buried in config files. (A possible exception is DOS, where there are lots of apps with the stack embedded in the app, e.g. NCSA Telnet.) Note that I'm ignoring the question of software cost... but if correct, this assertion has one important implication: it opens up the prospect of using the existing v4 32bit address for inter-domain routing, and doing something different within the local site. Until now I had argued for making minimal changes to the end systems for the obvious reasons, but if we *must* change end-system addresses, and if changing the stack isn't necessarily any harder than changing the address (maybe easier), then I think the game changes quite a bit. Suppose, for example, that border routers stuff the MAC address into an IPv4 option field, the backbone carries the packet to either the destination AS border, or maybe even subnet border, and that last router looks at the option field and sends it on its way... come to think of it, this strategy might even let the end-system software stay the same for quite some time, while gaining the low order 8bits (typical subnet size) back for dealing with network number exhaustion. (WARNING: I'm thinking out loud here, and none of this may hold water. I'm just trying to explore what happens if I turn my earlier assumptions upside down and say maybe we should leave the current backbone infrastructure alone and see what could be done by tweaking site routers and/or end systems.) > Provocative thought for the day: I believe that CIDR (with help from other > tools, such as renumbering, more thrust, NAT, etc.) can conceivably carry > IPv4 for two decades. I'm *very* skeptical of this. One of the reasons I think the address exhaustion issue is just as important as the route explosion problem is because we are already beginning to see the politics and economics of scarcity showing up in address administration. This tends to have terrible distorting effects on the way systems evolve, and I'm anxious to quickly get to a point where addresses are abundant again. -teg From owner-Big-Internet@munnari.oz.au Sun Apr 11 03:52:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07254; Sun, 11 Apr 1993 03:53:25 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07180; Sun, 11 Apr 1993 03:52:50 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11877>; Sat, 10 Apr 1993 10:52:28 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sat, 10 Apr 1993 10:52:21 -0700 To: Tony Li Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: CIDR (was other stuff...) In-Reply-To: Your message of "Sat, 10 Apr 93 02:43:16 PDT." <199304100943.AA11063@lager.cisco.com> Date: Sat, 10 Apr 1993 10:52:14 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Apr10.105221pdt.12171@skylark.parc.xerox.com> Tony, Let me respond to the following comment out of the middle of your message first, since it seems to embody a very common misunderstanding about the adequacy of 64-bit addresses: > Of course, I believe that 64 bits will provide enough room to address > all the IP systems in the universe. > > Even after lotsa bits get wasted on administrative stuff? I'm just not > convinced that we can make _that_ much of a difference. Do you believe > that we can really get >1% address utilization? If so, can you defend > this? I certainly can't. 1% utilization of a 64-bit address space is 10^17 addresses! If the goal is 10^12 devices, an allocation efficiency of .00001% suffices. A 64-bit address space really is rather large. Now, back to your other comments, in order: > ...Whatever mechanism is developed to do renumbering for IP:tng, it will > also be portable to IPv4... What lead you to that leap of logic? Or are you proposing that as a requirement for IP:tng auto-renumbering -- that it be portable to IPv4? I *think* that rules out the mechanisms proposed by TUBA and Pip folks for dynamically detecting when a remote host's address has changed, which (as I understand it) depends on EIDs, which IPv4 doesn't have. (mandatory footnote: for SIP, we are proposing to use the same mechanism used to support mobile hosts, which does not depend on EIDs.) > so I don't think CIDR will > do anything except reduce the *rate of growth* of backbone overhead. > > Which is it's primary goal and will suffice for quite a while. I thought that the backbone providers were having trouble with the *current* overhead, perhaps more severely in terms of human overhead to manage the current number of nets than in terms of router or bandwidth overhead. Is that not the case? Are the providers content to see continuing growth in the backbone routing tables? > ...One of the very nice additional properties that CIDR has is that it > allows more efficient address space allocation. If I need the equialent > of 30 class C's, I can get them, and it's no worse outside my provider > than if I had a class B. This is a _big_ improvement. That's an improvement in terms of address space efficiency, but not in terms of backbone routing overhead. Whether a site gets a single class B or a CIDR-ized set of class Cs, it's the same cost to the backbones (assuming the backbone routers support CIDR, of course). > And because address allocation is now done thru the provider,... To what degree is that true? Are *all* new IP network number assignments being done out of blocks allocated to providers? > Provocative thought for the day: I believe that CIDR (with help from other > tools, such as renumbering, more thrust, NAT, etc.) can conceivably carry > IPv4 for two decades. This is gut feeling, not something I can defend. OK, so now we've each expressed our gut feelings. Whose do you want to bet the Internet's survival on? > The emporer has no clothes. Or the subject is blind... Steve From owner-Big-Internet@munnari.oz.au Sun Apr 11 11:53:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21663; Sun, 11 Apr 1993 11:53:58 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21659; Sun, 11 Apr 1993 11:53:45 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sat, 10 Apr 1993 18:53:35 -0700 Date: Sat, 10 Apr 1993 18:53:35 -0700 From: Tony Li Message-Id: <199304110153.AA02714@lager.cisco.com> To: gray@cac.washington.edu Cc: deering@parc.xerox.com, big-internet@munnari.oz.au In-Reply-To: Terry Gray's message of Sat, 10 Apr 1993 09:19:51 -0700 (PDT) Subject: CIDR (was other stuff...) Putting my Service Provider hat on, my first choice is not having to change end systems *at all*, neither software nor addresses. NAT will almost give you this. You will have to change DNS servers. 1. Either a. it uses MAC layer addresses for host IDs, or b. it gives me 32 bits of my own to assign as inefficiently as I want. NAT gives each of your customers 32 bits to play with (less one class A). 2. Changing the "upper bits" (e.g. a provider address) only requires changing *one* entry in DNS-NG. Changing providers with NAT means just renumbering one box. 3. It preserves the notion of "layer 3 firewalls" so that faults, broadcast storms, address assignment errors, etc, are contained to one network segment. No change. In fact, things are improved since the NAT itself is really a level 3 firewall itself. Suppose, for example, that border routers stuff the MAC address into an IPv4 option field, the backbone carries the packet to either the destination AS border, or maybe even subnet border, and that last router looks at the option field and sends it on its way... come to think of it, this strategy might even let the end-system software stay the same for quite some time, while gaining the low order 8bits (typical subnet size) back for dealing with network number exhaustion. (WARNING: I'm thinking out loud here, and none of this may hold water. I'm just trying to explore what happens if I turn my earlier assumptions upside down and say maybe we should leave the current backbone infrastructure alone and see what could be done by tweaking site routers and/or end systems.) Congratulations, you've reinvented (one way of doing) NAT. > Provocative thought for the day: I believe that CIDR (with help from other > tools, such as renumbering, more thrust, NAT, etc.) can conceivably carry > IPv4 for two decades. I'm *very* skeptical of this. One of the reasons I think the address exhaustion issue is just as important as the route explosion problem is because we are already beginning to see the politics and economics of scarcity showing up in address administration. This tends to have terrible distorting effects on the way systems evolve, and I'm anxious to quickly get to a point where addresses are abundant again. I think that CIDR helps a lot. NAT will make things downright cushy. Tony From owner-Big-Internet@munnari.oz.au Sun Apr 11 16:09:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29593; Sun, 11 Apr 1993 16:09:33 +1000 (from owner-Big-Internet) Return-Path: Received: from tea.eng.umd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29567; Sun, 11 Apr 1993 16:09:20 +1000 (from baccala@eng.umd.edu) Received: by tea.eng.umd.edu (5.65c/IDA-1.4.4) with SMTP id AA19844; Sun, 11 Apr 1993 02:09:12 -0400 Rcpt to:mailed to Message-Id: <199304110609.AA19844@tea.eng.umd.edu> To: Big-Internet@munnari.oz.au Subject: VLSM and reserved bits Date: Sun, 11 Apr 1993 02:09:11 -0400 From: "Brent W. Baccala" Forgive me if this is not the correct list to mail this to, but I'm pretty sure it'll reach the audience I'm seeking. I don't subscribe to your list, so please reply directly or at least cc me. I'm developing an intermediate TCP/IP routing course, and I'm having some difficulty reconsiling VLSM with my traditional view of all-0s and all-1s reserved bit fields. In particular, RFC-950 notes the interpretation of an all-zero field as meaning "this" and an all-one field as meaning "all". It goes on: It is useful to preserve and extend the interpretation of these special addresses in subnetted networks. This means the values of all zeros and all ones in the subnet field should not be assigned to actual (physical) subnets. Aside from trivial little issues like non-implementation of these features and ambiguity in exactly how they should be implemented, it seems to me that VLSM makes it impossible to even interpret the subnet field. An all-1s field to one host may be another host's mixed field (assuming the second host is configured with a longer subnet field). So can reserved patterns in subnet fields be interpreted? If not, is there any reason to promote non-assignment of these patterns? EXAMPLES (Class C addr; only last octet shown) -------- Address: 1110 0001 Mask #1: 1110 0000 This is.. what? All host #1s on all subnets? Mask #2: 1111 1000 Now it just looks like a normal address Is there any use for an all-subnets address without all-hosts to go along with it? Nobody implements all-subnets broadcast anyway, right? Address: 0001 0001 Mask #1: 1110 0000 Current subnet; host 17 Mask #2: 1111 1000 Subnet 16; host 1 Assume there really is a subnet 16. Do all masks need to have an all-1 high nibble to ensure they don't misinterpret subnet 16 as a local host? In general, if any subnet address has x leading bits that are all-1 or all-0, do all subnet masks on that network need to have at least x+1 leading 1s? Does anybody care about any of this? -bwb Brent W. Baccala baccala@eng.umd.edu From owner-Big-Internet@munnari.oz.au Sun Apr 11 17:23:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01968; Sun, 11 Apr 1993 17:23:27 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01965; Sun, 11 Apr 1993 17:23:17 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 11 Apr 1993 00:23:12 -0700 Date: Sun, 11 Apr 1993 00:23:12 -0700 From: Tony Li Message-Id: <199304110723.AA06328@lager.cisco.com> To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Sat, 10 Apr 1993 10:52:14 PDT <93Apr10.105221pdt.12171@skylark.parc.xerox.com> Subject: CIDR (was other stuff...) Let me respond to the following comment out of the middle of your message first, since it seems to embody a very common misunderstanding about the adequacy of 64-bit addresses: > Even after lotsa bits get wasted on administrative stuff? I'm just not > convinced that we can make _that_ much of a difference. Do you believe > that we can really get >1% address utilization? If so, can you defend > this? I certainly can't. 1% utilization of a 64-bit address space is 10^17 addresses! If the goal is 10^12 devices, an allocation efficiency of .00001% suffices. A 64-bit address space really is rather large. I'm not convinced that .00001% suffices if the addressing plan isn't done properly. For example, if a site administrator only ends up with 10 bits to play with, there will be many problems. Yeah, 64 bits is large, but is it large enough? I'll be more provocative: the size of the address space is IRRELEVANT until you tell me how it's going to get used. Proof: it would be trivial to concoct an addressing plan that used an entire NSAP but left only 8 bits for site usage. > ...Whatever mechanism is developed to do renumbering for IP:tng, it will > also be portable to IPv4... What lead you to that leap of logic? The fact that none of the proposals differ so significantly from IP that the technology would not port back. The key elements are that all entities have an address (possibly an interface, possibly a host) which is hierarchical in nature and that some analog to ES-IS would exist. Please note that renumbering is NOT the same problem as mobility. I thought that the backbone providers were having trouble with the *current* overhead, perhaps more severely in terms of human overhead to manage the current number of nets than in terms of router or bandwidth overhead. Is that not the case? Are the providers content to see continuing growth in the backbone routing tables? The problems, in no particular order, are that the rate of growth outstrips our ability to (economically) add thrust to the system, the ability of our routing protocols to reasonably manipulate the volume of information involved, and exceeds the ability of the administrative infrastructure to add talent to the management of the network. I have heard _no_ objections to the rate of growth proposed in the CIDR RFC (and new draft) and I can only assume that people are quite comfortable with it. That's an improvement in terms of address space efficiency, but not in terms of backbone routing overhead. Whether a site gets a single class B or a CIDR-ized set of class Cs, it's the same cost to the backbones (assuming the backbone routers support CIDR, of course). I think you misunderstand the entire point of CIDR. A site which gets a block of class C's from its provider adds _NOTHING_ to the backbone overhead. The provider advertises its entire block of class C networks as a single route. This is constant regardless of the number of actual sites that use compents of the aggregate that the provider advertises. Further, thanks to the continental level of aggregation, even adding another provider to a continent does not increase routing information outside of that continent. > Provocative thought for the day: I believe that CIDR (with help from other > tools, such as renumbering, more thrust, NAT, etc.) can conceivably carry > IPv4 for two decades. This is gut feeling, not something I can defend. OK, so now we've each expressed our gut feelings. Whose do you want to bet the Internet's survival on? Mine, of course. ;-) In reality, the problem is that you see this as a zero-sum game. It's not. Tony From owner-Big-Internet@munnari.oz.au Sun Apr 11 17:35:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02325; Sun, 11 Apr 1993 17:35:43 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02314; Sun, 11 Apr 1993 17:35:34 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 11 Apr 1993 00:35:14 -0700 Date: Sun, 11 Apr 1993 00:35:14 -0700 From: Tony Li Message-Id: <199304110735.AA06433@lager.cisco.com> To: baccala@eng.umd.edu Cc: big-internet@munnari.oz.au Subject: VLSM Brent, Interpreting broadcast addresses can only be done given local mask information. This has always been the case. For example, 131.108.255.0 may be an all ones subnet if my mask is 255.255.255.0. However, if my mask is 255.255.240.0, that's a perfectly legit host address. With VLSM, the only difference is that a router must perform the longest match routing lookup to determine the state of the address. If you need further assistance with this, cs@cisco.com is a more appropriate forum. Tony From owner-Big-Internet@munnari.oz.au Tue Apr 13 01:10:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00327; Tue, 13 Apr 1993 01:10:26 +1000 (from owner-Big-Internet) Return-Path: Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00324; Tue, 13 Apr 1993 01:10:18 +1000 (from jmh@anubis.network.com) Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA00173; Mon, 12 Apr 93 10:12:14 -0500 Received: from petunia.network.com by anubis.network.com (4.1/SMI-4.1) id AA25916; Mon, 12 Apr 93 09:17:28 CDT Date: Mon, 12 Apr 93 09:17:28 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9304121417.AA25916@anubis.network.com> To: big-internet@munnari.oz.au Subject: Progres? At the last IETF, I was struck by a combination of perceptions which, if correct, should allow us to proceeed much more smoothly. As Tony Li says, CIDR is going to work for now. (I would be surprised if it lasts for 20 years, but it is probably good enough to take the brunt of current growth.) Thus, the sky is not falling. Simultaneously, each of the IPVNext proposals are proceeding, and in fact each seems to be gathering support. They are each beginning to perform real experiments. Because each proposal must interoperate, somehow, with IPv4, there is a natural consequence. The experimentation can go on for quite a while in parrallel. A router or host can be involved in 0, 1, or more of these experiments, with no problem. The propoents can build tests in labs, prottype implementations, and even try to persuade providers to participate in expeerimentation. We do not need to decide now. This should let us all be much more cordial and cooperative, and that is indeed what I saw at the meeting. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation PS I suspect that many other people have reached this conclusion independently, but I have not seen it on the list. From owner-big-internet@munnari.oz.au Tue Apr 13 05:24:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08747; Tue, 13 Apr 1993 05:24:23 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304121924.8747@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06509; Tue, 13 Apr 1993 04:15:39 +1000 (from ULLMANN@PROCESS.COM) Date: Mon, 12 Apr 1993 14:14 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, ullmann@sirius.process.com Subject: Re: IPv7 ... (Noel Chiappa:) This is an interesting set of comments. My understanding is that routing (by which I mean the calculation of paths through the network) has an overhead cost of *greater than* O(D), where D is the number of destinations which are being tracked - i.e. I don't know of any routing algorithm which is even that efficient. Do you believe this, and if not, could you explain why? Most people seem to believe we need to get the overhead cost of routing to be something nearer O(logN), where N is the number of things in the network. (Heck, for purposes of argument, we could probably even make it O(N), but I think not everyone would agree with that.) Do you disagree with this? No, I don't disagree. But let's look at the _total_ cost of routing N destinations (whether a destination is a large-always-monolithic-to- the-outside net, or a single mobile host wandering about :-); i.e. the aggregate cost to all the routers. I think this is going to be about O(N log N) with any reasonable set of methods. There are two extremes, (both hard to get to in practice :-). One has log N routers (e.g. the spanning-tree logic in my blue-sky example) each having knowledge of all N destinations. The other has N routers, each with log N information about the net. Current practice is closer to the latter extreme; we tend to have ~one router per destination, but have trouble abstracting the routing information to a pure log N "map" of the network. Trying to move _further_ toward this end seems (IMHO) a bit unreasonable. Note that a "router" isn't necessarily the same thing as a "forwarder". It is possible for a router to manage a number of switches, and set up paths (partial flows) through them on demand, using control traffic (above or below IP layer) to set up the links in the path. This is one of the models IPv7 is designed to support directly. (And it is far from a new idea; see for example the routing suggested for Cheriton's SIRPENT, or more recently IDPR.) (To forestall a question: "IPv7 is designed for IDPR? But I thought you were advocating RAP!" The answer is that RAP is designed to be a universally _applicable_ routing protocol, especially for automatic routing in a mixed IPv4-IPv7 net. It is _not_ supposed to be _the_ universal protocol. :-) It may perhaps replace RIP, and possibly BGP, but although it does what OSPF and IDPR do, the architecture is very different (DV vs LS :-), and therefore has different applicability.) Best Regards, Robert From owner-Big-Internet@munnari.oz.au Tue Apr 13 08:07:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13937; Tue, 13 Apr 1993 08:07:18 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13929; Tue, 13 Apr 1993 08:07:01 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA07512; Mon, 12 Apr 93 15:06:41 -0700 Message-Id: <9304122206.AA07512@Mordor.Stanford.EDU> To: jmh@anubis.network.com (Joel Halpern) Cc: big-internet@munnari.oz.au Subject: Re: Progres? Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 12 Apr 93 09:17:28 -0500. <9304121417.AA25916@anubis.network.com> Date: Mon, 12 Apr 93 15:06:41 -0700 From: Dave Crocker X-Mts: smtp Joel, I have been mistified by the apparent lack of pressure driving the community to reach some sort of consensus. Perhaps your note provides the explanation. I see four problems with the logic: 1. We are probably relying far to heavily on CIDR's fixing the immediate problem, given that it has not been shown to accomplish its assigned task, 2. It is expensive to keep these competitive efforts going in parallel and the longer they continue the more likely we are to be faced with having to continue support for each, since each will develop an installed base, 3. None of the projections take into account unplanned growth That is, if we open up a major new market segment, it could cause a serious explosion in IP number/net usage, far beyond the current calculations. 4. A standard rule of project management is that is if you can't afford to lose, make sure you don't. Make sure that scheduling and the availability of alternate solutions leave you with a fall-back path. I believe that the view you are espousing leaves us very exposed. Dave From owner-big-internet@munnari.oz.au Tue Apr 13 11:08:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20628; Tue, 13 Apr 1993 11:08:33 +1000 (from owner-big-internet) Return-Path: Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14264; Tue, 13 Apr 1993 08:20:20 +1000 (from jmh@anubis.network.com) Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA02296; Mon, 12 Apr 93 17:22:18 -0500 Received: from petunia.network.com by anubis.network.com (4.1/SMI-4.1) id AA04300; Mon, 12 Apr 93 17:19:33 CDT Date: Mon, 12 Apr 93 17:19:33 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9304122219.AA04300@anubis.network.com> To: dcrocker@Mordor.Stanford.EDU Subject: Re: Progres? Cc: big-internet@munnari.oz.au Dave, To comment on your suggestions: >1. We are probably relying far to heavily on CIDR's fixing the >immediate problem, given that it has not been shown to accomplish >its assigned task, It has not been "shown" to work. But analysis suggests that it does, and initial exerience suggests that it will. I am not so sanguine as to suggest that it is the last answer, or that we should stop working on long term solutions, but it seems to give us breathing room. >2. It is expensive to keep these competitive efforts going in >parallel and the longer they continue the more likely we are to >be faced with having to continue support for each, since each will >develop an installed base, It is very expensive to stop experimenting. While it is true the these efforts cost resources, they are well spent. Each known effort is working on different aspects and approaches to the problems. As such, while some may turn out to be wrong, they are valuable work. I do not think this is wasted effort, and presumably the folks expending it don't think so either. >3. None of the projections take into account unplanned growth That is, >if we open up a major new market segment, it could cause a serious >explosion in IP number/net usage, far beyond the current calculations. It is certainly true that we could be blind-sided. If we suddendly discover a need to select and deploy one alternative, so be it. Until then, why do so. Aside from anything else, until there is a real, visible, need no provider of service will commit to large-scale change-over, and no large customer will commit to undertake the software change required. >4. A standard rule of project management is that is if you can't afford >to lose, make sure you don't. Make sure that scheduling and the >availability of alternate solutions leave you with a fall-back path. >I believe that the view you are espousing leaves us very exposed. I belive that continueing the work we are doing, without attempting to artificially force a conclusion is the best way to avoid "losing". If it is not necessary to choose based on insufficient information, it would be a mistake to do so. Note that allowing the current state to continue means that we have a chance of adopting a singificant step forward in technology. To pick now would prohibit that. Alternatively, avoiding picking now allows the more moderate proposals to show through experimentation that they are strong enough to handle the worst case scenarios we have nightmares about. As yet a different view it could be pointed out that given the difficulty already evinced in making a technical choice, the marketplace should decide. Continued experimentation permits that. [Just persuade the builders and providers to deploy/experiment with your favorite proposal.] Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.oz.au Wed Apr 14 01:03:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05331; Wed, 14 Apr 1993 01:03:34 +1000 (from owner-Big-Internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05328; Wed, 14 Apr 1993 01:03:25 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA04845; Tue, 13 Apr 93 08:07:14 -0700 Date: Tue, 13 Apr 93 08:07:14 -0700 From: Eric Fleischman Message-Id: <9304131507.AA04845@atc.boeing.com> To: dcrocker@Mordor.Stanford.EDU, jmh@anubis.network.com Subject: Re: Progres? Cc: big-internet@munnari.oz.au Dave Crocker wrote: > 1. We are probably relying far to heavily on CIDR's fixing the > immediate problem, given that it has not been shown to accomplish > its assigned task, > 2. It is expensive to keep these competitive efforts going in > parallel and the longer they continue the more likely we are to > be faced with having to continue support for each, since each will > develop an installed base, > 3. None of the projections take into account unplanned growth That is, > if we open up a major new market segment, it could cause a serious > explosion in IP number/net usage, far beyond the current calculations. > 4. A standard rule of project management is that is if you can't afford > to lose, make sure you don't. Make sure that scheduling and the > availability of alternate solutions leave you with a fall-back path. > I believe that the view you are espousing leaves us very exposed. I am very grateful to Dave for articulating these four points. I must confess to my growing concern concerning the lack of progress we are making towards finding a unified solution to IPng. Perhaps what is the most troubling to me personally is that I do not understand the mechanism by which a final IPng solution will be selected/determined short of the unlikely scenario in which all proponents voluntarily "drop out" except for one clear winner. Rather, what I see polarization occurring roughly on the following lines: * SIP is generally favored by the workstation vendors. * PIP is generally favored by the research community. * TUBA is generally favored by the network providers and router vendors. * IPv7 is favored by Process Software Corporation. * NIMROD is generally favored by ... etc. I do not see any of these approaches "dropping out" since each of them clearly have differing sets of advantages and disadvantages associated with their approaches. Furthermore, the more "creative" approaches can only become verified by being given the time to fully demonstrate their capabilities which implies granting them the time to "show their stuff". In my mind, this potentially implies years for development and wide-scale testing. However, should this type of commitment occur, then it is increasingly unlikely that any advocate will be willing to permit their baby to not be THE official IPng approach -- meaning that we may have many divergent and intractible solutions. In this way we would effectively be "fiddling while Rome is burning". Given this scenario, I would like to press for three things to occur: 1) Permit current development to occur on all approaches until a specific date. The date which is most frequently mentioned is the final IETF of this year. I realize that the "we have plenty of time" contingent will not appreciate such a short development time horizon, but then I am a member of the "we have limited amount of time" faction. Thus, as a compromise, I would like to suggest that we agree to an arbitrary "cut off date" at that IETF upon which the various proposals will be judged. 2) The SELECT criteria have been formulated. I suggest that at the final IETF meeting of this year that each approach be evaluated concerning how they met those criteria. Let's let the IAB and the IESG "grade" each of these approaches for each of the criteria. Opportunities to challenge the grades must be permitted to see if the graders wish to change their minds. 3) I suggest that the resulting grades then be tabulated and the "winner" identified. My big question is what will the community do if one or more "non-winner"(s) refuse to admit defeat and continue (ad infinitum) pushing their approach? I, for one, think that multiple network protocols is our worse case scenario. However, I know of no mechanism to assure that any selection process will succeed. Can anybody suggest a more viable mechanism by which a final IPng solution can be determined? Sincerely yours, --Eric Fleischman From owner-big-internet@munnari.oz.au Wed Apr 14 02:14:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07713; Wed, 14 Apr 1993 02:14:25 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304131614.7713@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07580; Wed, 14 Apr 1993 02:07:52 +1000 (from jcurran@nic.near.net) To: Eric Fleischman Cc: big-internet@munnari.oz.au Subject: Re: Progres? In-Reply-To: Your message of Tue, 13 Apr 93 08:07:14 -0700. <9304131507.AA04845@atc.boeing.com> Date: Tue, 13 Apr 93 12:07:38 -0400 From: John Curran -------- ] From: Eric Fleischman ] Subject: Re: Progres? ] Date: Tue, 13 Apr 93 08:07:14 -0700 ] ... ] I must confess to my growing concern concerning the lack of progress ] we are making towards finding a unified solution to IPng. ] Perhaps what is the most troubling to me personally is that ] I do not understand the mechanism by which a final IPng solution ] will be selected/determined short of the unlikely scenario in which ] all proponents voluntarily "drop out" except for one clear winner. ] ] Rather, what I see polarization occurring roughly on the following lines: ] * SIP is generally favored by the workstation vendors. ] * PIP is generally favored by the research community. ] * TUBA is generally favored by the network providers and router vendors. ] * IPv7 is favored by Process Software Corporation. ] * NIMROD is generally favored by ... ] etc. If you're interested in which approach will become IPng, just fill in blank: ________ is generally favored by the end-user community. If someone thinks that we can deploy a solution which is _not_ favored by the user community, I'd love to hear how. /John From owner-Big-Internet@munnari.oz.au Wed Apr 14 03:21:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09869; Wed, 14 Apr 1993 03:21:17 +1000 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09850; Wed, 14 Apr 1993 03:21:02 +1000 (from kasten@ftp.com) Received: by ftp.com id AA08530; Tue, 13 Apr 93 13:21:04 -0400 Date: Tue, 13 Apr 93 13:21:04 -0400 Message-Id: <9304131721.AA08530@ftp.com> To: jcurran@nic.near.net, ericf@atc.boeing.com, big-internet@munnari.oz.au Subject: Prognostication (was Re: Progres?) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Well, I've been watching this thread for a while now, and think that I have some useful things to say. The Internet is a somewhat self-coordinating anarchy of independent empires. This is one of its greatest strengths and one of its greatest weaknesses. What this translates to is that we all are off doing our own thing in our own way, but we all realize that, in order for us all to win big, all those "things" and "ways" must be more or less compatible at various key points. What this also says is that there is no one person, organization, or group of people or organizations that can even pretend to make a decision. The IESG/IAB/IETF comes close to such a body. However, it can only pretend to dictate something only when most everyone agrees to accept the well-known dictate. I hear the cry: "What about things like SNMP?" Well, look at it, the IAB, et al, toyed around for a while, kind-of blessing SNMP AND CMOT, then sort of ignored the whole bloody problem until one of them became the one that was pretty obviously preferred by the community and, well, you have not heard much of CMOT lately, have you? At best, the I* can point in one or more promising directions, let the world decide which is better -- for whatever reason, not just technical reasons -- and then bless the already chosen approach. Now, this is not a flame at the I*. I firmly believe that this is exactly the right way to do things. This may seem like a spineless lack of leadership to some -- to me it seems like the apotheosis of "Rough Consensus and Running Code". I believe that this is all that can be done by the I*. Remember that "anarchy of independent empires" that I mentioned? Well, if the I* says that is the right answer to some problem before the answer is obvious to all, those independent empires could very well go off and do , all the while telling the I* to firmly place in some bodily orifice. What does this have to do with the IPng debate? Well, I think that what will happen is that all of the proposals that get off of the ground will be extensively fielded in various places. As they mature, they will be placed in production use in various independent empires in the Internet. Boeing might decide to standardize on TUBA since it has a corporate commitment to ISO and TUBA looks like it is ISO. FTP Software might decide to standardize on PIP because Paul Tsuchiya is a nice guy. And so on. This looks like it will be a tower of Babel, with all of these protocols. However, any protocol will have some form of transition and mapping plan to go from IPv4 to it -- so what would happen is that, where different protocols must play together, you will find -IPv4- translators. IPv4 will become, in effect, a common intermediate language. This situation is probably a bad one so I imagine that it will not last long -- a couple of years. Some of the protocols will die out because they do not offer the needed technology (maybe they don't provide the scaling that is needed, maybe they do not provide enhanced network layer functions). Others will die simply because they do not generate enough support in terms of an installed base (suppose that Cray is the only vendor to adopt the protocol -- with an installed base of a thousand or two, growing by the dozens each year, would not be a market place success). Eventually I expect that one protocol will, for technical AND non-technical reasons come to dominate the network. At this point someone will say "That's the Standard!" In short, I do not think that any decision is possible, warranted, or desired until it is redundant. Sorry for the length of this note. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Wed Apr 14 03:21:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09875; Wed, 14 Apr 1993 03:21:22 +1000 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09866; Wed, 14 Apr 1993 03:21:13 +1000 (from kasten@ftp.com) Received: by ftp.com id AA08537; Tue, 13 Apr 93 13:21:10 -0400 Date: Tue, 13 Apr 93 13:21:10 -0400 Message-Id: <9304131721.AA08537@ftp.com> To: ericf@atc.boeing.com Subject: Re: Progres? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: dcrocker@Mordor.Stanford.EDU, jmh@anubis.network.com, big-internet@munnari.oz.au > > Rather, what I see polarization occurring roughly on the following lines: > * SIP is generally favored by the workstation vendors. > * PIP is generally favored by the research community. > * TUBA is generally favored by the network providers and router vendors. > * IPv7 is favored by Process Software Corporation. > * NIMROD is generally favored by ... > etc. > > I do not see any of these approaches "dropping out" since each of them > clearly have differing sets of advantages and disadvantages associated > with their approaches. Furthermore, the more "creative" approaches can At the risk of being offensive, I tried to get this sort of information out of the various proponents at the Monday Morning IPng status report at the Columbus IETF and was very unhappy with the results None of the four (NIMROD was not there) claimed any architectural boundary conditions or limits. The advantages claimed (I asked "If I were King of the Internet and had to make the choice, why should I pick your protocol over the others?") were "least risk", "long term growth path/flexibility", "CLNP is already there" and "automatic upgrade and install" for SIP, PIP, TUBA, and IPv7, respectively. This was followed by a bit of "we have that other stuff too". -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Wed Apr 14 04:08:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11516; Wed, 14 Apr 1993 04:09:09 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11504; Wed, 14 Apr 1993 04:08:54 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA02757; Tue, 13 Apr 93 11:08:15 -0700 Message-Id: <9304131808.AA02757@Mordor.Stanford.EDU> To: kasten@ftp.com Cc: ericf@atc.boeing.com, jmh@anubis.network.com, big-internet@munnari.oz.au Subject: Re: Progres? Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 13 Apr 93 13:21:10 -0400. <9304131721.AA08537@ftp.com> Date: Tue, 13 Apr 93 11:08:15 -0700 From: Dave Crocker X-Mts: smtp Frank, I noted your effort, during the Monday presentations. Similarly, then, I was trying to get at the human and operational impact. Somehow, though, we aren't asking the right questions, so we are not getting sufficiently crisp and comparable answers. Mumble. Dave From owner-big-internet@munnari.oz.au Wed Apr 14 23:21:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27070; Wed, 14 Apr 1993 23:22:07 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25518; Wed, 14 Apr 1993 22:38:29 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29074; Wed, 14 Apr 1993 14:37:57 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA24427; Wed, 14 Apr 1993 14:37:39 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9304141237.AA24427@dxcern.cern.ch> Subject: Re: Progres? To: jcurran@nic.near.net (John Curran) Date: Wed, 14 Apr 1993 14:37:39 +0200 (MET DST) Cc: ericf@atc.boeing.com, big-internet@munnari.oz.au In-Reply-To: <9304131614.7713@munnari.oz.au> from "John Curran" at Apr 13, 93 12:07:38 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1362 >--------- Text sent by John Curran follows: > > -------- > ] From: Eric Fleischman .... > ] Rather, what I see polarization occurring roughly on the following lines: > ] * SIP is generally favored by the workstation vendors. > ] * PIP is generally favored by the research community. > ] * TUBA is generally favored by the network providers and router vendors. > ] * IPv7 is favored by Process Software Corporation. > ] * NIMROD is generally favored by ... > ] etc. > > If you're interested in which approach will become IPng, just fill in blank: > > ________ is generally favored by the end-user community. > > If someone thinks that we can deploy a solution which is _not_ favored by > the user community, I'd love to hear how. > Thanks John, you said it all. So the market decides; but today the market does not know (a) that there is a problem (b) that solutions are under discussion so we are several years from the time when the market can be expected to decide. As Steve Bourne said here in a seminar this morning, we still need Computer Science Ph.D.s to run our networks for a while longer. Serious point here: how do we begin to sensitise the end-user community to the IPng issue, and when should we do this? Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.oz.au Thu Apr 15 00:54:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00995; Thu, 15 Apr 1993 00:54:40 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00991; Thu, 15 Apr 1993 00:54:31 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA26249; Wed, 14 Apr 93 07:54:14 -0700 Message-Id: <9304141454.AA26249@Mordor.Stanford.EDU> To: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Cc: jcurran@nic.near.net (John Curran), ericf@atc.boeing.com, big-internet@munnari.oz.au Subject: Re: Progres? Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 14 Apr 93 14:37:39 +0200. <9304141237.AA24427@dxcern.cern.ch> Date: Wed, 14 Apr 93 07:54:13 -0700 From: Dave Crocker X-Mts: smtp Brian, You asked when and how the user population should be sensitized to the IPng issues. I believe that we are already late in this task. I've made some individual efforts to raise the issue in some user forums, but don't see that community taking the bait. One of the reasons the SIP/IPAE group issued a press release about its demo was to try to get this topic a wider forum. As near as I can tell, it hasn't had much effect, yet. I believe that the primary issue is that few users perceive the problem. They trundle along with relatively small nets and limited interaction with the Internet, so they simply don't have anything that forces them to feel a sense of impending doom. Each of us believes we know what is best for the user community. But the major strength of the IETF process is that it doesn't impose filters on participation. Still, I believe we do not have enough user participation, so there is an unfortunate, effective filter in that vendors, providers, and researchers get to guess what is best. That is why I was delighted to see Eric's note, but feel that we need considerably more input from a wider range of folks. (Eric notes that he represents a user that is rather distinctive in size and complexity.) Dave From owner-Big-Internet@munnari.oz.au Thu Apr 15 00:54:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01008; Thu, 15 Apr 1993 00:55:08 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00998; Thu, 15 Apr 1993 00:54:52 +1000 (from francis@tsuchiya.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 14 Apr 93 10:54:44 EDT Received: from tsuchiya (localhost) by tsuchiya.bellcore.com (5.0/SMI-SVR4) id AA02582; Wed, 14 Apr 93 10:54:38 EDT Message-Id: <9304141454.AA02582@tsuchiya.bellcore.com> To: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Cc: jcurran@nic.near.net (John Curran), ericf@atc.boeing.com, big-internet@munnari.oz.au, francis@thumper.bellcore.com Subject: Re: Progres? In-Reply-To: Your message of "Wed, 14 Apr 1993 14:37:39 +0200." <9304141237.AA24427@dxcern.cern.ch> Date: Wed, 14 Apr 1993 10:54:37 -0400 From: Paul Francis (formerly Paul Tsuchiya) Content-Length: 559 > > Serious point here: how do we begin to sensitise the end-user > community to the IPng issue, and when should we do this? > I don't think the user community can or even should be sensitized to this. I think the *only* way the user community as a whole could come to care about this is if, someday, user A cannot talk to user B because of the IP problem. Then, of course, the user will suddenly care, but at that point we will have already failed (at least partially). Ideally, the users should never be aware that there is/was a problem..... PX From owner-big-internet@munnari.oz.au Thu Apr 15 03:30:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07087; Thu, 15 Apr 1993 03:30:27 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02071; Thu, 15 Apr 1993 01:24:53 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29023; Wed, 14 Apr 1993 17:24:28 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA00979; Wed, 14 Apr 1993 17:23:42 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9304141523.AA00979@dxcern.cern.ch> Subject: Re: Progres? To: francis@tsuchiya.bellcore.com (Paul Francis) Date: Wed, 14 Apr 1993 17:23:42 +0200 (MET DST) Cc: jcurran@nic.near.net, ericf@atc.boeing.com, big-internet@munnari.oz.au, francis@thumper.bellcore.com In-Reply-To: <9304141454.AA02582@tsuchiya.bellcore.com> from "Paul Francis" at Apr 14, 93 10:54:37 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 944 Here's an interesting diversity of view, or unusually rough consensus :-) >--------- Text sent by Paul Francis follows: > > > > > Serious point here: how do we begin to sensitise the end-user > > community to the IPng issue, and when should we do this? > > > > I don't think the user community can or even should be > sensitized to this. >--------- Text sent by Dave Crocker follows: > > > You asked when and how the user population should be sensitized to the > IPng issues. > > I believe that we are already late in this task. Well I agree with both of you. The _real_ users don't want to know about this stuff. But the network managers at user sites need to start worrying about it in good time, just to be able to plan a smooth transition. It is the latter category we need to wake up. Eric F and I are in that category, actually, so some of us are awake already. Should we BOF on this topic at the Amsterdam IETF? Brian From owner-Big-Internet@munnari.oz.au Thu Apr 15 06:17:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15859; Thu, 15 Apr 1993 06:18:05 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15856; Thu, 15 Apr 1993 06:17:55 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA02141; Wed, 14 Apr 93 13:17:34 -0700 Message-Id: <9304142017.AA02141@Mordor.Stanford.EDU> To: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Cc: big-internet@munnari.oz.au Subject: Re: Progres? Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 14 Apr 93 17:23:42 +0200. <9304141523.AA00979@dxcern.cern.ch> Date: Wed, 14 Apr 93 13:17:33 -0700 From: Dave Crocker X-Mts: smtp Brian, ---- Included message: Should we BOF on this topic at the Amsterdam IETF? What a good idea! And I commend your offer to set up the BOF and to chair it. D/ From owner-Big-Internet@munnari.oz.au Thu Apr 15 06:23:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16124; Thu, 15 Apr 1993 06:23:41 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16097; Thu, 15 Apr 1993 06:23:26 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA02193; Wed, 14 Apr 93 13:23:16 -0700 Message-Id: <9304142023.AA02193@Mordor.Stanford.EDU> To: Paul Francis (formerly Paul Tsuchiya) Cc: big-internet@munnari.oz.au Subject: Re: Progres? Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 14 Apr 93 10:54:37 -0400. <9304141454.AA02582@tsuchiya.bellcore.com> Date: Wed, 14 Apr 93 13:23:15 -0700 From: Dave Crocker X-Mts: smtp Paul, ---- Included message: I don't think the user community can or even should be sensitized to this. I should clarify that I see multiple types of "user" communities. Your assessment of the likely best involvement for the lowly end-user -- i.e., the person that all of the rest of us believe we are serving -- is none. But there are host administrators, network administrators, product support & training staff, and others who are not directly involved in either developing the technology or otherwise acting as a primary provider of the service. Each of them is a user of the work of others. And I believe that each of the IPng alternatives represents very real tradeoffs. It will be quite unfortunate if those users have no say in the selection among those tradeoffs. Dave From owner-big-internet@munnari.oz.au Thu Apr 15 07:29:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19363; Thu, 15 Apr 1993 07:29:40 +1000 (from owner-big-internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09022; Thu, 15 Apr 1993 04:27:51 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA08505; Wed, 14 Apr 93 11:31:37 -0700 Date: Wed, 14 Apr 93 11:31:37 -0700 From: Eric Fleischman Message-Id: <9304141831.AA08505@atc.boeing.com> To: brian@dxcern.cern.ch, jcurran@nic.near.net Subject: Re: Progres? Cc: big-internet@munnari.oz.au, ericf@munnari.oz.au Brian Carpenter wrote: >So the market decides; but today the >market does not know > > (a) that there is a problem > (b) that solutions are under discussion > >so we are several years from the time when the market can be expected >to decide. ... >Serious point here: how do we begin to sensitise the end-user >community to the IPng issue, and when should we do this? From my perspective as a Network Architect for a large end user community, I view the IPng issue to be a very serious matter. I do not favorably view any technology with known, built-in obsolescence. IPng implies to me that any TCP/IP product purchased today will need to be potentially replaced before the product has been depreciated from our books. This represents a potentially expensive lose-lose proposition for us. Of course, we are well aware of this situation and are actively taking steps to avoid these potentially significant risks as much as we are able. I am also grateful for the attention being given to "migration issues" by the various IPng approaches. However, I firmly believe that the "marketplace" will be horrified by the need for IPng and any "sensitization" thus will be a very delicate "public relations" proposition. Such sensitization will need to address why the marketplace should trust the IETF community to build scalable products which will meet anticipated/required product life-cycles. It will also need to address why the marketplace should continue to invest in TCP/IP technology when other technologies exist which do not have these built-in obselescence "features". This public relations problem would be significantly eased if a single IPng solution were determined. That is, I am not comforted that the solution "is being worked" because I have tracked this issue for four years and thus have no "warm fuzzies" that a closure will ever be reached. Certainly, the "market forces will decide" position seems to me to be an approach which will confirm the market's worst fears about the IETF's "responsibility". Certainly you can't reasonably expect *ME* to buy any IPng solution if it is not known whether it will even be viable short term or not [i.e., consider for the moment the risks associated to us users if we "decide" on a losing solution. This is an untenable approach: we simply will have to stay with IPv4 regardless of the state of the address space until a non-risky IPng solution is formulated just because we can't afford to guess wrong. Note: Even if the vendors are willing to fully carry much of this risk themselves and guarantee us a "free" replacement we still would have had substantial personnel-related migration costs associated with a wrong guess. Who can afford that?]. However, should a single solution be identified in a timely manner then that is an entirely different proposition -- one that offers hope. I realize that much of what I am saying may fall upon "deaf ears". However, I sincerely expect that any optimism about Market forces "resolving the IPng problem" is misplaced. That is, I suspect that the current market ignorance concerning the "IPng problem" is a major blessing. I only hope that we formulate a consensus solution before the market catches on. If we don't, then I anticipate the market responding in a manner which will surprise many. Put another way, I have found that senior management is always more sanguine when the risks are minimized by having a viable solution in hand. "We're working on it" (i.e., the Joe Isuzu "trust me" approach) just does not cut it, especially if the one offering the promise does not have an absolutely perfect success record. The old days that "nobody is ever fired for buying {a certain vendor's} products" are now gone, probably forever. Sincerely yours, --Eric Fleischman All comments presented here are the personal opinions of Eric Fleischman and do not necessarily reflect in any way upon the corporate positions or opinions of The Boeing Company. From owner-Big-Internet@munnari.oz.au Thu Apr 15 08:25:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21430; Thu, 15 Apr 1993 08:26:49 +1000 (from owner-Big-Internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21329; Thu, 15 Apr 1993 08:25:31 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA21417; Wed, 14 Apr 93 15:24:56 -0700 Date: Wed, 14 Apr 93 15:24:56 PDT From: Vince Fuller To: Steve Deering Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au, ULLMANN@process.com, deering@parc.xerox.com Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) In-Reply-To: Your message of Wed, 7 Apr 1993 15:27:45 PDT Message-Id: I don't think that IPv4 renumbering will happen, so I don't think CIDR will do anything except reduce the *rate of growth* of backbone overhead. All the existing routes will still need to be maintained, plus lots of new ones. Maybe, maybe not. We are certainly encouraging our clients to renumber where it is not too difficult to do so. At least one network provider that I know of will be *requiring* its clients to renumber (the provider in question is in the unique position of connecting its clients essentially for free, so they have the luxury of being able to make such requirements). Maybe what we need is a trust fund to reward those sites who are willing to renumber (1/2 :-) For CIDR to make a big difference, you have to convince a significant majority of sites to renumber *all* of their IP boxes, to numbers that are (or appear to be) less "portable" than their current numbers (since the new ones will contain provider prefixes). I just don't think that will fly. Have you read RFC1338? It explicitly states that the provider-oriented network numbers assigned according to its guidelines are completely portable. Loss of aggregation efficiency is caused by networks which move without renumbering, so sites which move are encouraged to plan a transition to new network numbers (but this is NOT required). The whole "fear-of-renumbering" problem should be a fundamental consideration in the decision on IPng. And no, geographical "address" assignment is not the answer, since that just moves the problem and adds unacceptable and entirely unenforceable constraints to the network topology. IMHO, any IPng proposal which doesn't deal with this issue is not worthy of serious consideration. This problem is also one of the strongest arguments in favor of something like Noel's EID's, which decouple the host-identification and routing functions that are currently mashed together in IPv4 addresses. --Vince From owner-big-internet@munnari.oz.au Thu Apr 15 08:57:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22784; Thu, 15 Apr 1993 08:58:30 +1000 (from owner-big-internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16386; Thu, 15 Apr 1993 06:27:14 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA18179; Wed, 14 Apr 93 13:30:40 -0700 Date: Wed, 14 Apr 93 13:30:40 -0700 From: Eric Fleischman Message-Id: <9304142030.AA18179@atc.boeing.com> To: big-internet@munnari.oz.au Subject: apology I have previously posted the following to this list. > Rather, what I see polarization occurring roughly on the following lines: > * SIP is generally favored by the workstation vendors. > * PIP is generally favored by the research community. > * TUBA is generally favored by the network providers and router vendors. > * IPv7 is favored by Process Software Corporation. > * NIMROD is generally favored by ... It has been pointed out to me that this message of mine is subject to an interpretation which I did not intend. The purpose of this note is to apologize for my lack of clarity. By saying the above I solely meant to say that 1) that different proposals had somewhat differing constituencies, but that nearly all companies are presently "un-aligned". 2) that one of the proposals actually has a vendor formally backing it which is why that statement was worded differently than the others. In no way did I imagine that I was providing an evaluation of the worth of any proposal. Similarly, I did not intend to say that "all people" within community X advocate proposal Y. Indeed, I am well aware that many/most of us are open to all proposals at the present. My concern, however, is that I hope that EVERYONE will be open to backing a SINGLE "consensus" approach once the IETF determines how and when that consensus will be determined. The motivation of my original message was to be a catalyst for this to occur by suggesting a possible "straw horse" method for formulating that consensus. Sincerely yours, --Eric Fleischman From owner-big-internet@munnari.oz.au Thu Apr 15 18:18:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14707; Thu, 15 Apr 1993 18:18:15 +1000 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07041; Thu, 15 Apr 1993 15:14:33 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19514; Wed, 14 Apr 93 22:14:25 PDT Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27365; Wed, 14 Apr 93 22:14:33 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA00514; Wed, 14 Apr 93 22:14:23 PDT Date: Wed, 14 Apr 93 22:14:23 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9304150514.AA00514@bigriver.Eng.Sun.COM> To: Vince Fuller Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Content-Length: 1167 Vince, >problem is also one of the strongest arguments in favor of something like >Noel's EID's, which decouple the host-identification and routing functions >that are currently mashed together in IPv4 addresses. A problem I have with EID's is that as a general concept they are simple to understand, but doesn't seem to be any agreement as to what they are. There is no agreement on their size (are six bytes IEEE addresses big enough, maybe not for the global internet, how about eight bytes?); whether they represent an interface, computer, process, or something else; are they portable (when you get a new computer do you reuse your EID or get a new one); who assigns them; how much structure do they have; how are they assigned. Each of these decision points has major effects on the design of the protocols which would use them. I would agree that they have the potential to solve many problems, but they do not come for free and we are a long way from any sort of consensus on their practical utility. So far everything that can be done with EIDs can also be done with addresses. It is still not clear to me that the benefit justifies the cost. Bob From owner-Big-Internet@munnari.oz.au Thu Apr 15 18:28:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15201; Thu, 15 Apr 1993 18:28:28 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15186; Thu, 15 Apr 1993 18:28:17 +1000 (from smart@mel.dit.csiro.au) Received: by shark.mel.dit.csiro.au id AA29219 (5.65c/IDA-1.4.4/DIT-1.3 for big-internet@munnari.oz.au); Thu, 15 Apr 1993 18:28:28 +1000 Message-Id: <199304150828.AA29219@shark.mel.dit.csiro.au> To: big-internet@munnari.oz.au Subject: Re: Progres? In-Reply-To: Your message of "Mon, 12 Apr 93 15:06:41 MST." <9304122206.AA07512@Mordor.Stanford.EDU> Date: Thu, 15 Apr 93 18:28:28 +1000 From: Bob Smart In this age of multi-protocol routers, how important is it that we come up with a single solution? What is important is that *one* of the solutions is universally implemented. If we had to pick the universal network protocol tomorrow we'd pick CLNP (again). However I strongly feel that we will, instead, work out ways to use the 32 bit address space more densely and keep IP going till the end of the decade. Imagine what will happen when we stop allocating IPv4 addresses. The people who want them and can no longer get them will look to their neighbor who has a class B with 1% utilization and be very upset. At this point ad hoc schemes for denser use will arise if sensible standards have not been defined. So in 5 years we will have a continuing universal IPv4 address space that will sometimes use IPv4 routing and sometimes encapsulate the packets in some other protocol. We will have a nearly universal CLNP internet supporting Internet and OSI applications. There will be a new internet protocol, PIP or SIP, supporting new features (particularly those required by real-time applications). And the whole information infrastructure will still be growing exponentially and changing furiously, so all sorts of things we haven't thought of yet will be going on. To those who were hoping that we would come up with a grand unifying simplification: sorry no chance. Things are going to get more complex and our job is to control the complexity. The only thing that will be simpler is that DECNET phase IV will have disappeared. So I think that the work going on at the moment is all useful. When CIDR has been implemented, and when some of the new protocols with bigger addresses are more widely deployed then it will be a good time to reintroduce some of the proposals for denser use of the IPv4 space using encapsulation. The longer we can put off the end of universal IPv4 interconnectivity the better the transition arrangements will be. >2. It is expensive to keep these competitive efforts going in >parallel The TUBA development is very valuable in its own right. It allows the many sites which have little choice but to run an OSI network layer to use Internet applications. The competition between PIP and SIP seems very valuable to me. Americans, of all people, shouldn't underrate the value of competition or overrate the value of putting all your eggs in one basket. >3. None of the projections take into account unplanned growth. Given the difficulty of running an IP network there are limits to how many new networks can connect in the next few years. If the average home system and small business are to connect it will initially be through specialized front-ends: souped up versions of compuserve that won't use up significant address space. But it doesn't matter when it happens: one day we have to decide what our new universal connector is going to be. The earlier the decision the more likely it is to be CLNP. The later the decision the more likely it will be a new protocol supporting new features. Bob Smart From owner-big-internet@munnari.oz.au Thu Apr 15 18:52:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16020; Thu, 15 Apr 1993 18:52:10 +1000 (from owner-big-internet) Return-Path: Received: from uu6.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10001; Thu, 15 Apr 1993 16:28:42 +1000 (from miker@jupiter.fuentez.com) Received: from jupiter.fuentez.com by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02558 for big-internet@munnari.oz.au; Thu, 15 Apr 93 02:28:10 -0400 Received: from localhost by fuentez.com (4.1/FSC-1.2) id AA00733; Thu, 15 Apr 93 02:25:50 EDT Message-Id: <9304150625.AA00733@fuentez.com> To: big-internet@munnari.oz.au Subject: Re: Progres? In-Reply-To: Message from Paul Francis (formerly Paul Tsuchiya) of "Wed, 14 Apr 1993 10:54:37 -0400" <9304141454.AA02582@tsuchiya.bellcore.com> Date: Thu, 15 Apr 1993 02:25:50 -0400 From: Mike Robitaille > > > > Serious point here: how do we begin to sensitise the end-user > > community to the IPng issue, and when should we do this? > > > > I don't think the user community can or even should be > sensitized to this. I think the *only* way the user community > as a whole could come to care about this is if, someday, > user A cannot talk to user B because of the IP problem. Then, > of course, the user will suddenly care, but at that point we > will have already failed (at least partially). > > Ideally, the users should never be aware that there is/was > a problem..... > > PX As an inveterate mailing list wallflower for the last ten-odd years, I can echo the underwhelming amount of interest that is out there. IMHO the majority of the people out there that might have an inkling of the import of what you all are doing are simply assuming that you collectively will do "the right thing" (whatever that may be). Other folks (like me) who are reasonably up to speed technically, just monitor the lists (if they've got the time) and wince whenever a trade rag pumps up yet another replacement for IP. I would note that one area where folks like me could help the future "IPng Bake Off" is to prepare (as I am doing) the way with my corporate folks and mention to them how we (the company) need to be involved when (and if) reference versions of each approach become (semi-)pubically available. I'm of the opinion that you will notice a *whole bunch* more interest when it's explained to folks that it might just be in their best interest to help wring the various approaches out. After all, the whole point to the scalability criterion will just be based on what feels good if no effort is made to put the various IPng's to a medium-to-large scale test. Um, there *is* going to be some kind of a bake off, right? ---------- Michael A. Robitaille Fuentez Systems Concepts, Inc. miker@fuentez.com 11781 Lee Jackson Highway Voice: +1 (703) 273-1447 Fairfax, VA 22033 USA Fax: +1 (703) 273-2972 From owner-big-internet@munnari.oz.au Thu Apr 15 19:22:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17295; Thu, 15 Apr 1993 19:22:13 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13433; Thu, 15 Apr 1993 17:48:55 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04835; Thu, 15 Apr 1993 09:48:41 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA05448; Thu, 15 Apr 1993 09:48:35 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9304150748.AA05448@dxcern.cern.ch> Subject: Re: Progres? To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Date: Thu, 15 Apr 1993 09:48:35 +0200 (MET DST) Cc: big-internet@munnari.oz.au In-Reply-To: <9304142017.AA02141@Mordor.Stanford.EDU> from "Dave Crocker" at Apr 14, 93 01:17:33 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 817 People, >--------- Text sent by Dave Crocker follows: > > Brian, > > ---- Included message: > > > Should we BOF on this topic at the Amsterdam IETF? > > What a good idea! And I commend your offer to set up the BOF > and to chair it. > Oh, SUGAR! How did that happen ?-) OK: IF you think it is worthwhile to hold a BOF in Amsterdam on the topic of "whether, when and how to open up the IPng discussion among the Internet user community (broadly defined), and the implications of this for the IPng decision process", AND IF you are likely to attend the BOF, THEN please send a brief mail to me (spare the list). I will proceed if there is a reasonable number of positive replies. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.oz.au Thu Apr 15 20:56:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20767; Thu, 15 Apr 1993 20:56:37 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20761; Thu, 15 Apr 1993 20:56:26 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA22052; Thu, 15 Apr 93 06:56:08 EDT Date: Thu, 15 Apr 93 06:56:08 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304151056.AA22052@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: IP:TNG BOF in Amsterdam Might I humbly suggest that this BOF be multicast using the recent audio/video techniques ? A lot more users/admins are likely to tune in via the net than to actually show up in Amsterdam. If so, one might mention this a bit earlier than is usual so that folks can setup systems to join the M-Bone and debug their local installations in some reasonable time frame... Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Fri Apr 16 01:13:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00749; Fri, 16 Apr 1993 01:13:55 +1000 (from owner-Big-Internet) Return-Path: Received: from survis.surfnet.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00644; Fri, 16 Apr 1993 01:13:04 +1000 (from Erik-Jan.Bos@SURFnet.nl) Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <27162-0@survis.surfnet.nl>; Thu, 15 Apr 1993 17:12:37 +0200 Received: from localhost.surfnet.nl by surgeon.surfnet.nl (4.1/SMI-4.1(EJB01)) id AA23087; Thu, 15 Apr 93 17:12:48 +0200 Message-Id: <9304151512.AA23087@surgeon.surfnet.nl> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-Internet@munnari.oz.au Subject: Re: IP:TNG BOF in Amsterdam In-Reply-To: Your message of Thu, 15 Apr 93 06:56:08 -0400. From: Erik-Jan.Bos@SURFnet.nl X-Mailer: MH X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 310290 X-Fax-Number: +31 30 340903 Date: Thu, 15 Apr 93 17:12:46 +0200 Sender: Erik-Jan.Bos@SURFnet.nl Ran, > Might I humbly suggest that this BOF be multicast using the > recent audio/video techniques ? > > A lot more users/admins are likely to tune in via the net than > to actually show up in Amsterdam. If so, one might mention this > a bit earlier than is usual so that folks can setup systems to > join the M-Bone and debug their local installations in some > reasonable time frame... We are surely planning to have the AVT stuff running from the Amsterdam IETF, as was the case from the Columbus IETF. But of course you would like to come to Amsterdam :-). Well in advance we will send out information on this. Stay tuned. __ Erik-Jan. (part of the Amsterdam IETF local organizers folks) From owner-big-internet@munnari.oz.au Fri Apr 16 02:03:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02742; Fri, 16 Apr 1993 02:04:57 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27932; Fri, 16 Apr 1993 00:09:10 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA03177; Thu, 15 Apr 93 07:08:52 -0700 Received: by us1rmc.bb.dec.com; id AA08076; Thu, 15 Apr 93 10:06:46 -0400 Message-Id: <9304151406.AA08076@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 15 Apr 93 10:06:46 EDT Date: Thu, 15 Apr 93 10:06:46 EDT From: "Donald E. Eastlake 3rd (LJO2/I4, +1 508 486 2358) 15-Apr-1993 1008" To: big-internet@munnari.oz.au Cc: stapleton@bpa.arizona.edu Apparently-To: stapleton@bpa.arizona.edu, big-internet@munnari.oz.au Subject: FWD: next looming Internet crisis?!? From: US1RMC::"STAPLETON@bpa.arizona.edu" "Dr. Ross Alan Stapleton" 15-APR- 1993 09:13 To: com-priv@psi.com Subj: next looming Internet crisis?!? After cornering numerous inspectors general in hallways too many to recount, this reporter has learned that, while IP address space allocation was a known problem given the rapid growth of the Internet, a more dire development is that the quIP address space is fast becoming saturated as well. In his Pulitzer Prize-winning WOOF Report, a certain major NSF official described the original scheme: "Originally, we had decided to allocate quIP addresses based on truth content of postings. Clearly several major users have a monopoly on the truth, while others tend to route around a lesser (but still sizable) number of half-truths, and the vast majority, as with any E-mail-based system, are lurkers on whom the verdict is still out." The decision was made to mirror the IP address space allocation, with the high-end users receiving class A quIP licenses, the lesser users class B, and all others class C. That scheme, however, is breaking down. According to the WOOF report: "We had correctly anticipated the phenomenal growth of the Internet message traffic, so the sizable increase in requests for class C's was expected. What we had failed to take into account was the possibility that so many people would acquire a monopoly on the truth, and want to tell all sites about it." The NSF is rumored to be negotiating with the NYSE to establish a commodities market for class B and C licenses ("if they can do it with pollution credits and mineral rights, it ought to work on the nets as well" [see "Stripmining the Internet," April issue of the WOOF Report]), but the problem of class A licenses remains. Innovations in multicasting are expected to lessen some of the load on the backbone, but the most promising development may be a collaborative venture with the gaming community to develop the concept of a software "multi-user unction dispensery" (MUD), a tiny virtual world in which class A holders can provide each other with enlightenment directly. ;-) +--------------------------------------------------------------------+ | Disclaimer: "The opinions expressed above are mine and mine alone, | | and do not necessarily reflect those of the University of Arizona | | or the US Government, nor any other organization with which I am | | affiliated." Ross Alan Stapleton | +--------------------------------------------------------------------+ From owner-big-internet@munnari.oz.au Fri Apr 16 02:40:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04049; Fri, 16 Apr 1993 02:40:39 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28507; Fri, 16 Apr 1993 00:21:01 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11333; Thu, 15 Apr 93 10:20:40 -0400 Date: Thu, 15 Apr 93 10:20:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304151420.AA11333@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu There is no agreement on ... whether they represent an interface, computer, process, or something else... Well, I can't speak for everyone on this list, but EID is short for "endpoint identifier" (i.e. it is a unique names for an "endpoint"), and since I invented the term "endpoint", I reckon that what I thought "endpoint" meant (and it has an *extemely* precise definition) ought to be definitive until someone can prove my definition has problems. If someone wants a term for some other concept, please use some other term. They *definitely* do not represent an interface. I can't see how anyone could have bothered to read any of my mail about EID's and still have that idea. They don't quite represent a computer or a process (although there are circumstances in which they might). They represent a *networking* concept, not a concept dragged in from somewhere else in computer science, like process. They name, quite simply, end-end entities; i.e. the smallest atomic (in the old 'indivisble' sense of the word) things which participate in reliable end-end communications. This might be a host, if the operating system has no provision for multiple independant processors or mobile processes, or it might be a process. It is a networking concept, and does not have a one-one mapping to these other concepts. There is no agreement on ... how much structure do they have This statement is also confused. They *have* no usable structure, any more than IEEE 48-bit numbers do. Again, I can't see how anyone could have bothered to read any EID mail and think this. There is no agreement on ... who assigns them; ... how are they assigned. Each of these decision points has major effects on the design of the protocols which would use them. Why does the administrative structure which assigned them have anything to do with "the design of the protocol which [uses] them"? If they are defined to uniquely name a certain class of objects in the network (and *nothing* more), how the hell does it matter how they are assigned as long as they are unique? I would agree that they have the potential to solve many problems, but they do not come for free... True. So far everything that can be done with EIDs can also be done with addresses. So what? This is an utterly worthless statement, since a) "address" as you use it is so nebulous a concept that it can be stretched to cover any need (such as the use of the "destination address" field in IPv4 packets as a destination EID, in mobile host solutions which use the IP Source Routing option), and b) just because something can be stretched to do something doesn't mean it is good engineering to do so. A minimal Turing machine can perform any computation, but I don't notice Sun rushing out to convert all their workstations to them. ...we are a long way from any sort of consensus on their practical utility. ... It is still not clear to me that the benefit justifies the cost. This is the crux of the matter, and I don't see that there is any way to resolve it. Different people have different judgements on costs and benefits, which frankly, it is impossible to quantify because so many of both lie in the future. The endpoint/EID I-D I have half-done should at least prevent confusion about what they are (at least if anyone bothers to read it), but I doubt it will help do more than that. Noel From owner-big-internet@munnari.oz.au Fri Apr 16 05:24:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09755; Fri, 16 Apr 1993 05:25:58 +1000 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06538; Fri, 16 Apr 1993 03:52:44 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) In-Reply-To: Your message of "Thu, 15 Apr 1993 10:20:40 -0400." <9304151420.AA11333@ginger.lcs.mit.edu> Date: Fri, 16 Apr 1993 03:52:29 +1000 Message-Id: <491.734896349@munnari.OZ.AU> From: Robert Elz Date: Thu, 15 Apr 93 10:20:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9304151420.AA11333@ginger.lcs.mit.edu> I agree with all of Noel said, except for ... There is no agreement on ... how much structure do they have This statement is also confused. They *have* no usable structure, any more than IEEE 48-bit numbers do. Again, I can't see how anyone could have bothered to read any EID mail and think this. I believe EIDs will have just the same kind of structure as IEEE 48 bit numbers, that is, structure that indicates who or what allocated the particular number in question, but which is useless for almost anything else. However, I would also note that while this is irrelevant for deciding how EIDs may be used in protocols, I would allocate EIDs in just the same kind of manner as IPv4 addresses are allocated, though obviously with no need for any CIDR type considerations, so perhaps, as IPv4 addresses used to be allocated would be a better description. Noel didn't touch the question of how big EIDs are, the impression I had, perhaps because its also what I supported, was that they should be 8 bytes - there were some 6 byte advocates. I don't see how this is a vitally important question right now, as there are still some people to be convinced that the concept is useful - the number of bits in them will only really be relevant when someone actually starts to put them in packets (though perhaps PIP has done that already). In any case, if 8 byte addresses will even arguably be big enough for the future, 8 byte EIDs certainly will, so 8 is certainly enough, 4 is almost certainly too few, and of the numbers then available (5, 6, 7, and 8) 8 is pragmatically the nicest number to use (easiest to deal with). kre From owner-big-internet@munnari.oz.au Fri Apr 16 05:24:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09756; Fri, 16 Apr 1993 05:25:58 +1000 (from owner-big-internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07542; Fri, 16 Apr 1993 04:27:09 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA02468; Thu, 15 Apr 93 11:26:25 PDT Date: Thu, 15 Apr 93 11:26:25 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9304151826.AA02468@saffron.acc.com> To: ericf@atc.boeing.com Subject: Re: apology Cc: big-internet@munnari.oz.au Thanks for your note; I thought that an apology was unnecessary, however. > Rather, what I see polarization occurring roughly on the following lines: > * SIP is generally favored by the workstation vendors. > * PIP is generally favored by the research community. > * TUBA is generally favored by the network providers and router vendors. > * IPv7 is favored by Process Software Corporation. > * NIMROD is generally favored by ... I think your summarization is perhaps a bit too crisp. My reading is more that each proposal has its proponents and arguments. I think that if I had to break out representative communities, I would have so say something more like the following (and those with the flame throwers will please note that this is at least as imprecise Eric's characterization; if anyone feels slighted, maybe they can provide better words): PIP is a research project being done primarily at or under the auspices of Bellcore, and its principal proponents come from Bellcore. It argues that there are new applications on the horizon which we want to plan for now, and that we therefore want provide redefinable mechanisms for forwarding within the protocol. Coexistence is to be via gateway or product upgrade. IPv7 is a research product being being developed by Process Software Corporation, and its principal proponents come from Process Software Corporation. It argues that the principal problems we face now are not only bit counts in the address but bit counts in certain other fields. A rearranged IP and TCP can support all applications currently operational in the Internet - via direct translation for IPv4 coexistence - for as far into the future as we can reasonably discuss. TUBA is a proposal from the OSI community; its proponents are primarily people who have been proponents of OSI for some time. It argues that the principal problems which we face are the size of an IP address and its lack of hierarchy. It presumes that OSI is ubiquitously deployed or that cheap interoperable products exist which make ubiquity a non-issue. It proposes that coexistence be via transport (or higher) level gateways or by product upgrade. SIP is a proposal from several traditional IP vendors; it suggests that the only problem that we know that we have to solve is the distribution of IP addresses into networks or subnets, and limits itself to addressing that issue. Coexistence is by translation in the near term and product upgrade in the long term. NIMROD is insufficiently spelled out to make substantive comments on (my opinion, Noel, flames to me, not the list :^) From owner-big-internet@munnari.oz.au Fri Apr 16 05:23:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09719; Fri, 16 Apr 1993 05:24:10 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304151924.9719@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06197; Fri, 16 Apr 1993 03:43:30 +1000 (from jcurran@nic.near.net) To: Bob Hinden Cc: Vince Fuller , deering@parc.xerox.com, big-Internet@munnari.oz.au Subject: Re: EIDs... In-Reply-To: Your message of Wed, 14 Apr 93 22:14:23 -0700. <9304150514.AA00514@bigriver.Eng.Sun.COM> Date: Thu, 15 Apr 93 13:42:39 -0400 From: John Curran -------- ] From: Bob Hinden ] Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) ] Date: Wed, 14 Apr 93 22:14:23 PDT ] ] ... ] > (Vince) ] >problem is also one of the strongest arguments in favor of something like ] >Noel's EID's, which decouple the host-identification and routing functions ] >that are currently mashed together in IPv4 addresses. ] ] A problem I have with EID's is that as a general concept they are simple ] to understand, but doesn't seem to be any agreement as to what they are. ] ] There is no agreement on their size (are six bytes IEEE addresses big ] enough, maybe not for the global internet, how about eight bytes?); ] whether they represent an interface, computer, process, or something ] else; are they portable (when you get a new computer do you reuse your ] EID or get a new one); who assigns them; how much structure do they have; ] how are they assigned. Each of these decision points has major effects ] on the design of the protocols which would use them. I will note that we possess a similiar lack of understanding regarding flow identification and yet SIP possesses such a field. There is considerable variance in the progress that each IPng effort is making towards EIDs. For instance, PIP EID's are becoming quite well defined, and the latest ID's address many of the questions above. I would not expect to see immediate consensus on how EIDs should be implemented just as we have not seen instant consensus on the "right" way to assign flows, allocate resources, or perform policy routing. As a side note, TUBA currently follows in the tradition of IPv4 (and SIP), in that it does not explicitly define separate identifiers for endpoints. The last TUBA WG meeting discussed this question with great vigor, as many folks see a difference between network attachment points and communication entities and hence question whether deploying a new network architecture without explicit EID support is reasonable. /John From owner-Big-Internet@munnari.oz.au Fri Apr 16 06:37:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12178; Fri, 16 Apr 1993 06:37:59 +1000 (from owner-Big-Internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12174; Fri, 16 Apr 1993 06:37:50 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA01806 (5.65c/IDA-1.4.4nsd for ); Thu, 15 Apr 1993 13:37:38 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA15590 (5.65c/IDA-1.4.4-910725); Thu, 15 Apr 1993 13:37:37 -0700 Message-Id: <199304152037.AA15590@remmel.NSD.3Com.COM> To: John Curran Cc: big-internet@munnari.oz.au Subject: Re: Progres? In-Reply-To: Your message of "Tue, 13 Apr 93 12:07:38 EDT." <9304131614.7713@munnari.oz.au> Date: Thu, 15 Apr 93 13:37:36 -0700 From: tracym@NSD.3Com.COM [There have been a number of responses already, but this message is still the most convenient starting place.] > > If you're interested in which approach will become IPng, just fill in blank: > > ________ is generally favored by the end-user community. ------------------------------------->>>>which<<<<< > > If someone thinks that we can deploy a solution which is _not_ favored by > the user community, I'd love to hear how. The mention of "user community" brought to my mind some different issues from those of end-users, administrators, etc. I can't remember much thinking (out loud on this list ;-) along the lines of integrating some of the other internet protocols into our brave new IPng world. Perhaps half of the world's networked users run IPX, for which no transition plan is being envisioned under any of the current IETF efforts. And many of them (well, at least a few users from each of a large number of organizations) will want to make use of direct external internet connectivity for things that can't be conveniently done using email. Are we simply assuming that each and every IPX/Vines/Decnet/OSI/SNA-only organization will turn multiprotocol in some fashion? Will they have to upgrade all of their hosts? Some? Can gateways be built for them? One tiny example of thinking along these lines: Could we simply encapsulate IPX addresses with a suitable NSAP format for internet transport (a TUBA-ish thought)? I think it unfortunate that the major vendors of proprietary protocols have continued extensions along mostly proprietary lines, when it is certain that in the long run their various customer bases will want to communicate with each other with more than just email. 'nuff said. Cheers, Tracy From owner-Big-Internet@munnari.oz.au Fri Apr 16 08:33:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16061; Fri, 16 Apr 1993 08:33:53 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16047; Fri, 16 Apr 1993 08:33:22 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 15 Apr 1993 15:31:57 -0700 Date: Thu, 15 Apr 1993 15:31:57 -0700 From: Tony Li Message-Id: <199304152231.AA10394@lager.cisco.com> To: fbaker@acc.com Cc: big-internet@munnari.oz.au Subject: Re: apology Fred, Got a few bones to pick with you: "It argues that the principal problems which we face are the size of an IP address and its lack of hierarchy." I believe that we have consensus that this is primary problem that _all_ of the proposals are trying to solve. If there is dissent here, I believe that we should discuss this NOW. "TUBA is a proposal from the OSI community; its proponents are primarily people who have been proponents of OSI for some time." As I'm not an OSI proponent but am (somewhat) a TUBA-ite, I sorta disagee with this characterization. I think you exclude the community who see CLNP as an existing solution to present problems and are loathe to reinvent the wheel without good cause. Tony From owner-big-internet@munnari.oz.au Fri Apr 16 13:31:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27971; Fri, 16 Apr 1993 13:31:18 +1000 (from owner-big-internet) Return-Path: Received: from pooh.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21619; Fri, 16 Apr 1993 10:54:30 +1000 (from john@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Thu, 15 Apr 93 19:53:50 -0500 Message-Id: <9304160053.AA17718@iastate.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: The master has spoken (was Re: Ullmann's IPv7 (was Re: re: EIDs...)) In-Reply-To: Your message of Thu, 15 Apr 93 10:20:40 -0400. <9304151420.AA11333@ginger.lcs.mit.edu> Date: Thu, 15 Apr 93 19:53:49 CDT From: John Hascall [... EIDs are? ...] > They *definitely* do not represent an interface. I can't see how anyone could > have bothered to read any of my mail about EID's and still have that idea. Gee, I wonder why people might not read your mail... John Hascall From owner-Big-Internet@munnari.oz.au Fri Apr 16 14:25:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00350; Fri, 16 Apr 1993 14:25:43 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00336; Fri, 16 Apr 1993 14:25:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15754; Fri, 16 Apr 93 00:25:17 -0400 Date: Fri, 16 Apr 93 00:25:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304160425.AA15754@ginger.lcs.mit.edu> To: davin@bellcore.com, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu It is clear that one could easily forge a globally unique flow id by combining a globally unique EID with some other locally unique cruft. It is also clear that one could easily forge a flow id that is (locally) unique to a particular link (and preserve that property end-to-end by successive, very cheap translations). Before going on to your main point, let me mention that I considered the latter alternative, and don't like it. It's just a lot more fumbling around, and fields to modify, header checksum to update (unless you don't cover the flow ID), etc, etc. Also, having a globally unique name for the flow which is used everywhere in all transactions regarding the flow seems like a good thing. Of course, one could also do both at the same time (not as gratuitous as it sounds, actually). True. One could identify the flow with a global name, and have short local names on each hop which the packet contains, and get some of the best of both worlds. A short, locally unique flow id requires indexing a table. A long, globally unique flow id requires a hash plus a few long name comparisons. True. However, if your implementation is in hardware, you can do content addresses memory type stuff, and pull the correct flow entry up first time. As for software, would updating the short local flow id be more or less expensive than checking the long flow ID? My guess is it would probably be about the same. Also, if we are going to have the source and destination EID's in all packets anyway (which I like for error handling; no dependancy loops or tricky stuff required), it doesn't cause packet bloat. An "almost unique" flow id (long id with precomputed hash hint) requires a few long name comparisons. Doesn't seem like the "almost unique" flow id gets you into a significantly better performance regime than just plain long flow ids. If I read your subtext correctly, you are gently pointing out that we can optimize software packet processing by carrying a precomputed hash function of the globally unique flow id in the packets, yes? This is a good idea, I hadn't thought of it, and you don't need to be so indirect! Certainly not as good as a short, locally unique id. Well, I've learned that in networks, you want to go for simple, uncomplicated designs. It may not be theoretically minimal, but the simple brute force stuff is a lot more robust and forgiving, and that's worth a great deal. Globally unique flow id's just sound much simpler (not for the simple stuff, but things like error recovery, etc, which can get hairy with local id's) and foolproof, and that's a big attraction to me. There are lotsa good reasons for the EID/address split, but I'm not sure that fast flow lookup is at the top of my list. Indeed, it may be less attractive to use EIDs to disambiguate flow hash tags than it is to abbreviate EID information by locally unique flow ids. Sigh, I've been taking the steps in threes again! I left out the stuff about why I like having global flow id's, and once you put that in, together with always having the source and destination EID's in the packet anyway (for other robustness/error recovery reasons) I think it makes more sense. To be honest, it's not the top of my list either, it just all fits together so nicely it has to be right! It is probably the case that a flowish paradigm makes EIDs cheaper, not vice versa. You got a bit too terse there for me. Could you expand this a bit so I can make sure of your meaning? Noel From owner-Big-Internet@munnari.oz.au Fri Apr 16 14:56:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01600; Fri, 16 Apr 1993 14:57:36 +1000 (from owner-Big-Internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01577; Fri, 16 Apr 1993 14:56:24 +1000 (from minshall@wc.novell.com) Received: from Untitled ([130.57.64.145]) by wc.novell.com (4.1/smi4.1.1.v91190) id AA15838; Thu, 15 Apr 93 21:55:13 PDT Date: Thu, 15 Apr 93 21:55:11 PDT Message-Id: <9304160455.AA15838@wc.novell.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com (Unverified) Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Cc: big-internet@munnari.oz.au Noel, > There is no agreement on ... how much structure do they have > >This statement is also confused. They *have* no usable structure, any more >than IEEE 48-bit numbers do. Again, I can't see how anyone could have bothered >to read any EID mail and think this. Well, i'm not just anyone... But there *is* structure in terms of an assignment hierarchy (or some such). IEEE 48-bit numbers have this form of structure. There is also the question of whether one can do a gethostbyEID() on an EID. If so, then this imposes requirements on EID's which presumably mandate more structure. I think that what you want to say is that an EID does not necessarily bear any relationship to the topology of the internet. Trying to express this "no structure" constraint precisely seems, actually, a bit tricky. The following is a stab: There exists no "simple function" F(eidA, eidB) such that absolute-value(F(eidA, eidB) - topological-distance(eidA, eidB)) is (for every eidA, eidB) less than 0.5*topological-distance(eidA, eidB). (A "simple function" here is a function which is limited to the use of boolean and arithmetic operations with no "oracular" knowledge (and, thus, no networking!).) (Is there such an F() for IP addresses? No. The reason, of course, is that separate IP networks don't have any pre-defined topological relationship. But, by looking at two IP addresses, i *can* say whether they are or are not in the same IP network. Thus, i still haven't captured this right. Hmm...) Greg Minshall From owner-Big-Internet@munnari.oz.au Fri Apr 16 15:07:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01895; Fri, 16 Apr 1993 15:08:06 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01888; Fri, 16 Apr 1993 15:07:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15862; Fri, 16 Apr 93 01:07:34 -0400 Date: Fri, 16 Apr 93 01:07:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304160507.AA15862@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, john@iastate.edu Subject: Re: The master has spoken (was Re: Ullmann's IPv7 (was Re: re: EIDs...)) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Gee, I wonder why people might not read your mail... Hey, if they don't want to spend the time plowing through them, that's fine with me. Lots of people have better things to do with their time. I just object if they don't, and then make thumbs up/down decisions on things (like EID's) that are discussed there without understanding (apparently) some basic things about them, because they won't put in the time to read. Noel From owner-big-internet@munnari.oz.au Fri Apr 16 15:53:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03542; Fri, 16 Apr 1993 15:53:41 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29239; Fri, 16 Apr 1993 14:04:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15614; Fri, 16 Apr 93 00:03:47 -0400 Date: Fri, 16 Apr 93 00:03:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304160403.AA15614@ginger.lcs.mit.edu> To: ams@eitech.com, jnc@ginger.lcs.mit.edu Subject: Re: IPv7 ... Cc: ULLMANN@process.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Seems to me that having hierarchical addressing with a fixed number of levels and a stable average fan-out for each level doesn't do anything to change the routing problem from O(N) -- all it does is change a constant in the cost calculation. Of course, if the constant is comparable to the upper bound for N, it might make all the difference. Yes, all true, which is why I don't like scheme with fixed size addresses, or fixed numbers of levels! (You will not that Nimrod has neither!) I think if you wanted to make a hierarchical routing algorithm O(log N) you'd have to arrange to make the product of the number of levels and the average fan-out scale with log N. This is approximately correct; my formal math on this is a little rusty, but I think that product has to be better than O(log N), actually, since routing overhead is greater than O(D) (where D is the number of destinations) process; it's more complicated than just a straight table lookup to find even close to optimal routes. So, if D is growing at O(log N), routing overhead is growing at greater than O(log N). Noel From owner-big-internet@munnari.oz.au Fri Apr 16 17:55:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB07870; Fri, 16 Apr 1993 17:55:34 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01764; Fri, 16 Apr 1993 15:01:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15815; Fri, 16 Apr 93 01:00:42 -0400 Date: Fri, 16 Apr 93 01:00:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304160500.AA15815@ginger.lcs.mit.edu> To: Garrett.Wollman@uvm.edu, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu you don't have to know which address to use; some router on the way to the other interface should send you an ICMP redirect if there's a better way. Keith McCloghrie (kzm@hls.com) and I went around for a while on this. Rather than rehash the whole thing, I'll simply include his final sumup, which says it better than I did! 2. Assuming that EIDs are used, then the selection of an address is a policy decision, which therefore should be considered as just another factor to be handled by policy routing, where the host specifies the policy and routers find an appropriate route. 3. Taking this policy approach a little further, one aspect of policy would be which destination address to use for the specific destination EID, i.e., it would be optional for the source host to specify a destination address - if it does, then the routers must deliver the datagram to the destination EID at the specified destination address; if the source host doesn't specify a destination address, then the routers can deliver the datagram to the destination EID at any of its addresses. I agree completely with this model. The only slight quibble I have is with his statement (in 2) that "routers find an appropriate route"; in the current architecture, the boxes which handle the forwarding of packet traffic also decide about the route. I think that in the future these functions are likely to be split up, with the latter being performed by "route servers". If so, we'd modify his statement from "routers find" to "route servers find". The only problem, of course, is that it's a static configuration file. We need to develop a system whereby this information can be calculated and distributed automatically, based on site-specific criteria Well, again, I think this is just a (tiny :-) part of the whole policy routing configuration/setup stew. I know how to get the information around as to what is allowed and available where: figuring out how the users can use it is an as yet unplumbed ball of string! (Yes, yes, I'm looking under the streetlight a bit! However, I'm virtually certain that *whatever* mechanism we use to make these decisions, it is goign to need exactly this info as input, so I don't claim I'm totally avoiding the issue.) Noel From owner-big-internet@munnari.oz.au Fri Apr 16 21:08:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13802; Fri, 16 Apr 1993 21:09:06 +1000 (from owner-big-internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11378; Fri, 16 Apr 1993 06:10:46 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA02973 (5.65/6.02); Thu, 15 Apr 93 16:08:37 -0400 Date: Thu, 15 Apr 93 16:08:37 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9304152008.AA02973@sadye.emba.uvm.edu> To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: big-internet@munnari.oz.au Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) In-Reply-To: <9304150514.AA00514@bigriver.Eng.Sun.COM> References: <9304150514.AA00514@bigriver.Eng.Sun.COM> < Vince, Bob, > A problem I have with EID's is that as a general concept they are simple > to understand, but doesn't seem to be any agreement as to what they are. They are opaque blobs. > There is no agreement on their size (are six bytes IEEE addresses big > enough, maybe not for the global internet, how about eight bytes?); There doesn't need to be; all that is needed is that they be unique. PIP uses 64-bit EIDs, which should be "enough", by the same argument that Steve Deering uses to say that 64-bit SIP "addresses" are sufficient. > whether they represent an interface, computer, process, or something > else; They don't represent interfaces; that we can all agree on. What they do represent is one end of a conversation; one computer might have multiple EIDs (perhaps it has several separate TCP state machines), or one EID might belong to several computers (a multicast group), or several EIDs might migrate from computer to computer (process mobility). > are they portable (when you get a new computer do you reuse your EID > or get a new one); It doesn't really matter in the abstract sense. As a rule of thumb, IF you are assigning EIDs to hosts, and IF the new host has the same function as the host it replaces (with respect to other hosts), then it should probably reuse the same EID. But no correct protocol should depend on this. > who assigns them; Doesn't matter, so long as they are unique. > how much structure do they have; As I said before, they are opaque objects. As far as the protocols are concerned, they have no structure. Now, for /administrative/ purposes, you might want to give some structure to them, but any EID-using protocol should have no knowledge about their format. > how are they assigned. Doesn't matter, so long as they are unique. (Gee, is there an echo in here?) > Each of these decision points has major effects on the design of > the protocols which would use them. No. (no... no... ... no) EIDs are opaque WRT the protocols which use them. > [W]e are a long way from any sort of consensus on their practical > utility. On the contrary, I think that there is considerable consensus, at least on the part of the ``EID Supporters Club''. Those of us who have had this ``aha'' experience about how they can help solve some of the thornier problems in networking, seem to pretty much agree on these issues; if only the rest of you weren't so thick-headed :-) . > So far everything that can be done with EIDs can also be done with > addresses. I'll just agree with Noel's response to this point. > It is still not clear to me that the benefit justifies the cost. I firmly believe that the cost is no greater than the cost of administering IPv4 addresses. I expect that IP:tng will fully support some sort of dynamic address assignment, so the total cost IMO should be not more than 10% more than it is now. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Fri Apr 16 23:51:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19316; Fri, 16 Apr 1993 23:51:49 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19311; Fri, 16 Apr 1993 23:51:35 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 16 Apr 93 09:51:24 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 16 Apr 93 09:51:23 EDT Date: Fri, 16 Apr 93 09:51:23 EDT From: francis@thumper.bellcore.com (Paul Francis (formerly Paul Tsuchiya)) Message-Id: <9304161351.AA00834@tsuchiya.bellcore.com> To: Bob.Hinden@eng.sun.com, Garrett.Wollman@UVM.EDU Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Cc: big-internet@munnari.oz.au In Bob Hinden's message on EIDs, he asks the following question..... > who assigns them; My answer to that is, the same outfit that assigns the group IDs for SIP. :-) PX From owner-Big-Internet@munnari.oz.au Sat Apr 17 01:00:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22396; Sat, 17 Apr 1993 01:00:23 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22376; Sat, 17 Apr 1993 01:00:03 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA24319; Fri, 16 Apr 93 07:59:35 -0700 Message-Id: <9304161459.AA24319@Mordor.Stanford.EDU> To: Tony Li Cc: fbaker@acc.com, big-internet@munnari.oz.au Subject: Re: apology Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 15 Apr 93 15:31:57 -0700. <199304152231.AA10394@lager.cisco.com> Date: Fri, 16 Apr 93 07:59:34 -0700 From: Dave Crocker X-Mts: smtp Tony & Fred, Curiously, I believe it might be helpful to attempt refinement of the descriptions started by Eric, re-done by Fred, and now starting to get comments. To do that, we probably need to be careful about what we do and do not TRY to say. The wordings are attempting to describe a) technical focus, and b) apparent constituency. The latter, of course, is the minefield. We all need to walk pretty carefully. But the technical description can prove remarkably tough. For example, I believe that the SIP folks also claim that we shouldn't re-invent the wheel. In their (ok... "our") case, the wheel is IP and its protocol, software, operations, and support infrastructure. The effect, then, is that SIP and TUBA focus on different details of being conservative (by virtue of preservation/minimization). I suggest that the wordings, therefore, attend to this level of distinction, since the broader one doesn't distinguish them sufficiently. As to constituency, participation in the TUBA demo by Merit, 3Com and cisco, would certainly point to a preference by service providers and router vendors. Participation in the SIP/IPAE demo by 5 vendors of end-user platform software suggests that Eric's original assessment is about right. (Not sure how to characterize Network General's participation.) It probably IS true that historical OSI-ite's, such as NIST, favor TUBA also. Dave From owner-big-internet@munnari.oz.au Sat Apr 17 01:20:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23116; Sat, 17 Apr 1993 01:21:28 +1000 (from owner-big-internet) Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16605; Fri, 16 Apr 1993 22:39:12 +1000 (from atkinson@itd.nrl.navy.mil) Received: from mason.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19709; Fri, 16 Apr 93 08:38:48 EDT Return-Path: Received: by mason.itd.nrl.navy.mil; Fri, 16 Apr 93 08:38:45 EDT Date: Fri, 16 Apr 93 08:38:45 EDT From: atkinson@itd.nrl.navy.mil Message-Id: <9304161238.AA03794@mason.itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: still trying to understand EIDs Noel, I'm still trying to fully understand things relating to EIDs. I'm sure I don't understand things very well right now, so I'm soliciting some educational help. I'm doing it via the list in the belief that there are probably one or two others who are also a bit confused/ignorant of the details here. Feel free to take this offline if you think it appropriate... -- In your conception do EIDs have to map 1-1 with end systems ? -- Can an end system have more than one EID ? -- Would the presence of EIDs affect how addresses were allocated or how many addresses a host could have ? -- What mechanism would be used to perform EID <--> Address translation ? -- Why would the overhead of EID <--> Address translation not be a problem (please consider number of round trips required for a connection over a transcontinental high BW-delay product network) ? -- How big would an EID need to be and how would they be structured and administered (e.g. would this be another thing that network ops folks would have to look after and maintain) ? Thanks very much (in advance) for the clarifications. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Sat Apr 17 01:58:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24538; Sat, 17 Apr 1993 01:58:25 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24528; Sat, 17 Apr 1993 01:58:00 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA18544; Fri, 16 Apr 93 08:57:43 PDT Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA12568; Fri, 16 Apr 93 08:56:44 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA23094; Fri, 16 Apr 93 08:56:40 PDT Date: Fri, 16 Apr 93 08:56:40 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9304161556.AA23094@bigriver.Eng.Sun.COM> To: francis@thumper.bellcore.com (Paul Francis (formerly Paul Tsuchiya)) Cc: big-internet@munnari.oz.au In-Reply-To: <9304161351.AA00834@tsuchiya.bellcore.com> Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Content-Length: 116 Paul, How about if I assign EID's. I will charge $1 each. Guaranteed to be unique or your money back. :-) Bob From owner-Big-Internet@munnari.oz.au Sat Apr 17 03:33:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27819; Sat, 17 Apr 1993 03:34:19 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27737; Sat, 17 Apr 1993 03:33:16 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA03672; Fri, 16 Apr 93 10:32:52 -0700 Message-Id: <9304161732.AA03672@Mordor.Stanford.EDU> To: atkinson@itd.nrl.navy.mil Cc: big-Internet@munnari.oz.au Subject: What's wrong with this picture? (was: Re: still trying to understand EIDs) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 16 Apr 93 08:38:45 -0400. <9304161238.AA03794@mason.itd.nrl.navy.mil> Date: Fri, 16 Apr 93 10:32:52 -0700 From: Dave Crocker X-Mts: smtp Heuristics can be very helpful. One that I find myself invoking here is clarity-vs-time. EIDs have been under discussion for a very, very long time. They have been discussed very, very heavily. Confusion remains. EIDs are failing the heuristic test. In the absence of concrete specifications, with clear, precise, concrete, hopefully simple, definitions of terms and clear, precise, concrete, hopefully simple, explanations of use, then it seems quite strange to maintain that they are useful. I.e., isn't it time to stop debating concepts and, instead, consider highly concrete specifications? On the average, I think the IETF discusses concepts rather badly and specifications rather well. Dave From owner-Big-Internet@munnari.oz.au Sat Apr 17 04:56:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00773; Sat, 17 Apr 1993 04:56:33 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00767; Sat, 17 Apr 1993 04:56:12 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Fri, 16 Apr 1993 11:55:45 -0700 Date: Fri, 16 Apr 1993 11:55:45 -0700 From: Tony Li Message-Id: <199304161855.AA00623@lager.cisco.com> To: dcrocker@Mordor.Stanford.EDU Cc: fbaker@acc.com, big-internet@munnari.oz.au In-Reply-To: Dave Crocker's message of Fri, 16 Apr 93 07:59:34 -0700 <9304161459.AA24319@Mordor.Stanford.EDU> Subject: apology Dave, As to constituency, participation in the TUBA demo by Merit, 3Com and cisco, would certainly point to a preference by service providers and router vendors. This is an erroneous conclusion. cisco has explicitly expressed NO preference for ANY IPng proposal. Participation in the TUBA demo was the result on the work of ONE engineer who wished to develop the prototype software. The engineer involved does indeed prefer TUBA. Participation in the SIP/IPAE demo by 5 vendors of end-user platform software suggests that Eric's original assessment is about right. (Not sure how to characterize Network General's participation.) I disagree with this conclusion as well. I would conclude that the active lobbying effort by the SIP camp was effective in attracting attention. It is not clear that a) they endorse this solution or b) that they ever prefer this solution. As no other solution performed active lobbying (that I know of), I can attach no technical significance to the number or flavor of the demo systems shown. Tony From owner-big-internet@munnari.oz.au Sat Apr 17 06:12:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03224; Sat, 17 Apr 1993 06:12:29 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23761; Sat, 17 Apr 1993 01:39:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17859; Fri, 16 Apr 93 11:39:01 -0400 Date: Fri, 16 Apr 93 11:39:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304161539.AA17859@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, minshall@wc.novell.com Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu KRE> I agree with all of Noel said, except for ... JNC> This statement is also confused. They *have* no usable structure, any JNC> more than IEEE 48-bit numbers do. Again, I can't see how anyone could JNC> have bothered to read any EID mail and think this. KRE> I believe EIDs will have just the same kind of structure as IEEE 48 KRE> bit numbers, that is, structure that indicates who or what allocated KRE> the particular number in question, but which is useless for almost KRE> anything else. GM> But there *is* structure in terms of an assignment hierarchy (or some GM> such). IEEE 48-bit numbers have this form of structure. Arrghhh! Either I say it all in very detailed and exact language, and we get a Noelgram that nobody reads because it is too long, or I say it short, and I don't get the message across clearly. I can't win! :-) Yes, I realize there is a small amount of structure in IEEE 48-bit numbers. Not only is there the allocation heirarchy (the 24 bits of OUI), but (as Vernon Schryver pointed out to me) there is the multicast bit. However, most of this is not *usable* structure (which is what I said: I didn't say they had *no* structure, just "no *usable* structure"); your Ethernet interface doesn't (and probably can't) do anything with the OUI. Yes, EID's will have some sort of allocation structure, much like IEEE 48-bit numbers (and again, this is what I said: "no ... more than IEEE 48-bit numbers do"). KRE> Noel didn't touch the question of how big EIDs are, the impression I KRE> had, perhaps because its also what I supported, was that they should KRE> be 8 bytes - there were some 6 byte advocates. I guess I've been thinking 8 bytes a) since it's a round number for machine hacking (either 2 long-words on most of today's machines, or one word on the likely next generation), and, as pointed out by Chuck Davin, we want these things to be efficient, and b) this way we can embed the entire IEEE space whole (a ready made source of allocated unique numbers), while still leaving lots of space for other stuff we might want to do (e.g. mobile processes). However, it's not a big issue; 6, 8, whatever; it's a very second-order question, *especially* given that many people don't even agree we need them. GM> There is also the question of whether one can do a gethostbyEID() on GM> an EID. If so, then this imposes requirements on EID's which GM> presumably mandate more structure. Well, not necessarily. However, this is a tricky question. First, my concept is that only in unusual (i.e. error handling, etc) situations would one need to do an EID->anything translation. So, the mechanism doesn't have to be *efficient*. Second, I can imagine building an IEEE->anything translation in a distributed, replicate way which *did not* involve people having giant, complete table; the same could be true of EID's. Ross Callon and I went over how this could work in some detail on this Big-I list last August (see the archives). I won't claim there are *no* hitches; the chief one is "how do you authentically update the mapping since random people are likely to be thrown next to each other in this database". This can lead me to partial agreement with those who have said there may be good reasons to effectively include administrative hierarchy in EID's. Your EID would come from a space controlled by your organization, which would be delegated the responsibility of maintaining the EID->anything mapping database, and could use whatever authentication measures it deemed necessary. However, the whole issue is quite tricky, because to get a level of authenticity X at level K in the (presumably hierarchical) lookup process, all levels 0, 1, .., K-1 would also have to be at least that secure. The problems of securing this translation are exactly the same as those of securing the DNS, and it's not easy, *especially* in the presence of dynamic, in-band updates to the mapping. It's not clear that in the end you really wind up with anything simpler this way. So, perhaps another solution is to make this mapping be a piece of the network infrastructure, e.g. like the telephone White Pages. When you pay whoever allocates EID's (ISOC, or some delegated regional/whatever authority) to be allocated some EID's, you pay them to maintain the mappings for them. GM> I think that what you want to say is that an EID does not necessarily GM> bear any relationship to the topology of the internet. This is definitely and completely true. However, that is still not a definitive definition of what, if anything, you can tell about an EID by looking at it, and what use that information is. I tend to prefer to err on the side of "as little as possible", since the less something does, the less chance there is that you got it wrong! :-) Not to be flip, but things which do just one thing, and well, seem to age better than things that try to do three things, and do none well. Trying to build an internetworkign architecture which will age well is my primary goal here; if it lasts a long time, it has to be because it's right. Noel From owner-big-internet@munnari.oz.au Sat Apr 17 06:12:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03228; Sat, 17 Apr 1993 06:12:48 +1000 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01816; Sat, 17 Apr 1993 05:37:25 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Fri, 16 Apr 1993 12:36:46 -0700 Date: Fri, 16 Apr 1993 12:36:46 -0700 From: Tony Li Message-Id: <199304161936.AA02549@lager.cisco.com> To: dcrocker@Mordor.Stanford.EDU Cc: fbaker@acc.com, big-internet@munnari.oz.au In-Reply-To: Dave Crocker's message of Fri, 16 Apr 93 12:09:06 -0700 <9304161909.AA06430@Mordor.Stanford.EDU> Subject: IPng political bullshit (don't know how to interpret the subject line text of your message.) Sorry, I inherited it. I've changed it so that it's more appropriate. But patterns of actual investment in time and effort do seem significant to me. To ascribe the investment to the corporation is erroneous. The remainder of the pattern is thus clearly broken. The only reasonable conclusion is that the individuals involved are interested. It's not even clear that they prefer the particular solution. Attention? Sorry, but this was more than attention. This was a very considerable amount of very sustained effort by most of the participants. Each of these companies spent valuable resources. But as you point out, it's on the level of a few days. [BTW, the difficulty of doing TUBA is on this order too, given a working CLNP as a base.] I don't consider a few days to be a significant investment. Do you consider the time that I spend in sending this mail message to be a significant investment? It's not.... As no other solution performed active lobbying (that I know of), I can attach no technical significance to the number or flavor of the demo systems shown. No technical significance? When two of the participants cite the ability to deliver full, working versions after very few HOURS of effort, and a couple more cite small numbers of DAYS, starting from scratch, I'm afraid that I count that as technically significant. Trying to turn the sword, eh Dave? The facts are these: SIP went out and actively recruited people to do SIP demo implementations. No one else did this. As a result, SIP had more demo systems. SIP folks chose the people that they would lobby. This choice was reflected in the demo systems that were presented. The effort that went into the SIP implementation is almost irrelevant. The sole point is that the development is tractable. But that has been shown to be the case for all of the demo'ed proposals. Tony From owner-big-internet@munnari.oz.au Sat Apr 17 06:12:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03332; Sat, 17 Apr 1993 06:16:27 +1000 (from owner-big-internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26150; Sat, 17 Apr 1993 02:49:07 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA13816; Fri, 16 Apr 93 09:48:46 PDT Date: Fri, 16 Apr 93 09:48:46 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9304161648.AA13816@saffron.acc.com> To: tli@cisco.com Subject: Re: apology Cc: big-internet@munnari.oz.au Tony: >> "It argues that the principal problems which we face are the >> size of an IP address and its lack of hierarchy." >> >> I believe that we have consensus that this is primary problem that >> _all_ of the proposals are trying to solve. If there is dissent here, >> I believe that we should discuss this NOW. I don't believe that this represents the consensus, and while all of the proposals are solving this problem, few of them are solving *only* this problem. Each, with the possible exception of SIP, solves something else as well, and much of the debate centers on the "something else" being solved. The part of the consensus that I believe exists and that you don't mention above is that an IPv4 coexistence strategy must exist which can be used by all hosts for a short (< 3 year) period and by some hosts indefinitely, which does not involve changing host software or user procedures. In other words, current investment must be preserved. From owner-Big-Internet@munnari.oz.au Sat Apr 17 07:46:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05788; Sat, 17 Apr 1993 07:48:09 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05767; Sat, 17 Apr 1993 07:46:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20654; Fri, 16 Apr 93 17:45:02 -0400 Date: Fri, 16 Apr 93 17:45:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304162145.AA20654@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, francis@thumper.bellcore.com Subject: Re: Ullmann's IPv7 (was Re: (ex) re: EIDs...) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu How about if I assign EID's. I will charge $1 each. Guaranteed to be unique or your money back. :-) Jeez, I better go patent them; I could snarf a royalty! :-) Noel From owner-big-internet@munnari.oz.au Sat Apr 17 11:40:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12222; Sat, 17 Apr 1993 11:40:45 +1000 (from owner-big-internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06464; Sat, 17 Apr 1993 08:14:45 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA22015; Fri, 16 Apr 93 18:16:13 -0400 Date: Fri, 16 Apr 93 18:16:13 -0400 Message-Id: <9304162216.AA22015@worldlink.worldlink.com> From: David M. Piscitello To: big-internet@munnari.oz.au Subject: progress? >Dave Crocker wrote: > 1. We are probably relying far to heavily on CIDR's fixing the > immediate problem, given that it has not been shown to accomplish > its assigned task, > 2. It is expensive to keep these competitive efforts going in > parallel and the longer they continue the more likely we are to > be faced with having to continue support for each, since each will > develop an installed base, > 3. None of the projections take into account unplanned growth That is, > if we open up a major new market segment, it could cause a serious > explosion in IP number/net usage, far beyond the current calculations. > 4. A standard rule of project management is that is if you can't afford > to lose, make sure you don't. Make sure that scheduling and the > availability of alternate solutions leave you with a fall-back path. > I believe that the view you are espousing leaves us very exposed. Interesting points, but.. W/R/T #1, I'm not as skeptical about CIDR as Dave C. Perhaps that puts me in the minority, but I'm beginning to feel rather comfortable here (and besides, the company is very nice:-) I'm *really* curious about #2, since I don't get a sense that anyone is committing serious R&D to any of the solutions, but rather, that folks championing each solution are "making time" to do investigate one or more alternatives. I'd be delighted to be proven wrong; can someone show me a bona fide product plan from a vendor, or more accurately, a *funded* plan, with an honestToGoodness delivery date? #3. Unplanned growth, unplanned pregnancies, unexpected storms--we all live in a constant state of denial of one form or another--it won't happen to us. Why is this effort so different? (save the flame, I'm joking...) #4. duh... is this one of those brass-plaque inspirational messages you can by from airline magazines or what? Funny, I was under the impression that we're all working to CYA. From owner-big-internet@munnari.oz.au Sat Apr 17 12:40:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14224; Sat, 17 Apr 1993 12:41:40 +1000 (from owner-big-internet) Return-Path: Received: from hp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08218; Sat, 17 Apr 1993 09:19:07 +1000 (from chitgo@hpindlm.cup.hp.com) Received: from hpindlm.cup.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA19348; Fri, 16 Apr 93 16:18:43 -0700 Received: from localhost by hpindlm.cup.hp.com with SMTP (16.6/15.5+IOS 3.20+cup+OMrelay) id AA18683; Fri, 16 Apr 93 16:20:19 -0700 Message-Id: <9304162320.AA18683@hpindlm.cup.hp.com> To: big-Internet@munnari.oz.au Subject: Re: still trying to understand EIDs In-Reply-To: Your message of "Fri, 16 Apr 93 08:38:45 PDT." <9304161238.AA03794@mason.itd.nrl.navy.mil> Date: Fri, 16 Apr 93 16:20:18 PDT From: Sunil Chitgopekar > Feel free to take this offline if you think it > appropriate... Noel, Please don't answer the questions offline .. Some of us who started late would like to get educated too ! Regards: Sunil Chitgopekar From owner-big-internet@munnari.oz.au Sat Apr 17 15:24:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20259; Sat, 17 Apr 1993 15:25:26 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03168; Sat, 17 Apr 1993 06:07:45 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA08238; Fri, 16 Apr 93 13:07:11 -0700 Message-Id: <9304162007.AA08238@Mordor.Stanford.EDU> To: Tony Li Cc: fbaker@acc.com, big-internet@munnari.oz.au Subject: Re: IPng political bullshit Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 16 Apr 93 12:36:46 -0700. <199304161936.AA02549@lager.cisco.com> Date: Fri, 16 Apr 93 13:07:10 -0700 From: Dave Crocker X-Mts: smtp Tony. Sigh. ---- Included message: (don't know how to interpret the subject line text of your message.) Sorry, I inherited it. I've changed it so that it's more appropriate. If you are going to to reference bodily functions, please at least strive for accuracy in the selection. Apparently you are intent on reducing this discussion to a pissing contest. While I'm tempted to further use the imagery, delicacy for the international scope of distribution of this list prevents that indulgence. If you wish to step out to a private email parking lot, I'll be glad to discuss the fine points of such issues further. (Gosh, that was fun. Now, could we endeavor for a bit of restraint, Tony?) But patterns of actual investment in time and effort do seem significant to me. To ascribe the investment to the corporation is erroneous. The Well, perhaps your own company's profits are high enough to consider expenditure of senior technical talent to be insignificant, but most of the ones I know about aren't. There is a big step between full, strategic commitment and insignificant. Dismissing such investments out of hand is a curious analytic tack. The only reasonable conclusion is that the individuals involved are interested. Perhaps for some of the efforts, but definitely not all. Some of these efforts have been far too visible to their corporate management, and sometimes have included that management. Attention? Sorry, but this was more than attention. This was a very considerable amount of very sustained effort by most of the participants. Each of these companies spent valuable resources. But as you point out, it's on the level of a few days. [BTW, the Now you resort to mis-application. Product delivery has engineering effort on the level of 10-15%. Similarly, the SIP/IPAE effort has involved rather more than software coding. My citation was only for the coding effort. Working group participation and demo staging, setup, etc. have involved rather more time. To repeat, the investment is considerably more than the coding time. The involvement has typically been more than just personal. The effort that went into the SIP implementation is almost irrelevant. What a remarkable dismissal of a 6-vendor demonstration. Particularly given the IETF's special emphasis on 'doing the technical work'. You've taken a major and essential premise of the community and claimed it's irrelevant. The sole point is that the development is tractable. But that has been shown to be the case for all of the demo'ed proposals. Technical feasibility is only one implication of such efforts. Degree of constituency and EASE of effort are others. Perhaps YOU don't find it significant that the effort was easy for six, independent participants, but I sure do. Dave ld be used to perform EID <--> Address translation ? Well, for EID->anything translations, I talked about this a bit, and there are a number of options, but one simple-minded mechanism that is easy to imagine is just something like the IN-ADDR domain in the DNS. (For those who don't know what this is, you can look up 82.0.26.18.IN-ADDR int he DNS and get back ginger.lcs.mit.edu, i.e. this machine.) If you're worried about the security of that translation, require the EID->whatever translation to contain a checksum of the entire entry encrypted with a private key (of a private/public pair) associated with that endpoint. (How you get the public key securely is known art in the authentication world.) I can't see too many uses for address->EID translation, but you would get that for free from IN-ADDR type stuff (since inaddr returns you a pointer to the DNS name). -- How big would an EID need to be and how would they be structured and administered (e.g. would this be another thing that network ops folks would have to look after and maintain) ? Again, I talked about this. Something like IEEE numbers are administered, maybe? If we have 8 byte EID's, we could even embed the whole IEEE space in it, so you'd get an EID with ever 802.* interface... Noel From owner-big-internet@munnari.oz.au Sat Apr 17 15:24:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20263; Sat, 17 Apr 1993 15:25:47 +1000 (from owner-big-internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05050; Sat, 17 Apr 1993 07:18:44 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA08115 (5.65/6.02); Fri, 16 Apr 93 17:17:49 -0400 Date: Fri, 16 Apr 93 17:17:49 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9304162117.AA08115@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Garrett.Wollman@uvm.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: address vs. EID, revisited... In-Reply-To: <9304160500.AA15815@ginger.lcs.mit.edu> References: <9304160500.AA15815@ginger.lcs.mit.edu> <> 3. Taking this policy approach a little further, one aspect of >> policy would be which destination address to use for the specific >> destination EID, i.e., it would be optional for the source host to >> specify a destination address - if it does, then the routers must >> deliver the datagram to the destination EID at the specified >> destination address; if the source host doesn't specify a >> destination address, then the routers can deliver the datagram to >> the destination EID at any of its addresses. > I agree completely with this model. Hmmm. One of the ideas that I've been toying with (it was mentioned as a footnote in my NAP I-D), is to simply not give addresses to most hosts. Rather, we give addresses to ``subnets'', which could be simply subnets as in the current IPv4 model, or ISIS bottom-level areas, or something even more complex. Assuming that all a host's interfaces are in the same ``subnet'', which I think would be the usual case (it is around here), then this would completely eliminate the multi-homed host problem. Let me give a specific example of how I see the problem here. We have a large NFS server which is responsible for almost all our users' files. This machine is multihomed on three subnets (a lab Ethernet, a time-sharing Ethernet, and a FDDI ring); we would like all the hosts in the lab to use the local interface (gate-lal), the other host on the FDDI to use that (fddi-lal), the time-sharing machines to use their local interface (lal), and everything else to use whichever subnet is less loaded(*). All the interfaces have different DNS names so that most of this can be done, but the load-balancing is simply impossible. (You might argue that this is mostly deficiencies in NFS, and I might agree somewhat.) Now, here's my solution... All of EMBA's subnets (there are ten of them) are considered to be a single area, ISIS-style. None of the machines have their own addresses; rather, they are addressed by , and our router:tng---which knows which EIDs have been spotted on which wires---sends the packet to whichever interface it wants, based on a policy decision *we* have made. (NB: /We/ will decide which interface to use, not some remote host which is not under our control.) For a local host sending NFS:tng to our server, the destination is simply ; an ESIS-like protocol will hide the need for forwarding if it exists. Now you can tell me whose existing protocol I've just reinvented... -GAWollman (*) In case you're wondering, yes. We also have machines called `hal' (compute server), `sal', and `xal' (X terminal server). -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Sun Apr 18 01:11:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09974; Sun, 18 Apr 1993 01:11:49 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09969; Sun, 18 Apr 1993 01:11:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27490; Sat, 17 Apr 93 11:11:35 -0400 Date: Sat, 17 Apr 93 11:11:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304171511.AA27490@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: "The more things change" department... Cc: jnc@ginger.lcs.mit.edu Date: Fri, 12 Jun 92 14:16:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) To: big-internet@munnari.oz.au any addressing schemes (eg. fixed length node id Fixed length node (endpoint's, I call them now) ID's are *not* an addressing scheme! How many times do I have to say this? You can't tell a [expletive deleted] thing about where the [e.d.] thing is by looking at the ID. That's why it's called an ID! Gee, how time flies when you are having fun. Only 10 months ago... :-) Noel From owner-Big-Internet@munnari.oz.au Sun Apr 18 01:40:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11130; Sun, 18 Apr 1993 01:40:32 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11116; Sun, 18 Apr 1993 01:40:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27554; Sat, 17 Apr 93 11:40:12 -0400 Date: Sat, 17 Apr 93 11:40:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304171540.AA27554@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu Subject: Re: What's wrong with this picture? (was: Re: still trying to understand EIDs) Cc: big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu EIDs have been under discussion for a very, very long time. They have been discussed very, very heavily. Confusion remains. .... In the absence of concrete specifications ... it seems quite strange to maintain that they are useful. I've been puzzling over this message a long time, trying to figure out what is bothering you, and how to respond. I don't think the real problems are the ones you cite (or even the lack of documentation, etc). Exactly what is going on I can't say for sure, obviously, but let me make a few points. Confusion: There may not be general agreement among *everyone* out there on all details of endpoints/EIDs, I expect that *basically all* the EID proponents do have a core set of things we *do agree* on. I expect it looks something like: - endpoints are those indivisible entities which communicate on an end-end basic (e.g. one end of a TCP connection) - endpoints ought to have a naming space which is separate from the naming space for network attachment points (i.e. addresses) - the endpoint naming space should consist of shortish (6-8 bytes in a new design, 4 bytes in IPv4), fixed length binary identifier - these endpoint names need to be recognized and used at both the internetwork and transport layers - endpoint names (i.e. EIDs) have no relationship to the network topology Sure, there are some questions: is there any administrative structure reflected in EID's, are flows best named with global names which are composed with EID's, etc, but don't let these hide the striking degree of commonality. Documentation: The documentation status is not all it could be, I know. To make it more available, I have typed in what I consider the basic endpoint reference, Jerry Saltzer's paper, and it'll be available as an RFC as soon as I can get the copyright issues straightened out. I am working on an endpoint/EID I-D, but not because I think it will convince you and others who don't see the need for creation of an new endpoint namespace; I'm doing it primarily because we do need such a document when we add endpoints/EID's to the architecture, and secondarily to answer all those who either a) want something to read, or b) cite this as a reason not to believe in EID's. However, this does not obscure the fact that on a number of occasions (e.g. a message to this list, header identification: Date: Wed, 7 Oct 92 10:30:51 -0400, Message-Id: <9210071430.AA25982@ginger.lcs.mit.edu>, as well as again a week or so ago) I have provided a citation for Jerry Saltzer's paper. I know this is not easy to find, but some people have done so. (E.g. John Curran, who made reference to it on a message to this list: Date: Mon, 19 Oct 92 10:52:53 -0400.) If you were really interested in giving a real evaluation to EID's, did you try and locate this paper? You could have asked me to mail you a paper copy if you couldn't find it, but didn't do so. Specifications If you really want to look at concrete specifications, there is at least one fairly fully specified internetworking protocol which uses them: PIP. (I suspect Paul will take unkindly to any suggestion that PIP is not fairly well specified. :-) Note: this is *not* an endorsement of PIP! In addition to basic definition of, and introduction to, PIP ID's (in the document draft-ietf-pip-architecture-00.txt, section 5), the PIP specs fully define the structure and allocation of PIP ID's (in the document draft-ietf-pip-identifiers-01.txt), as well as provide a fully worked mechanism (in section 14 of the architecture document) to use EID's to provide a reasonably secure mobile hosts facility. I am thus at a total loss to understand your complaint of "the absence of concrete specifications, with ... clear, precise, concrete, hopefully simple, explanations of use". It has been repeatedly mentioned on this list that PIP uses EID's, and the PIP documents have been announced via the usual I-D means. Did you ever look at them? To sum up, I cannot find substantial grounds to understand your complaints. I am thus lead to wonder if your opposition to EID's, in part at least, is not connected to the fact that SIP does not have them. I hope the designers and proponents of SIP realize that people who believe (like me) that a new internetworking layer just *absolutely* has to have different naming spaces for i) network attachment points, and ii) communicating entities, will find SIP unacceptable on these grounds alone, and won't need to look further (not that I don't think there are other *major* problems with SIP). This is not "SIP-bashing"; i.e. scrounging up some excuse to beat up a proposal you don't like. May I remind you that endpoints/EID's *way* predate SIP; 'nodes ID's' as separate from 'interface addresses' date *way* back (I pushed them in a talk to the IPWG I gave at ISI in about 1981), and they've been discussed on this mailing list since June '92 (Date: Mon, 8 Jun 92 16:12:01 -0400 to be exact). SIP way postdates that; the first reference to it I found was a presentation Steve gave to an ad hoc meeting in Baltimore in August '92. I think I can thus claim that any opposition to SIP on the grounds that it doesn't include EID's is not purely a reaction to SIP. I've also given the Tuba people a really hard time about their decision to leave EID's out of Tuba, so I'm not picking on SIP alone. Look, if the designers and proponents of SIP have, as a matter of engineering judgement, left out endpoints/EID's from SIP when it was being formulated, that's your choice. However, that is not my engineering judgement, and thus, while I can't speak for others, I personally will continue to argue that SIP is "fundamentally not acceptable" for its lack of differentiation between interfaces and endpoints. Noel From owner-big-internet@munnari.oz.au Sun Apr 18 02:26:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12625; Sun, 18 Apr 1993 02:26:26 +1000 (from owner-big-internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03767; Sat, 17 Apr 1993 22:23:56 +1000 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA22084; Sat, 17 Apr 93 08:23:42 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304170823.ZM22082@tengwar.itd.nrl.navy.mil> Date: Sat, 17 Apr 1993 08:23:42 -0400 References: <9304170729.22989@munnari.oz.au> Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: big-Internet@munnari.oz.au Subject: Re: still trying to understand EIDs I'm still mulling over Noel's response in some areas and will get back to them in due course, but I have a few quick reactions. First, if I understand things correctly, the network admins are going to have to keep not only host names and host addresses in the DNS, but also the EIDs. This is not a show stopper, but can be a real disadvantage given the scarcity of really good network admins for the foreseeable future. For example, consider the ongoing problem of "lame delegations" in the net. I had not particularly been concerned with security once the DNS came into view. (While DNS authentication isn't trivial, I think I fully understand how to do that.) Second, I'm sure that I'll have a need to have a single system have multiple EIDs. The case I'm thinking of in particular is multi-level secure systems which will probably need an EID per sensitivity level if someone decides to get serious about security. Note that the current practice is to have one IP address per sensitivity level but both addresses and EIDs would have to be one per level if EIDs existed. Administrators of MLS systems will be less happy than they are now (they generally aren't happy folks now). Third, It seems to me that traffic in a flow will need to have not only the EID but also the address. It is clear that others don't believe that this is true, but I cannot figure out why/how I'm confused. So maybe that could be clarified again. :-) Fourth, it would give me warm fuzzy feelings if more detail could be given in how these mechanisms would all work. Partly this is because I would understand things better, but partly this is because I've been burned before by items that appeared to be straight forward from the outside but turned out to be very subtle to get correct once I got into the details. Regards, Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Sun Apr 18 02:42:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13094; Sun, 18 Apr 1993 02:42:30 +1000 (from owner-big-internet) Return-Path: Received: from pooh.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05983; Sat, 17 Apr 1993 23:35:08 +1000 (from john@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Sat, 17 Apr 93 08:34:53 -0500 Message-Id: <9304171334.AA19993@iastate.edu> To: tli@cisco.com Cc: dcrocker@mordor.stanford.edu, big-internet@munnari.oz.au Subject: IPng complexity (was Re: IPng political bullshit) In-Reply-To: Your message of Fri, 16 Apr 93 12:36:46 -0700. <199304161936.AA02549@lager.cisco.com> Date: Sat, 17 Apr 93 08:34:52 CDT From: John Hascall [Dave Crocker, Tony Li] DC> No technical significance? When two of the participants cite DC> the ability to deliver full, working versions after very few HOURS DC> of effort, and a couple more cite small numbers of DAYS, starting from DC> scratch, I'm afraid that I count that as technically significant. TL> The effort that went into the SIP implementation is almost irrelevant. TL> The sole point is that the development is tractable. But that has TL> been shown to be the case for all of the demo'ed proposals. I couldn't disagree more. The more complex the IPng layer is, the more likely there are to be botched and/or incompatible implementations (for goodness sakes, there are IPs which don't even get it quite right, yet in this day). I can just see the headline ``rare bug in toaster takes down the internet''. ``billions lost in toast damage worldwide'' ;-) Remember also that one of the pushes for IPng is the push to the ``toaster level'' of ubiquity. To me, this means the protocol better be darn simple, it takes long enough for computer people to apply patches to computers, bugs in toaster software will be forever (I can just imagine my mother getting a prom in the mail from GE). John From owner-Big-Internet@munnari.oz.au Sun Apr 18 05:51:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19289; Sun, 18 Apr 1993 05:51:27 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19286; Sun, 18 Apr 1993 05:51:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29468; Sat, 17 Apr 93 15:51:14 -0400 Date: Sat, 17 Apr 93 15:51:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304171951.AA29468@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Saltzer paper Cc: jnc@ginger.lcs.mit.edu As a result of a number of requests, the Saltzer paper is temporarily available, in machine readable form, via anonymoys FTP, from munnari.oz.au in the file "big-internet/saltzer-naming+binding", As far as I know, we have permission to make copies, but I'm still in the process of verifying this for sure. It will hopefully be available as an RFC when that process is complete. Thanks to Robert Elz for the help making this available. Noel From owner-Big-Internet@munnari.oz.au Sun Apr 18 17:33:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10286; Sun, 18 Apr 1993 17:33:39 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10281; Sun, 18 Apr 1993 17:33:21 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 18 Apr 1993 00:32:50 -0700 Date: Sun, 18 Apr 1993 00:32:50 -0700 From: Tony Li Message-Id: <199304180732.AA01501@lager.cisco.com> To: big-internet@munnari.oz.au Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: EIDs Noel and I were having an offline discussion about EIDs and he suggests that it be brought on-line ... Noel had asked if there was a use for a single/multiple EIDs per endpoint. I suggested: You want to allow an endpoint to use the same EID for multiple TCP connections. One example is improved security for FTP. You would very much like to tie the control and data connections together. [BTW, in case it is not apparent, my model of an endpoint is an interface layer just above a BSD socket and just below an operating system thread. Dunno if this coincides with Noel's.] You want to allow an endpoint to have more than one EID so that it can masquerade as multiple endpoints. For example, a single process may open multiple transport connections which should be routed differently (say they have different QOS). Since these connections should really be treated as separate flows, you want separate EIDs. I won't pick nits here if an operating system thread can control multiple endpoints. I'm not convinced that EID's should be in any way connected to DNS. You should be able to open a transport connection in the usual way and _learn_ the EID of the remote process. For TCP, it shows up with the SYN. In fact, I don't see the point of EID <-> anything translation. Still not convinced that EID's belong in the network layer header, Tony From owner-Big-Internet@munnari.oz.au Mon Apr 19 00:12:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22727; Mon, 19 Apr 1993 00:12:25 +1000 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22720; Mon, 19 Apr 1993 00:12:04 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA12012; Mon, 19 Apr 93 00:12:15 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304181412.AA12012@coombs.anu.edu.au> Subject: Re: EIDs To: tli@cisco.com (Tony Li) Date: Mon, 19 Apr 93 0:12:13 EST Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <199304180732.AA01501@lager.cisco.com>; from "Tony Li" at Apr 18, 93 12:32 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Tony Li, Sie wrote: [...] > You want to allow an endpoint to use the same EID for multiple TCP > connections. One example is improved security for FTP. You would > very much like to tie the control and data connections together. > [BTW, in case it is not apparent, my model of an endpoint is an > interface layer just above a BSD socket and just below an operating > system thread. Dunno if this coincides with Noel's.] > > You want to allow an endpoint to have more than one EID so that it can > masquerade as multiple endpoints. For example, a single process may > open multiple transport connections which should be routed differently > (say they have different QOS). Since these connections should really > be treated as separate flows, you want separate EIDs. I won't pick > nits here if an operating system thread can control multiple > endpoints. Just a point about terminology, you're saying that an "endpoint" can have multiple EIDs. Doesn't that make the "endpoint" something else, such as (maybe) a NSAP ? An "endpoint" should be just that, a point, not a collection of points/EIDs. > Still not convinced that EID's belong in the network layer header, Well, consider the example where the EID is the ethernet number. With current IP over ethernets, you loose the real origin of the packet. If you can reliably put an EID into the network layer and be able to say without any doubts where a packet came from or is going to, then it becomes useful for other things as well. Darren From owner-Big-Internet@munnari.oz.au Mon Apr 19 04:18:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00921; Mon, 19 Apr 1993 04:18:18 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00912; Mon, 19 Apr 1993 04:18:06 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 18 Apr 1993 11:17:44 -0700 Date: Sun, 18 Apr 1993 11:17:44 -0700 From: Tony Li Message-Id: <199304181817.AA28292@lager.cisco.com> To: avalon@coombs.anu.edu.au Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Darren Reed's message of Mon, 19 Apr 93 0:12:13 EST <9304181412.AA12012@coombs.anu.edu.au> Subject: EIDs Just a point about terminology, you're saying that an "endpoint" can have multiple EIDs. Doesn't that make the "endpoint" something else, such as (maybe) a NSAP ? No, absolutely not. An endpoint is NOT an address. An "endpoint" should be just that, a point, not a collection of points/EIDs. It _is_ a point. There is a many-to-one relationship between EIDs and endpoints. Well, consider the example where the EID is the ethernet number. With current IP over ethernets, you loose the real origin of the packet. If you can reliably put an EID into the network layer and be able to say without any doubts where a packet came from or is going to, then it becomes useful for other things as well. The source Ethernet address is not unique (DECnet addresses) and is easily forged, so it's never reliable. Tony From owner-big-internet@munnari.oz.au Mon Apr 19 13:24:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20373; Mon, 19 Apr 1993 13:25:37 +1000 (from owner-big-internet) Return-Path: Received: from pooh.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10879; Mon, 19 Apr 1993 09:18:01 +1000 (from john@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Sun, 18 Apr 93 18:17:38 -0500 Message-Id: <9304182317.AA21852@iastate.edu> To: big-Internet@munnari.oz.au Subject: EIDs revisited (was Re: What's wrong with this picture?) In-Reply-To: Your message of Sat, 17 Apr 93 11:40:12 -0400. <9304171540.AA27554@ginger.lcs.mit.edu> Date: Sun, 18 Apr 93 18:17:37 CDT From: John Hascall ???> EIDs have been under discussion for a very, very long time. They have been ???> discussed very, very heavily. Confusion remains. ... JNC> There may not be general agreement among *everyone* out there on all JNC> details of endpoints/EIDs, I expect that *basically all* the EID JNC> proponents do have a core set of things we *do agree* on. JNC> - endpoints are those indivisible entities which communicate on an end-end JNC> basis (e.g. one end of a TCP connection) JNC> - endpoints ought to have a naming space which is separate from the naming JNC> space for network attachment points (i.e. addresses) ... JNC> - these endpoint names need to be recognized and used at both the internet JNC> work and transport layers Yes, I think we can all see this is what you are suggesting -- the question behind each of these is *why*? What is the benefit of EIDs? What prevents the benefits from being achieved through some other methodology? Why are they at the internetwork layer? [And at the TCP layer too?] Why a separate naming space from network-attachments? John PS, I don't think Saltzer is all that enlightening (he basically argues that networks consist of 4 kinds of objects (services, nodes, attachments, and paths), which should each have bindings from "names" to "addresses". I found his arguments quite breief and I don't find any argument that this involves the internetwork layer. From owner-Big-Internet@munnari.oz.au Mon Apr 19 18:41:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04952; Mon, 19 Apr 1993 18:42:39 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04928; Mon, 19 Apr 1993 18:41:54 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA11777; Mon, 19 Apr 1993 10:44:08 +0200 Message-Id: <199304190844.AA11777@mitsou.inria.fr> To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: EIDs In-Reply-To: Your message of "Sun, 18 Apr 93 00:32:50 PDT." <199304180732.AA01501@lager.cisco.com> Date: Mon, 19 Apr 93 10:44:07 +0200 From: Christian Huitema >Still not convinced that EID's belong in the network layer header, >Tony I am not convinced either. For example, if I read the PIP spec, I find out that the source EID is carried in every packet, but that it's sole purpose is "end to end". Now, what is exactly the end to end function? 1) in a "datagram" environment (UDP), one should be able to deduce a return path for the response (but an address does it well), and one may want to do some authentication filtering -- but I would rather not base my security checks on a field that is merely asserted by the sender! 2) in a "connected" environment (TCP), one should link the incoming packet to a TCP context. This is done today with the "address+port" pair, which does pose a problem when the address changes during the course of a connection. There are workarounds, e.g. encapsulation, which end up carrying two headers instead of one for the small fraction of packets that belong to "movable connections". The EID approach appears to "sanctify" this workaround. It might be a better idea to address the real problem, i.e. the context identification in TCP; after all, the transport protocol could probably make some real use of these 64 bits of gratuitous overhead. In fact, there is even more to say here. The more sophisticated your system, the more you want to remove functionalities from the "bottom" layers and place them "near the application". In which case one will probably use a name (DNS or PEM) rather than a binary ID -- because just after "identifying" the party, one will have to get it's attributes. Like digital signature infos, permissions, etc. I don't see why a flat binary ID would be useful here... Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Apr 19 22:20:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13073; Mon, 19 Apr 1993 22:22:18 +1000 (from owner-Big-Internet) Return-Path: Received: from CSEIC.SAIC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13050; Mon, 19 Apr 1993 22:20:58 +1000 (from carlberg@cseic.saic.com) Received: by cseic.saic.com (4.1/1.34) id AA11497; Mon, 19 Apr 93 08:11:30 EDT Date: Mon, 19 Apr 93 08:11:30 EDT From: carlberg@cseic.saic.com (Kenneth Carlberg) Message-Id: <9304191211.AA11497@cseic.saic.com> To: john@iastate.edu Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) Cc: big-Internet@munnari.oz.au > What is the benefit of EIDs? Arguements of pro can be found in the fall issues of big-internet. Also go back several weeks to mail sent by KRE - the one benefit dearer to my heart relating to mobility (although NOT to be treated as the ONLY reason !!). > What prevents the benefits from being achieved through > some other methodology? As has been pointed out by Noel (and his Turing machine example), simply being *able* to do something does not dictate that another solution *could* be better. And yes, I say could because I am speaking in the hypothetical case - to date, the data community has not come up with a working example (in the Internet tradition) of showing exactly how (as in these are the written specifications) to incorporate EIDs. HOWEVER, has anyone stopped to think that "we" already have a working example of EIDs. Its called the postal system ;-). And as much as we like to complain about snail-mail, it DOES make a distinction between the address and the end point (ie. the person). And I don't believe they (at least the US) have any plans to change things around so that a person's name is tagged to the destination address. -ken From owner-Big-Internet@munnari.oz.au Mon Apr 19 23:22:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15266; Mon, 19 Apr 1993 23:23:28 +1000 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15245; Mon, 19 Apr 1993 23:22:04 +1000 (from derich@netcom.com) Received: from netcom.netcom.com by ux1.cso.uiuc.edu with SMTP id AA13725 (5.67a8/IDA-1.5 for ); Mon, 19 Apr 1993 08:19:39 -0500 Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA07877; Mon, 19 Apr 93 06:21:49 -0700 Newsgroups: alt.best.of.internet,alt.bbs.internet,info.big-internet,netcom.internet Path: derich From: derich@netcom.com (Scotty*Tissue) Subject: How to buy Internet access? How to set up a Internet site? Message-Id: Followup-To: poster Organization: NETCOM On-line Communication Services (408 241-9760 guest) Date: Mon, 19 Apr 1993 13:21:48 GMT Apparently-To: info-big-internet@ux1.cso.uiuc.edu My dad's law firm would like to obtain Internet access for its own firm, but he would like to know where and how to "buy" Internet access and have the firm's own internet address? Any helpers? Responses to derich@netcom.com or derich@digex.com -- Scott Allen Steinbrink ************************************************ * GO CLEVELAND CAVALIERS!! NBA FINALS '93!!!!!!* NetCom: Derich@netcom.com * GO CLEVELAND INDIANS!!!! WORLD SERIES '93!!!!* Digex: derich@digex.com * GO CLEVELAND BROWNS!!!!! SUPER BOWL '94!!!!!!* ************************************************ From owner-Big-Internet@munnari.oz.au Tue Apr 20 01:31:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20600; Tue, 20 Apr 1993 01:31:36 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20592; Tue, 20 Apr 1993 01:31:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05099; Mon, 19 Apr 93 11:31:00 -0400 Date: Mon, 19 Apr 93 11:31:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304191531.AA05099@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, carlberg@cseic.saic.com Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) Cc: jnc@ginger.lcs.mit.edu to date, the data community has not come up with a working example (in the Internet tradition) of showing exactly how (as in these are the written specifications) to incorporate EIDs. Huh? As a pointed out in my recent message to Dave Crocker, what about the PIP specs? Noel From owner-Big-Internet@munnari.oz.au Tue Apr 20 01:53:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21380; Tue, 20 Apr 1993 01:54:12 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304191554.21380@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21364; Tue, 20 Apr 1993 01:53:51 +1000 (from perk@watson.ibm.com) Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2227; Mon, 19 Apr 93 11:53:45 EDT Date: Mon, 19 Apr 93 11:39:02 EDT From: perk@watson.ibm.com To: big-internet@munnari.oz.au Subject: Transport layer EIDs A small idea from a long-time lurker: What if EIDs, as described by the participants in this discussion, were interpreted only by the transport layer? Doesn't this fit the post-office analogy better than requiring EIDs to be interpreted by network-layer protocols? Differences in service that might need to have different EIDs could also be considered to be provided by different transport mechanisms. The natural conclusion, if the above suggestion has merit, would be to make EIDs into a field of new transport-layer headers. That might be the right place for this piece of the puzzle. Charlie P. From owner-Big-Internet@munnari.oz.au Tue Apr 20 02:00:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21673; Tue, 20 Apr 1993 02:01:17 +1000 (from owner-Big-Internet) Return-Path: Received: from CSEIC.SAIC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21582; Tue, 20 Apr 1993 02:00:00 +1000 (from carlberg@cseic.saic.com) Received: by cseic.saic.com (4.1/1.34) id AA12116; Mon, 19 Apr 93 11:50:48 EDT Date: Mon, 19 Apr 93 11:50:48 EDT From: carlberg@cseic.saic.com (Kenneth Carlberg) Message-Id: <9304191550.AA12116@cseic.saic.com> To: jnc@ginger.lcs.mit.edu Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) Cc: big-Internet@munnari.oz.au, deering@parc.xerox.com From Noel: > to date, the data community has not come up with a working example (in the > Internet tradition) of showing exactly how (as in these are the written > specifications) to incorporate EIDs. > >Huh? As a pointed out in my recent message to Dave Crocker, what about the PIP >specs? I stand corrected. My apologies for having overlooked Paul's work. From Steve: > John Smith > 123 Main St. > Peoria, IL > > ..."John Smith" is *not* an EID -- it is not globally unique! It is much > more analogous to a TCP/UDP port, serving to to demux incoming messages > to a particular consumer once it reaches the destination node (house). > The postal system works without EIDs. Yes. The postal system works without EIDs. But the person-to-person delivery does not. I need a name (an identifier, an end point,...) to distinguish who receives the mail. The name John Smith is not unique because humans can overcome this. If it were necessary to have a unique identifier, then we (in the US) could use a social security number in stead of the individuals name. I don't agree with the TCP/UDP port analogy. I see John Smith *as* the consumer of the mail (the end point) and you see him as a port "serving to demux incomming messages to the particular consumer". -ken From owner-Big-Internet@munnari.oz.au Tue Apr 20 03:37:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25019; Tue, 20 Apr 1993 03:38:24 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24989; Tue, 20 Apr 1993 03:37:08 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Mon, 19 Apr 1993 10:36:28 -0700 Date: Mon, 19 Apr 1993 10:36:28 -0700 From: Tony Li Message-Id: <199304191736.AA07983@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, tli@cisco.com, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Mon, 19 Apr 93 11:01:07 -0400 <9304191501.AA05008@ginger.lcs.mit.edu> Subject: EIDs [BTW, in case it is not apparent, my model of an endpoint is an interface layer just above a BSD socket and just below an operating system thread. Dunno if this coincides with Noel's.] Hmmm, like I said, endpoints are networking concepts and don't map well to operating system concepts. But at some point, this concept needs to have a concrete implementation... While I'm NOT trying to design that implementation, it would very much help this junior engineer ;-) grok the concept if I had an example of an implementation of an endpoint. Likewise, if you have two endpoints, and one EID, you can't differentiate between them based on the EID. (This latter is particularly dangerous, and I'd really want to see an example which couldn't be solved any other way before I'd allow it.) Agreed. Still NOT convinced that EID's belong in the network layer header, I'd like them in the internetwork layer header because addresses are going to get *long* (and variable length), flows are going to happen (for routing, resource and a host of other reasons), and these two together mean we don't want or need addresses in each packet. And we're back to our crystal ball argument... Tony From owner-Big-Internet@munnari.oz.au Tue Apr 20 04:38:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27296; Tue, 20 Apr 1993 04:39:38 +1000 (from owner-Big-Internet) Return-Path: Received: from ibm1.scri.fsu.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27262; Tue, 20 Apr 1993 04:38:20 +1000 (from hays@ibm1.scri.fsu.edu) Received: by ibm1.scri.fsu.edu id AA16103 (5.65c/IDA-1.4.4 for big-Internet@munnari.oz.au); Mon, 19 Apr 1993 14:37:36 -0400 Date: Mon, 19 Apr 1993 14:37:36 -0400 From: Ken Hays Message-Id: <199304191837.AA16103@ibm1.scri.fsu.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: atkinson@itd.nrl.navy.mil, big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9304162140.AA20561@ginger.lcs.mit.edu> Subject: Re: still trying to understand EIDs Reply-To: Ken Hays This is to follow-up on Noels response to Ran Atkinson from last Friday. Noel Chiappa writes: ..omitted text > >-- In your conception do EIDs have to map 1-1 with end systems ? > >Hmm, I'm not sure exactly what you mean by "end system". If you mean host, not >really (since a host might have several mobile processes in it, each with the >own EID). Assuming you mean endpoint, it is explicitly forbidden for more than >one endpoint to have the same EID. I can't see offhand a good reason to >have more than one EID (i.e. endpoint name) per endpoint, but maybe someone >else can? (If you *can* have more than one, it does remove some of the >advantages of having them! :-) > >-- Can an end system have more than one EID ? > >This is the same question as the last one, no? > > >-- Would the presence of EIDs affect how addresses were allocated > or how many addresses a host could have ? > >No and no. I think addresses should be the (topologically) structured names of >network attachment points (i.e. sort of network interfaces), so (since EID's >have no topological content) there would clearly be no tie-in, and a host >could have an many interfaces (each with a different address) as it wanted. ..omitted text > >-- How big would an EID need to be and how would they be structured > and administered (e.g. would this be another thing that network ops > folks would have to look after and maintain) ? > >Again, I talked about this. Something like IEEE numbers are administered, >maybe? If we have 8 byte EID's, we could even embed the whole IEEE space in >it, so you'd get an EID with ever 802.* interface... Please correct me if I am wrong, but I thought the IEEE numbers were being assigned to the interfaces. In a multiple interface system, would an endpoint have the same EID no matter which physical interface the communication flowed over? Would all endpoints on a system have the same EID? [seems that the first block of text included above says no but then the embedding comment gets me to wondering] Or was your point that 8 bytes is big enough to contain all of the IEEE number space ? I will print the Saltzer paper and read it tonight. Thanks, Ken From owner-big-internet@munnari.oz.au Tue Apr 20 08:34:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05019; Tue, 20 Apr 1993 08:35:44 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03100; Mon, 19 Apr 1993 17:57:19 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14257; Mon, 19 Apr 1993 09:56:26 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA01716; Mon, 19 Apr 1993 09:56:20 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9304190756.AA01716@dxcern.cern.ch> Subject: Re: IPng complexity (was Re: IPng political b***s***) To: john@iastate.edu (John Hascall) Date: Mon, 19 Apr 1993 09:56:18 +0200 (MET DST) Cc: tli@cisco.com, dcrocker@mordor.stanford.edu, big-internet@munnari.oz.au In-Reply-To: <9304171334.AA19993@iastate.edu> from "John Hascall" at Apr 17, 93 08:34:52 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1810 I think this is getting out of hand. Any company will tell you that the cost of making a prototype is nothing to do with the cost of making a product. It is inappropriate (PCW*) to base conclusions on how many weekends were needed to code each of the IPng demos. We have a criteria document, why don't we use it some? *PCW = politically correct wording. I mean "dumb". Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 >--------- Text sent by John Hascall follows: > > > [Dave Crocker, Tony Li] > > DC> No technical significance? When two of the participants cite > DC> the ability to deliver full, working versions after very few HOURS > DC> of effort, and a couple more cite small numbers of DAYS, starting from > DC> scratch, I'm afraid that I count that as technically significant. > > TL> The effort that went into the SIP implementation is almost irrelevant. > TL> The sole point is that the development is tractable. But that has > TL> been shown to be the case for all of the demo'ed proposals. > > I couldn't disagree more. The more complex the IPng layer is, the > more likely there are to be botched and/or incompatible implementations > (for goodness sakes, there are IPs which don't even get it quite right, > yet in this day). > > I can just see the headline ``rare bug in toaster takes down the internet''. > ``billions lost in toast damage worldwide'' ;-) > > Remember also that one of the pushes for IPng is the > push to the ``toaster level'' of ubiquity. > > To me, this means the protocol better be darn simple, it takes > long enough for computer people to apply patches to computers, > bugs in toaster software will be forever (I can just imagine my > mother getting a prom in the mail from GE). > > John > From owner-big-internet@munnari.oz.au Tue Apr 20 09:22:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06927; Tue, 20 Apr 1993 09:26:22 +1000 (from owner-big-internet) Return-Path: Received: from pooh.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15601; Mon, 19 Apr 1993 23:31:28 +1000 (from john@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Mon, 19 Apr 93 08:30:58 -0500 Message-Id: <9304191330.AA22474@iastate.edu> To: carlberg@cseic.saic.com (Kenneth Carlberg) Cc: big-Internet@munnari.oz.au Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) In-Reply-To: Your message of Mon, 19 Apr 93 08:11:30 -0400. <9304191211.AA11497@cseic.saic.com> Date: Mon, 19 Apr 93 08:30:57 CDT From: John Hascall carlberg@cseic.saic.com (Kenneth Carlberg) KC> HOWEVER, has anyone stopped to think that "we" already have a working KC> example of EIDs. Its called the postal system ;-). And as much as we KC> like to complain about snail-mail, it DOES make a distinction KC> between the address and the end point (ie. the person). And I don't believe KC> they (at least the US) have any plans to change things around so that a KC> person's name is tagged to the destination address. Seems like an example of the superfluousness of EIDs. I am quite certain that: 245 Durham Center Iowa State Univ Ames, IA 50011 is adequate to reach me (I'd also note that it is geographic based rather than provider ;-) John From owner-big-internet@munnari.oz.au Tue Apr 20 13:56:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18053; Tue, 20 Apr 1993 14:03:49 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20383; Tue, 20 Apr 1993 01:26:08 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11582>; Mon, 19 Apr 1993 08:24:25 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 19 Apr 1993 08:24:17 -0700 To: carlberg@cseic.saic.com (Kenneth Carlberg) Cc: big-Internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) In-Reply-To: Your message of "Mon, 19 Apr 93 05:11:30 PDT." <9304191211.AA11497@cseic.saic.com> Date: Mon, 19 Apr 1993 08:24:08 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Apr19.082417pdt.12171@skylark.parc.xerox.com> > HOWEVER, has anyone stopped to think that "we" already have a working > example of EIDs. Its called the postal system ;-). And as much as we > like to complain about snail-mail, it DOES make a distinction > between the address and the end point (ie. the person). Not quite, Ken. In the following address... John Smith 123 Main St. Peoria, IL ..."John Smith" is *not* an EID -- it is not globally unique! It is much more analogous to a TCP/UDP port, serving to to demux incoming messages to a particular consumer once it reaches the destination node (house). The postal system works without EIDs. Steve ection of points/EIDs. Well, basically I agree. I'm a little put off at the concept of a single name (EID) referring to a number of different objects (endpoints), when that name is *supposed* to be the name of an *individual* object. Noel From owner-big-internet@munnari.oz.au Tue Apr 20 15:29:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21392; Tue, 20 Apr 1993 15:35:43 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23104; Tue, 20 Apr 1993 02:44:33 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11610>; Mon, 19 Apr 1993 09:42:30 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 19 Apr 1993 09:42:21 -0700 To: carlberg@cseic.saic.com (Kenneth Carlberg) Cc: big-Internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) In-Reply-To: Your message of "Mon, 19 Apr 93 08:50:48 PDT." <9304191550.AA12116@cseic.saic.com> Date: Mon, 19 Apr 1993 09:42:15 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Apr19.094221pdt.12171@skylark.parc.xerox.com> > I don't agree with the TCP/UDP port analogy. I see John Smith *as* the > consumer of the mail (the end point) and you see him as a port "serving > to demux incomming messages to the particular consumer". There is *a* John Smith who is the consumer of the mail, but the string "John Smith" on an envelope serves to demux the incoming mail to that person. If two John Smiths live at the same address, they need different strings to unambiguously sort out their mail without examining the content (e.g., "John Smith, Sr." and "John Smith, Jr."). If a John Smith moves to a new address, his "name" is not necessarily portable to that new address -- there might another John Smith already living there. I think the analogy with ports is quite apt. The "name" must be unique within, and only within, the context of a specific postal address. There is even the equivalent of well-known ports, e.g., "Homeowner". By the way, mobility and address changes are handled in the postal system the same way as we propose for SIP: a letter sent to a person's "permanent" or "old" address is redirected to the "temporary" or "new" address by having some entity at or near the permanent/old address stick a new address on the envelope (or put the original letter inside an envelope addressed to the current location) and resubmit it to the delivery system. Steve From owner-big-internet@munnari.oz.au Tue Apr 20 18:09:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27607; Tue, 20 Apr 1993 18:09:52 +1000 (from owner-big-internet) Return-Path: Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18337; Tue, 20 Apr 1993 00:38:53 +1000 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA22795; Mon, 19 Apr 93 10:37:57 -0400 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9304191037.ZM22793@tengwar.itd.nrl.navy.mil> Date: Mon, 19 Apr 1993 10:37:56 -0400 Organization: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: saag-interest@tis.com, big-Internet@munnari.oz.au Subject: I-D on Security Questions for IP:TNG At the Columbus IETF meeting, I was volunteered to write up an Internet Draft on security questions and issues relating to the various IP: The Next Generation proposals. I apologise for the delay in posting this draft. I would like to actively solicit corrections/additions/clarifications for this document. The document is being cross-posted between the SAAG-Interest list and the big-Internet list in an effort to obtain wider review of this draft. I probably won't actually put this draft out for ftp until people have had some chance to comment on the (probably numerous) deficiencies in this version. TRUTH IN ADVERTISING: I've been doing some examination of how ISO NLSP and SP3 might be adapted to secure the SIP/IPv6 proposal using mechanisms very similar to those being discussed for the IPv4 Security Protocol. I think I've been proposal-neutral in this draft, but if you think bias is showing, please tell me about it... Ran atkinson@itd.nrl.navy.mil ----- Network Working Group Randall Atkinson Request for Comments: DRAFT Naval Research Laboratory April 1993 Security Questions for IP: The Next Generation Proposals Status of this Memo This RFC is being distributed to members of the Internet SAAG in order to solicit their corrections and enhancements of this internet-draft. The goal of this memo is to help focus the discussions of the security-related features of each of the proposals for next generation IP. INTRODUCTION There are several existing proposals for a follow-on protocol to replace the current version of IP (IP version 4). These are all somewhat different and it would be nice if the Internet community could find some rational way to evaluate and compare those proposals before any one of them were selected. Craig Partridge and Frank Kastenholz have circulated an Internet Draft that describes some "Criteria for Choosing IP Version 7". [IPv7-ID] Their draft includes some security-related questions but was intended to be a general set of criteria rather than specific to any technical area. Some people believe that it would be helpful to come up with a more specific and detailed list of critera for next generation IP (IP:TNG). This Internet Draft attempts to list such security-related criteria and is being circulated for comment, correction, and enhancement by others who are interested in network security issues. SECURITY PROPERTIES There are several security properties which are desirable in any internetwork or distributed system. Among these properties are integrity, authentication, and confidentiality. It is important that each IP:TNG proposal be able to provide these properties to users who desire to use them. Ideally, such support should not be limited to a single transmission mode (e.g. unicast) but should support all transmission modes (e.g. multicast and broadcast). It should be possible to protect not only the user data being transported, but also the network control information and header information. If this latter kind of information cannot be protected adequately, the kinds of Atkinson [Page 1] Internet Draft April 1993 problems identified by Bellovin [Bellovin89, also see Kent89] and others will continue to plague the Internet. There are several specific questions which are posed in an effort to clarify the security properties provided by each proposal. These questions include: Which security properties are provided in normal operation of the proposal ? Which additional security properties are available to users who desire enhanced security ? Which security properties are normally provided to related critical protocols such as the Domain Name System, ICMP, and routing protocols ? Are there other optional or enhanced security properties that are provided with this proposal ? If so, please describe them. SECURITY MECHANISMS The above properties must be provided by some set of security mechanisms. In order to evaluate the effectiveness and quality of the security provided, it is important to understand which mechanisms have been used and how they fit in with the protocol. To clarify this, the following questions are proposed: What mechanisms are there to provide users with enhanced security in the proposed protocol ? What mechanisms are in place to adequately protect ICMP or its equivalent and what properties are provided by those mechanisms ? What mechanisms are in place to provide authentication and integrity to other critical protocols (e.g. Domain Name System, Routing protocols) ? Are the above mechanisms different for each protocol or is there a common mechanism used with all protocols ? How is an end system or intermediate system uniquely identified (e.g. IPv4 address) ? How are those identifiers administered ? Atkinson [Page 2] Internet Draft April 1993 If any cryptological mechanisms are used, are they algorithm independent ? If any cryptological mechanisms are used, how are keys managed ? How does host mobility affect use of the above mechanisms ? If IP:TNG supports information "flows" across the internetwork, what provisions are made to ensure that any reserved resources are reasonably available to the flows making those reservations ? What are the other security considerations,if any, with this IP:TNG proposal ? IPv4 COMPATIBILITY It is desirable that the IP:TNG security mechanisms not interfere with the IPv4 security mechanisms during the transition period from IPv4. This is important because it is highly unlikely that there will be a "flag day" where all sites convert to exclusive use of the new protocol from IPv4. Ideally it would be possible to provide security over a connection from an IP:TNG host to an IPv4 host in a manner compatible with the IPv4 host and compatible with the backwards compatibility mechanism proposed for the transition period. It is also desirable to reuse mechanisms from IPv4 to IP:TNG where that is practical and does not impair either security or operational utility. How similar are the IP:TNG security mechanisms to the various proposals for the IPv4 Security Protocol (e.g. NIST's SP3, ISO NLSP, swIPe) ? Is the IP:TNG security mechanism compatible with any of the proposed starting points for the IPv4 Security Protocol (if so, which) ? Is the security mechanism used for IPv4-compatibility also compatible with pure IP:TNG systems? Is it possible for a host only capable of using IP:TNG to securely communication with a host only capable of using IPv4 ? If so, how does this work ? SECURITY CONSIDERATIONS Security considerations are discussed throughout this memo. Atkinson [Page 3] Internet Draft April 1993 REFERENCES [Bellovin89] Steve Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, March 1989. [ISO-NLSP] ISO/IEC, ISO OSI Network Layer Security Protocol, ISO DIS 11577, November 1992. [Kent89] Steve Kent, "Comments on 'Security Problems in the TCP/IP Protocol Suite'", ACM Computer Communications Review, Volume 19, Number 3, July 1989. [IPv7-ID] Craig Partridge & Frank Kastenholz, Criteria for Choosing IP Verson 7 (IPv7), Internet Draft (work in progress), 14 December 1992. [SDNS90] Charles Dinkel (ed.), Secure Data Network System (SDNS) Network, Transport, and Message Security Protocols, NIST IR 90-4250, NIST, Gaithersburg, MD. February 1990. [swIPe] ...TBD... Author's Address: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375 Atkinson [Page 4] From owner-big-internet@munnari.oz.au Tue Apr 20 18:05:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27455; Tue, 20 Apr 1993 18:05:51 +1000 (from owner-big-internet) Return-Path: Received: from cheviot.ncl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19738; Tue, 20 Apr 1993 01:13:11 +1000 (from Tim.Dixon@newcastle.ac.uk) Received: from eata.ncl.ac.uk by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Mon, 19 Apr 1993 16:12:49 +0100 Message-Id: Date: Mon, 19 Apr 1993 15:10:18 +0000 To: big-internet@munnari.oz.au From: Tim.Dixon@newcastle.ac.uk X-Sender: ntmd@eata.ncl.ac.uk Subject: Re: "Progres?" et seq I share a number of the concerns expressed by Brian, Dave, Eric et al about the process of converging on an IPng solution, and involving the end-users in the process. Given the amount of acrimony that still simmers under the surface and occasionally wells up on this list, as elsewhere, I'm not surprised that the I* (to use previously-introduced terminology) is putting its faith in anonymous market forces to resolve the issues. However, I think there is a minimum set of decisions that the I* has to make at some stage, or we have to question why such bodies exist. However... Firstly, we have to stop pretending that consumer has much stake in IPng. The paying end-user wants security and performance features which will not be delivered for many years to come, and which will only be delayed by the IPng hiatus. For everyone else (network managers, of course, excluded), IPng is a non-event - it offers no new functionality in the short term: it has an effect similar to the change in a telephone area code. (In any case, the networking community has a long history of regarding the end-user as the regrettable collateral damage of research and development, so users generally have to scream very loudly and in front of Network TV before their voices reach the hallowed halls of Technopolis). Secondly, we have to stop pretending that there is somehow a beneficial real difference between the IPng candidates which will emerge in the marketplace. They are all stateless protocols - mere encodings of information. The differences between them are based on differing views of the way network provision and administration may develop, views whose farsightedness or otherwise will not be obvious until an advanced state of deployment. The production of interworking implementations may be a big shot in the propaganda war, but it offers no proof of correctness or suitability that could not have been achieved with a pencil, an old envelope and a crystal ball. Thirdly, I think we have to recognise that there is a danger that IPng might not solve the primary problem it seeks to solve - address space. If there is significant deployment of different IPng solutions, whose only common means of interworking is IPv4, then we prolong the life of the 32-bit address, not hasten its obsolescence: it becomes the basic unit of interchange for the forseeable future. Clearly, however, the politics militate against a protocol of choice. However, I think it would be within the bounds of acceptability, for the I* to at least come to an official position on: a) What constitutes an IPng address b) A definition of one level of service to be provided by IPng which is functionally equivalent to IPv4 I could then, as an end-user, at least be assured that if I buy a network solution based on the TBD Protocol (Tim's Brain-Damaged Protocol) conforming to those two pronouncements, that simple, stateless, 1:1 network-layer relaying between adjacent protocol boundaries will be sufficient to interconnect me with everyone else in the Internet with the service I currently "enjoy" from IPv4. There will then be a real marketplace in which all those neat additional features which are touted for IPng can be tested: a market in which at least everyone is connected to each other at a basic level. Tim Dixon RARE Project Development Officer PS: If it didn't hurt, a broadening of that specification to encompass the service offered by other significant similar protocols (IPX has been mentioned here more than once) would not go amiss. PPS:There probably also needs to be a statement that the naming system will evolve to support character sets other than ASCII (to try to prevent people writing new interfaces from making assumptions which will be difficult to undo), but surely that would not be contentious? ==================== Standard disclaimer: These are my views, as expressed at the time of writing. This doesn't mean I won't change my mind, especially if someone threatens to agree with me. From owner-big-internet@munnari.oz.au Tue Apr 20 18:00:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27177; Tue, 20 Apr 1993 18:00:56 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19361; Tue, 20 Apr 1993 01:01:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05008; Mon, 19 Apr 93 11:01:07 -0400 Date: Mon, 19 Apr 93 11:01:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304191501.AA05008@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, tli@cisco.com Subject: Re: EIDs Cc: jnc@ginger.lcs.mit.edu You also want to allow an endpoint to use the same EID for multiple TCP connections. One example is improved security for FTP. You would very much like to tie the control and data connections together. Oops, sorry, I was being a tad simplistic when I said "think of an endpoint as one end of a TCP connection", but that was just an ilustrative example, after all! A single endpoint can definitely have multiple TCP connections; that's what the TCP port is used for. The EID is the name for the endpoint, and you'd only need one for the single endpoint. The connection is globally uniquely identified by the combination of source EID/port and destination EID/port. [BTW, in case it is not apparent, my model of an endpoint is an interface layer just above a BSD socket and just below an operating system thread. Dunno if this coincides with Noel's.] Hmmm, like I said, endpoints are networking concepts and don't map well to operating system concepts. To me, an endpoint is just an indivisible end-end entity, and how that maps onto a specific system would vary from system to system. For 98% of all operating systems, and endpoint = a host. You want to allow an endpoint to have more than one EID so that it can masquerade as multiple endpoints. Good point. I've assumed a one-one mapping between endpoint (the object) and EID (the name for the object), but I guess there are in fact circumstances in which it might be useful to relax that, just as there are cases in which we allow one interface (the object) to have more than one address (the name for the object.) Just realize what you are letting yourself in for: if you have one endpoint, and two EID's, you can't tell by inspecting the EID's that they refer to the same endpoint. Likewise, if you have two endpoints, and one EID, you can't differentiate between them based on the EID. (This latter is particularly dangerous, and I'd really want to see an example which couldn't be solved any other way before I'd allow it.) For example, a single process may open multiple transport connections which should be routed differently (say they have different QOS). Since these connections should really be treated as separate flows, you want separate EIDs. I won't pick nits here if an operating system thread can control multiple endpoints. A flow is not identified solely with the source/destination EID pair (except possibly in an interoperatbility mode with unmodified hosts). If each transport connection is associated with one flow, then what you want to do works quite naturally if flows are globally identified (as I claim they should be) by the concatentation of the source EID and a short source-locally-unique flow id. For the exception case (to support unmodified hosts), all connections betweena a host pair would be carried on the same flow. If the host is setting the ToS field, that could be used to further identify flows. If the host is doing some more complex QoS stuff, it will have been modified to support Unified/Nimrod or something, and will have been modified to support flows at the same time, no? It has to if wants any resourtce guarantees, yes? I'm not convinced that EID's should be in any way connected to DNS. You should be able to open a transport connection in the usual way and _learn_ the EID of the remote process. For TCP, it shows up with the SYN. Again, I guess I wasn't clear. This is exactly what I had in mind when I say that I want EID's to be part of the internework and transport layers; i.e. the DNS->(address, EID) translations are just a layer of sugar stuck on top for the humans. The lower layers work just fine with only EID's and addresses, and if you feel like typing them in numerically, so will your applications. In fact, I don't see the point of EID <-> anything translation. Well, exactly. I reckon the only time you'd need them is in case of unusual errors, where all you are left with is the EID. (Also, for an interoperable deployment in IPv4 with existing hosts, but this is not fundamental.) Still NOT convinced that EID's belong in the network layer header, I'd like them in the internetwork layer header because addresses are going to get *long* (and variable length), flows are going to happen (for routing, resource and a host of other reasons), and these two together mean we don't want or need addresses in each packet. Noel From owner-big-internet@munnari.oz.au Tue Apr 20 18:29:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28601; Tue, 20 Apr 1993 18:29:16 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18446; Tue, 20 Apr 1993 00:42:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04945; Mon, 19 Apr 93 10:41:44 -0400 Date: Mon, 19 Apr 93 10:41:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304191441.AA04945@ginger.lcs.mit.edu> To: atkinson@tengwar.itd.nrl.navy.mil, big-Internet@munnari.oz.au Subject: Re: still trying to understand EIDs Cc: jnc@ginger.lcs.mit.edu > First, if I understand things correctly, the network admins are > going to have to keep not only host names and host addresses in the > DNS, but also the EIDs. Ideally, for hosts which have 48-bit IEEE interfaces, the host's address will consist of the network's address (which it can find from the routers), together with the IEEE address. Thus, no configuration of the hosts's address is needed at all. The host has to trust (at least one) router (to give it the right network address), otherwise how does it reliably get off the net, so trusting the router to get the address shouldn't cause any more angst. But the remote end point has to be able to resolve the textual name into an EID and the DNS is how we normally do that. How do you propose to autoconfigure the DNS without creating a larger DNS security problem than we have now ? Well, this is not a problem that can be solved without reference to other parts of the system, like the security/authentication stuff. How we secure the translations depends on what else we have. For instance, if we have a secure/reliable authentication mechanisms (via a secure/reliable public key distribution, or something like that), you can use that as a tool to help secure the translations. Going back to what I said in an earlier message about secure translations, you can secure them in one of two ways: - you can go through a lot of work to make the updating process be secure, and make the enquiry process be unspoofable, which is a fair amount of work, - the content of the translation can be checksummed by the source host, and the resulting checksum proetcted via encryption (with the private key) The second seems easier to me. This is not exactly a complete description, it's true, but then again nobody has a complete design for a secure DNS anyway, no? Also, what about hosts without an IEEE MAC address? These do exist (e.g. most of the Macintoshes in my building). Localtalk Mac's have a dynamic address assignment mechanism for Localtalk addresses, which is how they get their addresses now. Is there a problem with using that? If so, they could always be configured (as would X.25 hosts); I didn't mean to imply you'd *never* have to do configuration, just that you could get rid fo a lot of it. What about hosts with multiple IEEE MAC addresses? How do they pick only one OR how do they deal with multiple EIDs ? ***Tilt***. I was talking about *address* assignment, not *EID* assignment. They aren't the same, right? :-) If a host has multiple IEEE's, it's because it has multiple interfaces, and thus, multiple addresses. (If you were using IEEE's to generate EID's, you just pick one at random, or the lowest, or something.) What about the big increase in the size of this thing if we base it on the IEEE MAC address? Size of what thing? Can you elaborate a little? (Hint: I'm pretty sure I'd want EIDs not to be tied to my MAC address. :-) It clearly has advantages and disadvantages. Whether it's good or not may vary from site to site, so maybe we want to allow both. At least one EID scheme (PIP's) embeds the entire IEEE space in it, to allow that as an easy source of EID's. > Second, I'm sure that I'll have a need to have a single system have > multiple EIDs. The case I'm thinking of in particular is multi-level > secure systems which will probably need an EID per sensitivity level > if someone decides to get serious about security. Yup, that's probably a good instance of a case where you need multiple EID's. > Note that the current practice is to have one IP address per sensitivity > level but both addresses and EIDs would have to be one per level if EIDs > existed. I didn't follow that last part. All the EID's can (and should) be at the same IP address; after all, all the packets are going across the same physical networking interface, no? Nope. If we are serious about security, we want to minimise the traffic analysis threat (NB: "minimise" not "prevent" -- I'm not completely naive :-). To do that, we use multiple IP addresses for the same system. These normally are configured as one IP address per heirarchical sensivity level (e.g. one IP address for Unclassified and a completely different one for Secret). We will want to do the same thing with EIDs, namely one EID for Unclassified and a completely different one for Secret. We do this for cases with one physical interface and also for cases with multiple physical interfaces. It is admittedly a very special case, but it is also a real world issue. Ah, I see. As far as I know, there's no reason not to allow a single interface to have multiple addresses, so this is possible too. (In fact, maybe you want to have multiple EID's/addresses for each security level, to further screw up traffic analysis. I had assumed a strict one-one mapping from EID's to endpoints, but maybe this is not the way to go. Cogitate...) > It seems to me that traffic in a flow will need to have not only the EID > but also the address. ... I cannot figure out why/how I'm confused. Routers will have little blocks of state (not critical state; i.e. you can zap and router and the flow can be routed around it and pick up, just as a connection will currently recover if any in-transit packet is lost, since all the critical state is stored in the hsots on the ends) for each flow, called a "flow block". I'm confused. HOW does the flow "be routed around the [zapped] router" if the address is not also information that we are sending along in the packets ? It's stored in the flow block when the flow was set up, as explained below. I rather like the current feature of dynamic routing where if a router gets zapped, the upstream router immediately finds another route as soon as it concludes a zap happened. I don't want my end points to have to reroute the flow. I must be missing something here. The same is possible here. If the upstream router found another route, it's because it new the next hop was dead. A similar thing can happen here; once the router knew the next hop was dead, it could look for flow blocks with that as the next hop, and reroute them. The complete mechanism varies, depending on whether the entity which set up the flow specified the path of the flow completely (i.e. every router or not). If not, a recursive repair (of the kind used in Nimrod) could fix it. Alternatively, (and in some cases it is unavoidable, if your policy or resource constraints can't be met) the original source host has to get into the act, but we are into routing and flows now, not EID's, OK? I have suggested that each flow be identified (in a globally unique way) by the source EID plus a source-locally-unique short (16 bits?) flow id. (You could use either the source or destination, actually, but it's much less hassle with the source.) The packets would contain the EID and the short local flow-id, and use that to find the flow block. That wouldn't appear to be enough for dynamic rerouting in the presence of a faulty network (e.g. an exocet missle took out a router :-). Again, as stated below, the flow block which was set up at the time the flow was set up contains the ultimate destination address. At the time the flow was set up, the source and destination addresses would have been saved in the flow block. Also, each router would have figured out (through some routing architecture) what the next hop router for that flow was, and stored that too. So, actually, the destination address wouldn't need to be consulted on each packet anyway. So to add EIDs to the scheme, I need to junk all my existing routers ?? We can add EID's in two ways. One, we can define a new packet format (and a new packet format is what most people seem to want to do, but I don't agree). If so, we have to junk all out existing router *software* anyway, right? Two, we keep IPv4, and make the 32-bit things in the IPv4 header EID's, and the Nimrod design thought a fair amount about how to interoperate with unconverted routers. It's ugly, but it can be done. (Most existing high speed routers do something like this already; they don't look up the destination IP address in the routing table for every packet, but cache IP-dest -> (outgoing interface, local network header) pairs. They use the destination IP address as a tag to find the cache entry, just like the EID/flow would be used in the above scheme. It's just invisible at the moment that they do this; I propose we make it fairly explicit.) There's also an interoperability mode that allows existing hosts to operate without any changes, but this is ugly and transient, so I won't go into it. I do hope it is mentioned in the pending I-D, because operational and transitional issues are also important to me. Look, the forthcoming I-D is not a complete *and* general endpoint/EID spec. There is no such thing. endpoint/EID's are a part of an protocol architecture, and can only be completely specified within the context of that architecture. So, there *is* a PIP EID spec, and there will be an IPv4 EID spec (for use with the IPv4 Nimrod deyployment). However, the I-D just talks about what endpoint/EID's are and why we need them and how to use them to solve some common issues, not "this field goes here", which is part of a protocol spec. > Fourth, it would give me warm fuzzy feelings if more detail could be > given in how these mechanisms would all work. Well, flows aren't in PIP, but EID's are. Noel From owner-big-internet@munnari.oz.au Tue Apr 20 19:53:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02837; Tue, 20 Apr 1993 19:54:08 +1000 (from owner-big-internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15411; Tue, 20 Apr 1993 12:54:08 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA16126; Tue, 20 Apr 93 12:53:43 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304200253.AA16126@coombs.anu.edu.au> Subject: Re: EIDs To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 20 Apr 93 12:53:42 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9304191524.AA05051@ginger.lcs.mit.edu>; from "Noel Chiappa" at Apr 19, 93 11:24 am Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Noel Chiappa, Sie wrote: > > Just a point about terminology, you're saying that an "endpoint" can have > multiple EIDs. > > What's wrong with that? A single object can have multiple names, if it seems > useful. I mean, I'm "J. Noel Chiappa" in some circumstances, and "James E. > Tetazoo" (as an alias) in others. Given that an endpoint may have any number of EIDs associated to it, how then do you allocate EID numbers ? Allow each IEEE number a certain range of EIDs ? (48bit IEEE out of a 64bit EID leaves 16bits for both hierarchical allocation plus local spread). Isn't that going to be a little limiting ? Maybe endpoints can be allocated that way and then have EIDs as an offset onto those ? (Or is this what people have been saying all along ?). Darren From owner-Big-Internet@munnari.oz.au Tue Apr 20 23:43:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11850; Tue, 20 Apr 1993 23:43:35 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11833; Tue, 20 Apr 1993 23:43:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09064; Tue, 20 Apr 93 09:43:11 -0400 Date: Tue, 20 Apr 93 09:43:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304201343.AA09064@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: still trying to understand EIDs Cc: jnc@ginger.lcs.mit.edu From: Tony Li But at some point, this concept needs to have a concrete implementation... While I'm NOT trying to design that implementation, it would very much help this junior engineer ;-) grok the concept if I had an example of an implementation of an endpoint. Well, here's an example for you; I have a system in which processes can migrate among a small group of machines, while retaining their existence, and open TCP connections. Each such mobile process would have its own EID. To do this, you *can't* use the address and TCP port to name the connection, since the port number used at the old machine may clash with an already allocated port number at the new machine. (In addition to which, since the host, and most of the processes and open TCP connections, didn't leave the old address, it would be be pretty damned confusing to a machine on the other end if half of the TCP connections on a machine got up and went somewhere else, and the other ones didn't!) However, this does not mean that there's a one-one map from processes to EID; on a normal Unix host, where processes stay on one machine, you only need one EID for the whole machine. From: Ken Hays Please correct me if I am wrong, but I thought the IEEE numbers were being assigned to the interfaces. No, you're right. It's just that since they are a nice source of unique numbers, the temptation is there to use them as a source for EID's as well (and PIP does). However, there are a number of potential problems since they *are* interface names; e.g. what happens if you unplug an 802.? interface from one machine and plug it into another.... In a multiple interface system, would an endpoint have the same EID no matter which physical interface the communication flowed over? Yes! Would all endpoints on a system have the same EID? An EID is just a name for an individual endpoint. If you can see some good reason to have several with the same name, perhaps this could be allowed, but it makes me very uneasy. From: perk@watson.ibm.com What if EIDs, as described by the participants in this discussion, were interpreted only by the transport layer? Well, the thing is that a lot of use want to use them to help solve things like the mobile host problem and the multi-homed host problem, and if they are only visible at the transport layer they wouldn't be very helpful for those goals. The natural conclusion ... would be to make EIDs into a field of new transport-layer headers. That might be the right place for this piece of the puzzle. It seems to me that the right model is that EID's are the top sub-layer of two sub-layers in the internetwork layer. That layer has the responsibilty of providing unreliable end-end datagram service. This allows the issue of the binding from the interface to the endpoint (involved in the problems I listed above) to be handled entirely within one layer. From: avalon@coombs.anu.edu.au (Darren Reed) Given that an endpoint may have any number of EIDs associated to it, how then do you allocate EID numbers? I think it's pretty rare that a single endpoint would need more than one EID. (The whole concept of an endpoint is that it *is* indivisible, so it's not like it's going to split in two and each half needs a distinct name to take away with it.) Given that, I don't think we need an automatic mechanism to allocate multiple EID's to each endpoint. From: John Hascall Seems like an example of the superfluousness of EIDs. I am quite certain that: 245 Durham Center Iowa State Univ Ames, IA 50011 is adequate to reach me (I'd also note that it is geographic based rather than provider ;-) Well, let's not push the real mail analogy too far, huh? It's not an exact match! If you are the only person (endpoint) at that address (interface), yah, you can leave out your name. But suppose someone moves in with you? How would you know which person incoming mail with only that on it was for? It's bad to make analogies to things like road and mail addresses, for the utility of geographic addressess, since real-world topology (e.g. the effective distance from Iowa to Virginia) doesn't change. Network topology changes all the time. From: Steve Deering "John Smith" is *not* an EID -- it is not globally unique! It is much more analogous to a TCP/UDP port, serving to to demux incoming messages to a particular consumer once it reaches the destination node (house). Again, you're pushing the postal analogy too far. A better analogy to ports would be if mail were delivered to "Inhabitant #1, ...", etc. Chances are if you moved your address, there'd be a good chance someone else would have the "inhabitant number" you used to have. If two John Smiths live at the same address, they need different strings to unambiguously sort out their mail without examining the content This is just an artifact of the fact that human string names are not guaranteed to be unique. It is for this precise reason that governments invent alternate naming spaces with guaranteed unique identifiers, e.g. the U.S. Social Security number; it's easier to do that than force human names to be unique. Seems to me you've just made a good analogy to another system that had to invent EID's. Noel From owner-Big-Internet@munnari.oz.au Wed Apr 21 00:16:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13471; Wed, 21 Apr 1993 00:16:16 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13462; Wed, 21 Apr 1993 00:16:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09336; Tue, 20 Apr 93 10:16:01 -0400 Date: Tue, 20 Apr 93 10:16:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304201416.AA09336@ginger.lcs.mit.edu> To: big-Internet@munnari.oz.au, john@iastate.edu Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) Cc: jnc@ginger.lcs.mit.edu Yes, I think we can all see this is what you are suggesting -- the question behind each of these is *why*? Good questions all, but I don't think I can give better answers than those I've previously given to this list. However, here they are again, collected together in crisp form for you. What is the benefit of EIDs? Whether we like it or not, interfaces and communicating entities are different things. If we only have a single name for both things, anytime we need to *distingiush* between the two, we are going to run into trouble if we cannot name them *separately*. Many, many examples have been given of this. What prevents the benefits from being achieved through some other methodology? Nothing *prevents* it. The question is "what is the cleanest and most powerful way to achieve it"? Large systems usually die because the basic architecture has been encrusted with a multitude of minor hacks ("bags on the side") each to do one thing, *instead of* making a well thought out change to the basic structure which can do many things. Why are they at the internetwork layer? [And at the TCP layer too?] They are at the internetworking layer to allow the binding from the interface to the endpoint to be examined or changed in that layer. If you want to pick up a transport layer connection and move it to a different place, invisibly to the transport layer, it has to happen *below* the transport layer, yes? They are at the transport layer because they are the names of the end-end entities which are communicating via that transport layer. Why a separate naming space from network-attachments? The form of a name is dictated by the uses to which it will be put. The names for interfaces (addresses) are structured to be used by the routing; i.e. they have a hierarchical structure which is visible to many of the entities which use the routing. The hierarchy is related to the actual topology of the network. They are not densely allocated (since they are set up to allow growth without renumbering). The names for endpoints (EID's) have different uses and allocation patterns. Without going into a long song and dance about the future structure of the switching fabric, it seems to me almost certain that the uses of EID's will be sufficiently different as to make a separate naming space necessary. If for no other reason, addresses *must* have topological significance, whereas EID's *must not*. I don't think Saltzer is all that enlightening (he basically argues that networks consist of 4 kinds of objects (services, nodes, attachments, and paths), which should each have bindings from "names" to "addresses". I found his arguments quite breief and I don't find any argument that this involves the internetwork layer. Yes, his terminology with "addresses" is a little wierd, and I don't like (or use) it. In that last section, he uses the term "address" to mean the process of mapping from the name of a higher level object to the name of a lower level object, which is just way overloading on the term "address". (In fact, that last section has a number of problems, I reckon; I don't like his analysis of the NCP port names either.) However, this doesn't detract from the value of the paper, which is *not* to provide a detailed design, but rather to make people in networking understand: - the difference between an object and the name of the object, and - that the set of terms (and ideas) "host name", "address", and "route" is insufficient to fully understand networks It is left as an exercise to the reader to apply these general lessons to *any* network architecture, be it TCP/IP, OSI, XNS or whatever. Noel From owner-Big-Internet@munnari.oz.au Wed Apr 21 03:04:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20845; Wed, 21 Apr 1993 03:04:44 +1000 (from owner-Big-Internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20836; Wed, 21 Apr 1993 03:04:29 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14438>; Tue, 20 Apr 1993 13:04:10 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA14562 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Tue, 20 Apr 93 12:50:16 -0400 Received: by dino.alias.com id AA13886 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Tue, 20 Apr 93 12:50:15 -0400 Date: Tue, 20 Apr 1993 12:50:15 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9304201650.AA13886@dino.alias.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: still trying to understand EIDs Cc: mandrews@alias.com, big-internet@munnari.oz.au >However, this does not mean that there's a one-one map from processes to EID; >on a normal Unix host, where processes stay on one machine, you only need one >EID for the whole machine. Okay, now I'm getting confused. I thought EID's are unique. Isn't there a unique EID associated with each TCP connection on the unix host? Doesn't each process on each machine have its own EID? Mark From owner-big-internet@munnari.oz.au Wed Apr 21 03:25:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21959; Wed, 21 Apr 1993 03:25:58 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11536; Tue, 20 Apr 1993 23:34:31 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14432>; Tue, 20 Apr 1993 09:34:13 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA11819 (5.65a/IDA-1.4.2 for atkinson@tengwar.itd.nrl.navy.mil); Tue, 20 Apr 93 09:33:09 -0400 Received: by dino.alias.com id AA10904 (5.65a/IDA-1.4.2 for saag-interest@tis.com); Tue, 20 Apr 93 09:33:09 -0400 Date: Tue, 20 Apr 1993 09:33:09 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9304201333.AA10904@dino.alias.com> To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson), big-Internet@munnari.oz.au, saag-interest@tis.com Subject: Re: I-D on Security Questions for IP:TNG Ran, Good draft! Any idea how widespread security in IPv4 currently is? I am aware of RFC 1108, but don't know if many (or any) have implemented it! I guess the PEM stuff would count here as well. Any notable others? Mark From owner-big-internet@munnari.oz.au Wed Apr 21 03:47:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22895; Wed, 21 Apr 1993 03:47:29 +1000 (from owner-big-internet) Return-Path: Received: from jpmorgan.jpmorgan.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13328; Wed, 21 Apr 1993 00:10:57 +1000 (from bhatiani@jpmorgan.com) Received: by jpmorgan.jpmorgan.com (5.65/fma-120691); id AA17755; Tue, 20 Apr 93 10:10:40 -0400 Received: by tcpg01a.ny.jpmorgan.com (5.65/fma-120691); id AA21201; Tue, 20 Apr 93 10:10:39 -0400 Received: by athena1 id AA11041; Tue, 20 Apr 93 10:08:38 -0400 From: bhatiani@jpmorgan.com Received: by in-the-bits.lsi.ny.jpmorgan.com (4.1/4.7) id AA01822; Tue, 20 Apr 93 10:06:23 EDT Message-Id: <9304201406.AA01822@in-the-bits.lsi.ny.jpmorgan.com> Subject: Re: still trying to understand EIDs To: big-internet@munnari.oz.au Date: Tue, 20 Apr 1993 10:06:22 -0400 (EDT) In-Reply-To: <9304162320.AA18683@hpindlm.cup.hp.com> from "Sunil Chitgopekar" at Apr 16, 93 04:20:18 pm Organization: JPMorgan, New York X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 407 > > > > Feel free to take this offline if you think it > > appropriate... > > Noel, > > Please don't answer the questions offline .. Some of us who started late > would like to get educated too ! > > Regards: > Sunil Chitgopekar > yeah...what he said ------------------------------------------------ Amit Bhatiani bhatiani@jpmorgan.com LAN Systems Integration JPMorgan, NY From owner-big-internet@munnari.oz.au Wed Apr 21 04:14:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23762; Wed, 21 Apr 1993 04:14:29 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15124; Wed, 21 Apr 1993 00:51:04 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14432>; Tue, 20 Apr 1993 10:50:20 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA12759 (5.65a/IDA-1.4.2 for big-Internet@munnari.oz.au); Tue, 20 Apr 93 10:41:18 -0400 Received: by dino.alias.com id AA11826 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Tue, 20 Apr 93 10:41:19 -0400 Date: Tue, 20 Apr 1993 10:41:19 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9304201441.AA11826@dino.alias.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: still trying to understand EIDs Cc: big-Internet@munnari.oz.au (Most existing high speed routers do something like this already; they don't look up the destination IP address in the routing table for every packet, but cache IP-dest -> (outgoing interface, local network header) pairs. They use the destination IP address as a tag to find the cache entry, just like the EID/flow would be used in the above scheme. It's just invisible at the moment that they do this; I propose we make it fairly explicit.) When the router caches `IP-dest -> (outgoing interface, local network header) pairs', does the local network header contain the source and dest EID's? If not, what sort for format would it have? Mark From owner-big-internet@munnari.oz.au Wed Apr 21 04:37:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24783; Wed, 21 Apr 1993 04:37:38 +1000 (from owner-big-internet) Return-Path: Received: from jpmorgan.jpmorgan.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18822; Wed, 21 Apr 1993 02:14:03 +1000 (from bhatiani@jpmorgan.com) Received: by jpmorgan.jpmorgan.com (5.65/fma-120691); id AA20123; Tue, 20 Apr 93 12:13:53 -0400 Received: by tcpg01a.ny.jpmorgan.com (5.65/fma-120691); id AA22063; Tue, 20 Apr 93 12:13:47 -0400 Received: by athena1 id AA11808; Tue, 20 Apr 93 12:11:43 -0400 From: bhatiani@jpmorgan.com Received: by in-the-bits.lsi.ny.jpmorgan.com (4.1/4.7) id AA00337; Tue, 20 Apr 93 12:11:42 EDT Message-Id: <9304201611.AA00337@in-the-bits.lsi.ny.jpmorgan.com> Subject: oh..what a TRIP. To: big-Internet@munnari.oz.au Date: Tue, 20 Apr 1993 12:11:41 -0400 (EDT) Cc: bhatiani@jpmorgan.com, spector@jpmorgan.com, sdegler@jpmorgan.com Organization: JPMorgan, New York X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2829 I hope that all of you will not flame me for posting non-serious matter. I hope you will forgive this attempt at humor and smile a little. Also, since I am a novice, please forgive any misuse of terminology. On to the story... This is the story of TRIP. It was a dark stormy night, circa 1993. The five pretenders to the throne, PIP, SIP, TUBA, Nimrod and IPv7 were sitting at a round table. King IP was holding court in his capital, big-Internet. The atmosphere around the table was tense. There was total silence in the room. The impending death of King IP had lent a strange gloom to the room. The doctors had seen him in his private chambers and had pronounced the verdict, he had very little "time to live". Even the renowned doctor CIDR had only been able to prolong his life by a very short time. All the routers in his kingdom were at hand to pay their last respects to their King. They did not wish to see him go. He had made them the most powerful people in his kingdom. But now they were dying because they had too many EID's to take care of. It was in this background that the King had called all the pretenders to his throne to choose his successor. He had hoped that by doing this in the presence of all the pretenders, he would avoid any in-fighting. The meeting had just started when there came a knock on the door. It startled everyone. No one else was expected and no one else knew about the meeting or the succession. The King motioned the doorman, Hello, to open the door. In the rain stood a small boy. He walked in TRIPping water and stood at the end of the room. The King looked at him and said: What is the meaning of this boy? Are you lost or just bouncing around? The boy looked around and said: My name is TRIP and I am going to be the new King. After a moment of silence, the room erupted into laughter. It was a nervous laughter. The kind of laugh that people have when they are not sure whether to belive you or not. After the laughter had died down, one of the pretenders asked the boy: so Mr. TRIP, what qualifications do you have to be King? I can save the routers of this kingdom by using my especially developed TRanscendental Internet Protocol. This protocol sends LSD packets to all routers in the kingdom. These LSD packets enable the routers to have 64 acres rather than 32 to feed their EIDs. As a matter of fact, I have some LSD packets right here for you. At this point, TRIP handed out LSD packets to everyone in the room. A few minutes later the King and the pretenders emerged from the room shouting: Hail to King TRIP...Hail to King TRIP...Oh what a TRIP. Thus ends the story of TRIP, a boy who conquered the throne of King IP. ------------------------------------------------ Amit Bhatiani bhatiani@jpmorgan.com LAN Systems Integration JPMorgan, NY From owner-big-internet@munnari.oz.au Wed Apr 21 05:34:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26840; Wed, 21 Apr 1993 05:34:21 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25389; Wed, 21 Apr 1993 04:54:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12964; Tue, 20 Apr 93 14:54:38 -0400 Date: Tue, 20 Apr 93 14:54:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304201854.AA12964@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, mandrews@alias.com Subject: Re: still trying to understand EIDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Okay, now I'm getting confused. I thought EID's are unique. Isn't there a unique EID associated with each TCP connection on the unix host? Doesn't each process on each machine have its own EID? Let me try this differently, since I seem to be confusing people. The term "endpoint" seems to have caused some of the problems, since it's very abstract, so let's temporarily forget the terms "endpoint" and "EID", OK? We'll talk in terms of more concrete things everyone is familiar with. The network contains communicating entities, and places where they attached to the network (alias "interfaces" or "network attachment points"). To begin with, for the communicating entities, just think of plain old hosts; e.g. your typical Unix workstation/timesharing machine. So, the network contains "hosts", and places to plug them in, "network attachment points". An "HID" is a name for the *host*. It is unique throughout the Internet, is shortish (4-8 bytes), is of fixed length, is the same wherever the host is plugged into the network, and is used to name that host (*not* the place where it plugs into the network) at the internetwork and transport layers. All transport connections go from one host to another, and the names that the transport layer uses are HIDs, OK? So, now the network has "hosts" as objects, and "HIDs" (as names for the hosts), OK? It also has "network attachment points", and "addresses" (which are names for the network attachment points). If I pick up a host and plug it in somewhere else in the net, it keeps the same HID, even though it is now at a different network attach point, i.e. has a new address. If a host has several interfaces, each interface has a separate address, but the host still has only one HID. So, how is "endpoint" different from "host"? Well, in most cases, it isn't. For your plain, vanilla Unix box, the endpoint *is* the host. It's just that there are certain circumstance (and mobile processes are the best example) where you want to take what looks like a single communicating entity and have half of it pick up and move somewhere else, while the other half doesn't. In these (currently) rare circumstances, the endpoint is not a host, but a more abstract concept; an indivisible end-end communication entity. Just as an HID is a name for a host, an EID is a name for an endpoint. Isn't there a unique EID associated with each TCP connection on the unix host? I think I caused this piece of confusion by saying "think of an endpoint as one end of a TCP connection", but that was already too abstract; what I should have said was "think of an endpoint as a host". What I meant when I said that, more accurately, is "think of an endpoint as the abstract thing which is at one end of a TCP connection". Seems like a small difference? Maybe; it's just that an endpoint is the entire TCP (and everything else that you think of when you currently think "host"), with all it open connections, not just one TCP connection. Doesn't each process on each machine have its own EID? Not if they aren't mobile, they don't need to. If I have a thing which contains bits which can pick of and go off separately, I need individual names for each of the things. If I have a thing which *cannot* be divided into parts which go gallivanting off separately, there's no need to give it multiple names. That's why I keep saying "that question does not have a yes/no answer" when asked "does an EID name a process" or "does an EID name a host". What at EID names is an indivisable end-end communication entity, the endpoint, and in *some* circumstances hosts are endpoints, and in others processes are. When the router caches `IP-dest -> (outgoing interface, local network header) pairs', does the local network header contain the source and dest EID's? If not, what sort for format would it have? The quote you lifted talks about today's routers. (I know for sure both Cisco and Proteon boxes work this way.) The local network header is just the 802.? header or whatever local network header is needed to get the packet to the next place it is going; i.e. the next hop router, or the ultimate destination, as the case may be. EID's have nothing to do with this. In the future, if we have flows (as seems likely, for routing and resource allocation reasons, among others), and the flows are identified by an (EID, locally_unique_flow_id) pair, then the mapping will likely be 'EID/flow-id -> (outgoing interface, local network header)'; i.e. what you get out of the mapping is the same thing as you do today; a plain old level 2 header. Noel From owner-Big-Internet@munnari.oz.au Wed Apr 21 07:01:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29882; Wed, 21 Apr 1993 07:02:00 +1000 (from owner-Big-Internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29869; Wed, 21 Apr 1993 07:01:46 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA01182; Tue, 20 Apr 93 14:01:39 PDT Date: Tue, 20 Apr 93 14:01:39 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9304202101.AA01182@saffron.acc.com> To: mandrews@alias.com Subject: Re: still trying to understand EIDs Cc: big-Internet@munnari.oz.au >> When the router caches `IP-dest -> (outgoing interface, local >> network header) pairs', does the local network header contain the >> source and dest EID's? If not, what sort for format would it have? It contains exactly the information it needs to make the next hop, no more and no less. This generally consists of a pointer to the MAC header or equivalent for the outbound port, its length (which is in some cases variable), and the address of a data structure which describes the port. From owner-Big-Internet@munnari.oz.au Wed Apr 21 07:09:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00189; Wed, 21 Apr 1993 07:09:58 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00180; Wed, 21 Apr 1993 07:09:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15719; Tue, 20 Apr 93 17:08:30 -0400 Date: Tue, 20 Apr 93 17:08:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304202108.AA15719@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, mandrews@alias.com Subject: Re: still trying to understand EIDs Cc: big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > It's just that there are certain circumstance (and mobile processes are > the best example) where you want to take what looks like a single > communicating entity and have half of it pick up and move somewhere else, > while the other half doesn't. In these (currently) rare circumstances, > the endpoint is not a host, but a more abstract concept; an indivisible > end-end communication entity. So, in this case, you would have two EID's; one consisting of all communicating processes on the "original" machine and the other is the EID of the host where the mobile processes have moved to? No, the EID is tied to the mobile process, not any of the physical machines it can run on. You can't use the EID of the new host machine; suppose that host machine already had a TCP connection on a TCP port the mobile process had a connection open on? Each TCP connection will be globally, uniquely identified by the quadruple (source_EID, source_TCP_port, destination_EID, destination_TCP_port). This is pretty much the way things work now, except that you substitute "IP address" for "EID" The current scheme (i.e. with IP addresses) has the problem that when you move your TCP connection to a different place in the network, it wants to have a new IP address, but can't, otherwise it wouldn't look like the same TCP connection, so you wind up with all sorts of kludges (like use of Source Routing, which doesn't always work). This way, when the process moves, TCP (which is really only concerned with providing a reliable end-end stream) doesn't give a hoot; the same would be true of any other end-end protocol, such as VMTP or whatever. They would all use the same mobility mechanism, which is in the top sub-layer of the unreliable end-end datagram layer. (In addition to each mobile process having an EID, I imagine each of the physical machines has an EID as well, to refer to the stuff which can't move, but let's not open that can of worms! :-) Noel From owner-Big-Internet@munnari.oz.au Wed Apr 21 08:51:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04187; Wed, 21 Apr 1993 08:51:27 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04178; Wed, 21 Apr 1993 08:51:17 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA14736; Tue, 20 Apr 93 18:51:02 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA22436; Tue, 20 Apr 93 18:52:27 EDT Message-Id: <9304202252.AA22436@tipper> X-Really-To: gibbs.oit.unc.edu To: bhatiani@jpmorgan.com Cc: big-Internet@munnari.oz.au, spector@jpmorgan.com, sdegler@jpmorgan.com Subject: Re: oh..what a TRIP. In-Reply-To: Your message of "Tue, 20 Apr 93 12:11:41 EDT." <9304201611.AA00337@in-the-bits.lsi.ny.jpmorgan.com> Date: Tue, 20 Apr 93 18:52:27 -0400 From: Simon Spero Will this work on SIMD architecures, or just MDMA? Simon From owner-big-internet@munnari.oz.au Wed Apr 21 11:30:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11614; Wed, 21 Apr 1993 11:31:03 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29199; Wed, 21 Apr 1993 06:41:48 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14436>; Tue, 20 Apr 1993 16:41:38 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA17736 (5.65a/IDA-1.4.2 for big-Internet@munnari.oz.au); Tue, 20 Apr 93 16:38:10 -0400 Received: by dino.alias.com id AA16831 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Tue, 20 Apr 93 16:38:08 -0400 Date: Tue, 20 Apr 1993 16:38:08 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9304202038.AA16831@dino.alias.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: still trying to understand EIDs Cc: big-Internet@munnari.oz.au >So, how is "endpoint" different from "host"? Well, in most cases, it isn't. >For your plain, vanilla Unix box, the endpoint *is* the host. It's just that >there are certain circumstance (and mobile processes are the best example) >where you want to take what looks like a single communicating entity and have >half of it pick up and move somewhere else, while the other half doesn't. >In these (currently) rare circumstances, the endpoint is not a host, but a >more abstract concept; an indivisible end-end communication entity. > >Just as an HID is a name for a host, an EID is a name for an endpoint. So, in this case, you would have two EID's; one consisting of all communicating processes on the "original" machine and the other is the EID of the host where the mobile processes have moved to? Mark From owner-big-internet@munnari.oz.au Wed Apr 21 12:02:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13109; Wed, 21 Apr 1993 12:02:28 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304210202.13109@munnari.oz.au> Received: from hadar.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29448; Wed, 21 Apr 1993 06:49:00 +1000 (from ULLMANN@PROCESS.COM) Date: Tue, 20 Apr 1993 16:44 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Subject: Re: still trying to understand EIDs Hi, In the future, if we have flows (as seems likely, for routing and resource allocation reasons, among others), and the flows are identified by an (EID, locally_unique_flow_id) pair, then the mapping will likely be 'EID/flow-id -> (outgoing interface, local network header)'; i.e. what you get out of the mapping is the same thing as you do today; a plain old level 2 header. Noel Hmm, right. Which is why I try in IPv7 to resist pushing addresses into more and more heirarchy (ala Tony Li) and go the other direction: the IPv4/v7 "address" should become more and more just the EID, used by the transport in identifying the connection (by EID-port-pair) and by the routing layer (to track the endpoints as they wander about, not being tied in the first place to an "interface"). I see moving in that direction as the "way to get there from here"; we have already moved a little bit away from the strict catenet/Berkeley address-is-an-interface model; we need to move farther, even before going to IPv7. In the intermediate state, using (e.g.) RAP for the equivalent of Level 1 routing, a host need have only one "address", and can be moved at will locally. (This can even be done with RAP/IPv4 if the v4 implementations are not overly restrictive; often proxy-arp is used for a poor-man's version of exactly this.) The "ID" part of the IPv7 "EID" still has adminstrative structure even in the final state; and I think it is still valid to be able to do EID->(other information) binding in that state. At that point the EIDs (no longer addresses in any sense) are completely freed from ties to specific interfaces. It will still be some time though before aggregates of EIDs (illicitly using their structure) will not be useful to, and used by, the routing protocol(s). Best Regards, Robert From owner-big-internet@munnari.oz.au Wed Apr 21 12:40:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14880; Wed, 21 Apr 1993 12:41:04 +1000 (from owner-big-internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04555; Wed, 21 Apr 1993 09:00:00 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA29652 (5.65/6.02); Tue, 20 Apr 93 18:59:49 -0400 Date: Tue, 20 Apr 93 18:59:49 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9304202259.AA29652@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: still trying to understand EIDs In-Reply-To: <9304201343.AA09064@ginger.lcs.mit.edu> References: <9304201343.AA09064@ginger.lcs.mit.edu> < Would all endpoints on a system have the same EID? > An EID is just a name for an individual endpoint. If you can see > some good reason to have several with the same name, perhaps this > could be allowed, but it makes me very uneasy. Multicast groups. (Paul, what goes in the EID fields of a PIP multigram?) Now, you could argue that this is really a single endpoint (the group) with a very large fanout, but I think this would make layerists unhappy and seems in any event to be stretching the terminology a bit. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-big-internet@munnari.oz.au Wed Apr 21 14:52:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20344; Wed, 21 Apr 1993 14:52:08 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01385; Wed, 21 Apr 1993 07:39:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15968; Tue, 20 Apr 93 17:39:23 -0400 Date: Tue, 20 Apr 93 17:39:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304202139.AA15968@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, tli@cisco.com Subject: Re: EIDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu if I read the PIP spec, I find out that the source EID is carried in every packet, but that it's sole purpose is "end to end" This is not necessarily bad. If there is some functionality or piece of data that *every* higher layer client will need, it makes sense to move it into the lower layer, *even though it is theoretically not necessary*. This prevents the hassle/expense of reinventing the wheel over and over again, not to mention the chances of doing it wrong, and don't laugh, this does happen. We came across a classic example of this doing the "Host Requirement" spec. A number of TCP-based applications (e.g. FTP, SMTP, etc) have the following pattern: they send some stuff, and expect a reply. If they don't get a reply, it's a bug, and you shouldn't hang forever waiting, but timeout. We had to put a separate timeout in on the reply, in each application, because TCP doesn't do this. TCP will make sure the other end receives what you sent, but doesn't have any way to say "I expect something back". Now, I'm not saying TCP should provide this feature (it would make TCP unneccessarily complex), but it would have been nice if there was some common functionalty somewhere that all the applications could have shared, instead of implementing this (common) function over, and over, and over, and over, etc.. So, the practical half of me (and maybe it's a shock to some people out there that I have one :-) says "so what"? one should be able to deduce a return path for the response (but an address does it well), and one may want to do some authentication filtering -- but I would rather not base my security checks on a field that is merely asserted by the sender! If you expect real security this way, you're in for a big surprise. It's easy to subvert addresses too (through use of the Source Route option, etc). If you want security/authentication, add real security/authentication, not something some lame undergrad can crack without working up a sweat. This is done today with the "address+port" pair, which does pose a problem when the address changes during the course of a connection. Exactly. There are workarounds, e.g. encapsulation, which end up carrying two headers instead of one for the small fraction of packets that belong to "movable connections". The EID approach appears to "sanctify" this workaround. Well, it's clean; plus to which if you believe that flows are going to happen (and I'd *love* to see someone *try* and make the case against that :-), it's much more useful; plus to which, if you believe that addresses are going to get long, it's more efficient. I agree with KRE: rather than defend putting EID's into all packets, I'd like to see someone defend putting addresses into all packets. It might be a better idea to address the real problem, i.e. the context identification in TCP; after all, the transport protocol could probably make some real use of these 64 bits of gratuitous overhead. But this is *exactly* what an EID is (at least if I understand what you mean by "the context identification in TCP")! It identifies a TCP 'object' and its associated 16-bit port space! The more sophisticated your system, the more you want to remove functionalities from the "bottom" layers and place them "near the application". Yes and no. Taken to extremes, this approach would leave us with no layers at all! If there are certain functions which all clients need, then it doesn't make sense to replicate them over, and over, and over again; put them in as a common sub-system (or layer, in protocol terms). It only makes sense not to do so if each client's needs vary enough that there is no reasonable common mechanism. In which case one will probably use a name (DNS or PEM) rather than a binary ID -- because just after "identifying" the party, one will have to get it's attributes. Like digital signature infos, permissions, etc. I don't see why a flat binary ID would be useful here... Dave Crocker made the same argument for using DNS names as endpoint names, but since I want to use endpoint names at the transport layer, but I don't think so. (See the Big-I archives for that discussion.) They are much longer, and would be far harder to introduce, for one. They do have the advantage of being easy to look up, though! PEM keys make a certain amount of sense (you *are* the public key of your public/ private key pair), and I can see a case for using them. However, those are a lot longer than 64 bits, and probably are not organized in any way to make them easy to look up on those rare instances when you need to. Where this sort of thing ("after "identifying" the party, one will have to get it's attributes") is important to servers, we'll probably wind up having protocols where the client sends the DNS name, or something similar, as soon as the connection is open, much like SMTP does now. Noel From owner-Big-Internet@munnari.oz.au Wed Apr 21 15:45:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22517; Wed, 21 Apr 1993 15:45:26 +1000 (from owner-Big-Internet) Return-Path: Received: from radiomail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22511; Wed, 21 Apr 1993 15:45:11 +1000 (from ewilliams@radiomail.net) Received: by radiomail.net; id AA19294; Tue, 20 Apr 93 22:44:52 -0700 Message-Id: <9304210544.AA19294@radiomail.net> Date: Tue, 20 Apr 1993 22:44:51 -0800 GMT From: Eric Williams (via RadioMail) Reply-To: eric@isci.com Subject: EIDs and Appl. Entities To: Big-Internet@munnari.oz.au Cc: jnc@ginger.lcs.mit.edu Can an EID be mapped onto a type of common name for a service provided by an application ent.? Or, is it not tied to a type of service / application service paradigm? Peace, Eric Eric@isci.com via RadioMail - A prime example of Criteria 5.1.5 :-) From owner-Big-Internet@munnari.oz.au Thu Apr 22 01:25:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20552; Thu, 22 Apr 1993 01:25:52 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20547; Thu, 22 Apr 1993 01:25:39 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA19392; Wed, 21 Apr 93 11:21:28 -0400 Date: Wed, 21 Apr 93 11:21:28 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9304211521.AA19392@er.doe.gov> To: big-internet@munnari.oz.au, tli@cisco.com Subject: Re: EIDs Cc: jnc@ginger.lcs.mit.edu It seems to me that having multiple EID's for endpoints defeats the whole purpose. Keeping multiple threads separate as flows between 2 EID's is definitely an issue for security, QOS, multiple users... This should be taken care of by assignment of flow ID's. You definitely need to be able to get EID's from DNS, along with other properties like what services supported, security levels,.... Of course if you know the EID before hand you should be able to find remote system... which requires EID->address translation unfortunately. One operational advantage of EID's perhaps is that there are a lot of applications around which want a DNS name and an IP address to function properly. If the EID format were chosen to match IP then this might simplify the code conversion... as well as allowing us to separate users from their addresses without making it apparent to them. This would make CIDR addresses much more palatable. Dan Hitchcock From owner-Big-Internet@munnari.oz.au Thu Apr 22 01:35:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21057; Thu, 22 Apr 1993 01:35:32 +1000 (from owner-Big-Internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21052; Thu, 22 Apr 1993 01:35:23 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA22521; Wed, 21 Apr 93 11:37:12 -0400 Date: Wed, 21 Apr 93 11:37:12 -0400 Message-Id: <9304211537.AA22521@worldlink.worldlink.com> From: David M. Piscitello To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: EIDs--nick at night!! >Arrghhh! Either I say it all in very detailed and exact language, and we get >Noelgram that nobody reads because it is too long, or I say it short, and I >don't get the message across clearly. I can't win! :-) Noel, the problem lies not with what you say, but that you say it in a mailgram instead of an internet-draft. I'm tired of the bi-monthly reruns on EIDs. I like the ideas, and want to pursue them in the IETF. I'd like to have something tangible--a framework document--and then run a BOF, followed by a WG, etc. Here's my concrete suggestion - type in your typical "in painful detail" description to someone who expresses confusion over EIDs as if you were going to reply by mail - save it in a file - apply the internet-draft boilerplate - post the goddam thing If you can't find the time to apply the boilerplate, or haven't the patience to do so, then mail the flame directly to me, and I'll do it. From owner-Big-Internet@munnari.oz.au Thu Apr 22 02:57:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25289; Thu, 22 Apr 1993 02:57:46 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25279; Thu, 22 Apr 1993 02:57:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22521; Wed, 21 Apr 93 12:57:19 -0400 Date: Wed, 21 Apr 93 12:57:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304211657.AA22521@ginger.lcs.mit.edu> To: dave@mail.bellcore.com, jnc@ginger.lcs.mit.edu Subject: Re: EIDs--nick at night!! Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'd like to have something tangible--a framework document--and then run a BOF, followed by a WG, etc. Here's my concrete suggestion ... If you can't find the time to apply the boilerplate, or haven't the patience to do so, then mail the flame directly to me, and I'll do it. Funny thing, I have most of a document (including the boilerplate :-), which I assembled partially by saving the last 2 weeks of mail. Problem is, it's very abstract, and the last week has taught me this approach to explaining endpoints/EID's doesn't work too well. So I'm redoing it to use concrete examples first.. I'm tired of the bi-monthly reruns on EIDs. Me too, but I don't think the document is going to stop it. Noel From owner-big-internet@munnari.oz.au Thu Apr 22 08:04:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09136; Thu, 22 Apr 1993 08:04:48 +1000 (from owner-big-internet) Return-Path: Received: from world.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12387; Wed, 21 Apr 1993 22:44:51 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA26667; Wed, 21 Apr 1993 08:43:24 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199304211243.AA26667@world.std.com> Subject: Re: EIDs and Appl. Entities To: eric@isci.com Date: Wed, 21 Apr 1993 08:43:23 -0400 (EDT) Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9304210544.AA19294@radiomail.net> from "Eric Williams" at Apr 20, 93 10:44:51 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1752 There seems to be a new thread in discussing EIDs, one which may be useful in judging their usefulness. Eric wonders about the association of EIDs with application services. In a collection of replies, Noel Chiappa referred serveral times to an EID as a process identifier. Sometimes, there might be only one pric cess running in a machine, thus only one EID; other times, more EIDs and more processes in a machine. I wonder if EIDs can better be judged from the perspective of the operating system, more than from the network. Perhaps an EID coud better be described (as I think I heard people starting to do) as a portable, machine-independent, process identifier. Only those PROCESSES that might move among platforms really need EIDs. Using such a definition, we might unify some "network-world" views with the view of a threaded operating system such as MACH or OSF/1-MK. In those systems, a thread is a lightweight process that could run on different processors in a common memory (address?) space. There are other aspects, but I wonder if we really are saying an EID is a globally recognized thread identifier? We might get more mileage by then seeing if the POSIX pthreads function definition might map to the service definition of an "entity" associated with an EID. Would the pthreads programming/service interface be adequate for invoking and controlling the whatever-it-is-with-an-EID? If it is, we might have discovered that an EID is a thread identifier, and the justification for EIDs is the justification for OS threads that can have globally known identifiers. Thread identifiers normally have local significnce only. From the hotel room and the slow Compuserve access to the Internet, Howard Berkowitz PSC International From owner-big-internet@munnari.oz.au Thu Apr 22 12:41:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21560; Thu, 22 Apr 1993 12:41:47 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14330; Wed, 21 Apr 1993 23:27:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19278; Wed, 21 Apr 93 09:27:27 -0400 Date: Wed, 21 Apr 93 09:27:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304211327.AA19278@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: EIDs and Appl. Entities Cc: jnc@ginger.lcs.mit.edu From: Eric Williams Can an EID be mapped onto a type of common name for a service provided by an application ent.? Or, is it not tied to a type of service / application service paradigm? Not directly. You might discover (via use of the appropriate resource location and name lookup protocols) that service S is offered by hostname H, which is operating at the transport/internetwork level endpoint E and address A. However, be careful with the word "mapped". File F might have some of its data in disk block B, but just because file F "maps" into disk block B doesn't mean file F *is* disk block B. In the same way, even though service S "maps" to endpoint E, it isn't the *same thing* as endpoint E. From: hcb@world.std.com (Howard C Berkowitz) In a collection of replies, Noel Chiappa referred serveral times to an EID as a process identifier. Sorry, but that's not what I said. I said that in some circumstances, a mobile process might be an endpoint (and the endpoint will have an EID). Sometimes, there might be only one [process] running in a machine, thus only one EID; other times, more EIDs and more processes in a machine. Again, not what I said. EID's name endpoints, not processes! There might in *some circumstances* be a mapping from endpoints to processes, but it's not universal. Go back to the file example: file F is not diskblock B, the file is not named B, and the diskblock is not named F. I wonder if EIDs can better be judged from the perspective of the operating system, more than from the network. No; "process" is an operating system concept, "endpoint" is a network concept (although, to some people, I concede, networks are a subset of operating systems :-). Perhaps an EID coud better be described ... as a portable, machine-independent, process identifier. ... I wonder if we really are saying an EID is a globally recognized thread identifier? No, because a "process" has a lot of state, etc (such as a stack, a PC, and tons of other environment) which is not at all covered by the concept of "endpoint". Since EID's only name endpoints, they explicitly don't cover all the stuff involved in having a "process" (or "thread"; a thread is really just a stripped down process). Using such a definition, we might unify some "network-world" views with the view of a threaded operating system such as MACH or OSF/1-MK. This is an interesting idea. Probably in the (distant :-) future there will be a Standard for the definition of a "mobile process", so that it can wander from machine to machine in an interoperable way. However, I think it's a ways off yet. First, we have the issue of different processor architectures to deal with (a process can't just stop running on a 68K, move to a 80?86 and keep rolling). Second, much as all modern operating systems look reasonably alike (i.e. like Unix), there are still a lot of differences (as well as those of us who think Unix is a step backwards from where we ought to be). If it is, we might have discovered that an EID is a thread identifier, and the justification for EIDs is the justification for OS threads that can have globally known identifiers. Thread identifiers normally have local significnce only. Again, an interesting idea. We will probably need identifiers for mobile processes, and to the extent that a mobile process is also an endpoint, perhaps we can identify them by the names of their associated endpoints. However, all this has nothing to do with endpoints (which are *defined* as a purely networking concept - an indivisible end/end communication entity), and EID's (which are *defined* as names for endpoints). This is not to say your ideas are bad: just don't snarf other terms to describe them. You may not be sure what an EID is, but I am! Noel From owner-big-internet@munnari.oz.au Thu Apr 22 13:25:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB22988; Thu, 22 Apr 1993 13:25:37 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18833; Thu, 22 Apr 1993 00:51:47 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14446>; Wed, 21 Apr 1993 10:50:05 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA21270 (5.65a/IDA-1.4.2 for big-Internet@munnari.oz.au); Wed, 21 Apr 93 10:39:17 -0400 Received: by dino.alias.com id AA03219 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Wed, 21 Apr 93 10:39:16 -0400 Date: Wed, 21 Apr 1993 10:39:16 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9304211439.AA03219@dino.alias.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: still trying to understand EIDs Cc: big-Internet@munnari.oz.au >No, the EID is tied to the mobile process, not any of the physical machines it >can run on. You can't use the EID of the new host machine; suppose that host >machine already had a TCP connection on a TCP port the mobile process had >a connection open on? Okay, I think I get it now [famous last words :-)]. In an abstract way, the EID (gotta watch my wording here) represents an entity or protocol (there has to be a better word for this) on a machine. The nice thing about them is that once they are set, they don't need to be changed if the host is logically moved. If the host moves, you have to change the IP address, but not the EID. I can see the attractiveness of this idea, especially for mobility! Not to open the can of worms you mentioned, but what about the other transport protocols (i.e.: UDP). Would you have a separate EID for TCP and another for UDP or an EID for the entire machine, then hand the packets off to the correct transport protocol based on the proto field in the internetwork header? Mark From owner-big-internet@munnari.oz.au Thu Apr 22 19:08:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08645; Thu, 22 Apr 1993 19:08:55 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00747; Thu, 22 Apr 1993 05:08:01 +1000 (from @yonge.csri.toronto.edu:chk@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14449>; Wed, 21 Apr 1993 15:07:45 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA26723 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Wed, 21 Apr 93 14:44:18 -0400 Received: by dino.alias.com id AA07166 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Wed, 21 Apr 93 14:44:18 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9304211844.AA07166@dino.alias.com> Subject: Re: EIDs To: jnc@ginger.lcs.mit.edu Date: Wed, 21 Apr 1993 15:44:16 -0400 Cc: big-internet@munnari.oz.au In-Reply-To: <9304202139.AA15968@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 20, 93 05:39:23 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1612 > We came across a classic example of this doing the "Host Requirement" spec. A > number of TCP-based applications (e.g. FTP, SMTP, etc) have the following > pattern: they send some stuff, and expect a reply. If they don't get a reply, > it's a bug, and you shouldn't hang forever waiting, but timeout. Why? What happens if the reply is delayed because a network link went down? I repeatedly use the example of an automated file transfer system I was using that ran across UHF radio links. Due to propogation issues and noise levels, the network link was only up at night; it would go down every morning at sunrise, and return at sunset. I once ran a single FTP session across this link that took over a week to complete. At no time did any network problems cause the transport layer or above to terminate the connection. Another example (which is still theoretical) involves tranfering files through LEO satellites. Said satellites rise and set; they are available for a few hours at a time, and then unavailable for a few hours. This type of temporary, but long term, network outage shoud not affect the transport layer! This "timeout" you speak of should *not* be an automated thing; it should be based solely on user input (i.e. the user should manually terminate the process if it's taking too long). -- C. Harald Koch, Network Manager | University: Like a software house, except the Alias Research Inc. Toronto, ON | software is free, and it's usable, and it chk@alias.com | works, and if it breaks they'll quickly tell chk@gpu.utcc.utoronto.ca | you how to fix it, and ... From owner-big-internet@munnari.oz.au Thu Apr 22 20:36:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12113; Thu, 22 Apr 1993 20:36:10 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02181; Thu, 22 Apr 1993 05:40:16 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA08186; Wed, 21 Apr 93 12:38:11 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA28354 for big-Internet@munnari.oz.au; Wed, 21 Apr 93 15:40:07 -0400 Message-Id: <9304211940.AA28354@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: John Hascall Cc: carlberg@cseic.saic.com (Kenneth Carlberg), big-Internet@munnari.oz.au Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) In-Reply-To: Your message of "Mon, 19 Apr 93 08:30:57 CDT." <9304191330.AA22474@iastate.edu> Date: Wed, 21 Apr 93 15:40:06 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: John Hascall To: carlberg@cseic.saic.com (Kenneth Carlberg) Cc: big-Internet@munnari.oz.au In-Reply-To: Your message of Mon, 19 Apr 93 08:11:30 -0400. <9304191211.AA11497@cseic.saic.com> > >carlberg@cseic.saic.com (Kenneth Carlberg) >KC> HOWEVER, has anyone stopped to think that "we" already have a working >KC> example of EIDs. Its called the postal system ;-). And as much as we >KC> like to complain about snail-mail, it DOES make a distinction >KC> between the address and the end point (ie. the person). And I don't belie ve >KC> they (at least the US) have any plans to change things around so that a >KC> person's name is tagged to the destination address. No. An EID is something like a Social Security Number. It is not an address, which is geography based, or a name which can be ambiguous especially when abbreviated. And yes, SSN's do have a little bit of strucutre because blocks are assigned to offices to give out. >Seems like an example of the superfluousness of EIDs. I am quite certain that : > > 245 Durham Center > Iowa State Univ > Ames, IA 50011 >is adequate to reach me (I'd also note that it is geographic based >rather than provider ;-) >John Donald From owner-big-internet@munnari.oz.au Thu Apr 22 20:47:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12583; Thu, 22 Apr 1993 20:47:18 +1000 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27868; Thu, 22 Apr 1993 15:22:12 +1000 (from mulligan@future.Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA09556; Wed, 21 Apr 93 22:22:01 PDT Received: from future.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA00476; Wed, 21 Apr 93 22:22:08 PDT Received: from localhost by future.Eng.Sun.COM (5.0/SMI-SVR4) id AA01177; Wed, 21 Apr 93 22:21:54 PDT Message-Id: <9304220521.AA01177@future.Eng.Sun.COM> To: Big-Internet@munnari.OZ.AU Subject: article in info-world Date: Wed, 21 Apr 93 22:21:52 PDT From: Geoff Mulligan Content-Length: 2139 Internet group wieghs address options by Cheryl Gerber INFOWORLD - April 12, 1993 (published by Bob Metcalfe) -- REPRINTED WITH PERMISSION -- By the year 2000, the Internet's current technology won't be able to handle any more users, experts say. To address the coming capacity crunch, three proposals are currently on the table at the Internet Engineering Task Force (IETF) to increase the address space for the Internet Protocol. The Simple Internet Protocol (SIP), which seems most likely to be adopted, proposes augmenting the current method used for address space. The SIP solution would provide backward compatibility with existing IP technology, making implementation easier. At the IETF meeting in Columbus, Ohio, earlier this month, Silicon Graphics Inc., Sun Microsystems Inc., TGV Inc., and Beame & Whiteside ltd. deomstrated SIP compatibility with their product lines. Also under consideration are the P Internet Protocol (PIP), which is designed to supplant the current IP structure completely, and TCP and UDP Over Big Addresses (TUBA), which proposes combining existing TCP and International Standards Organization (ISO) standards for larger Open Systems Interconnection-based addresses that would support both TCP/IP and OSI applications. Though many would like to see Internet and ISO standards integrate, it seems more likely the SIP proposal will win out. There is no panic to implement larger address space immediately. "The maximum number of networks we can support is 2 million, and we support 11,000 networks now," said Vinton Cerf, president of The Internet Society, in Reston, Va. However, even when Internet technology is augmented to effectively assign network addresses, another problem must be resolved: routing. "The more information they have to send, the more the routing protocols are under stress," Cerf said. Cerf and others hope to minimize routing movement by compressing it. "We also need to increase knowledge for routers to distinguish the types of traffic they hadling and to develop and deploy broader band-switching technology to support real-time network applications," Cerf said. From owner-big-internet@munnari.oz.au Thu Apr 22 21:37:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14442; Thu, 22 Apr 1993 21:37:25 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08148; Thu, 22 Apr 1993 07:47:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24126; Wed, 21 Apr 93 17:46:53 -0400 Date: Wed, 21 Apr 93 17:46:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304212146.AA24126@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, mandrews@alias.com Subject: Re: still trying to understand EIDs Cc: big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In an abstract way, the EID (gotta watch my wording here) represents an entity or protocol (there has to be a better word for this) on a machine. Yeah, I think you are starting to get it. An EID names an abstract entity, an "endpoint" (that's what the 'E' is for :-), which basically has, *as far as the network is concerned*, all the attributes a normal host has, *except* that it is not tied to a physical box. The nice thing about them is that once they are set, they don't need to be changed if the host is logically moved. If the host moves, you have to change the IP address, but not the EID. I can see the attractiveness of this idea, especially for mobility! Well, not everyone agrees that it is attractive, but yes. :-) what about the other transport protocols (i.e.: UDP). Would you have a separate EID for TCP and another for UDP or an EID for the entire machine, then hand the packets off to the correct transport protocol based on the proto field in the internetwork header? The latter; one EID to name *all* the network stuff in an endpoint, including the IP layer itself, ICMP, UDP, TCP, the lot. For the average host, where the endpoint includes the entire machine, one EID would name the whole host. Another way to look at it is that, when you get to the host, an EID does just about the same things an IP address does now. It's just that the EID doesn't say *where* in the network the thing is, and the routers do not construct routes based directly on it. Noel From owner-big-internet@munnari.oz.au Thu Apr 22 21:53:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB15098; Thu, 22 Apr 1993 21:53:16 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08608; Thu, 22 Apr 1993 07:56:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24183; Wed, 21 Apr 93 17:55:52 -0400 Date: Wed, 21 Apr 93 17:55:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304212155.AA24183@ginger.lcs.mit.edu> To: chk@alias.com, jnc@ginger.lcs.mit.edu Subject: Application timeouts Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Why? What happens if the reply is delayed because a network link went down? ... This "timeout" you speak of should *not* be an automated thing; it should be based solely on user input (i.e. the user should manually terminate the process if it's taking too long). This has nothing to do with EID's, but anyway: There are two sides to this. One side says "all timeout/give_up decisions should be up to the ultimate client, be it a human, or an automaton like a shadow directory maintainer or a mail daemon; it's up to them if they want to give up or keep trying". The other says "you ought to have a timer in there so that naive users or badly written automaton applications don't just sit there forever; they have to have retry capability anyway, in case the connection does go down". I think both sides have a point, and I don't subscribe to a position which is hard on one end or the other. Things like mail daemons *do* want to time out and go on to the next piece of mail, requeuing the one which failed, if an SMTP command does not get a reply within a reasonable time, and as things stand, all similar TCP clients have to build the own application timeouts in. On the other hand, if some human wants to sit at a terminal and wait, let them. Noel From owner-big-internet@munnari.oz.au Fri Apr 23 04:33:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02564; Fri, 23 Apr 1993 04:34:03 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19412; Thu, 22 Apr 1993 23:50:21 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14450>; Thu, 22 Apr 1993 09:49:57 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA19138 (5.65a/IDA-1.4.2 for hitchcoc@oerv01.er.doe.gov); Thu, 22 Apr 93 09:16:21 -0400 Received: by dino.alias.com id AA01101 (5.65a/IDA-1.4.2 for hitchcoc@oerv01.er.doe.gov); Thu, 22 Apr 93 09:16:18 -0400 Date: Thu, 22 Apr 1993 09:16:18 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9304221316.AA01101@dino.alias.com> To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: big-internet@munnari.oz.au Subject: Re: EIDs >It seems to me that having multiple EID's for endpoints defeats the >whole purpose. Keeping multiple threads separate as flows between 2 >EID's is definitely an issue for security, QOS, multiple users... This >should be taken care of by assignment of flow ID's. > >You definitely need to be able to get EID's from DNS, along with other >properties like what services supported, security levels,.... Of course >if you know the EID before hand you should be able to find remote >system... which requires EID->address translation unfortunately. Assuming that the DNS hands out EIDs when queried with a hostname, what about the cases when a hostname is a CNAME for another host OR when a site has two names (i.e.: ftp.a.edu and h.a.edu)? In the case of the CNAME, I would suspect the DNS would deem the two names as equivalent and answer a query for each with the same EID. In the second case, I don't know! I can see the possibility that each has their separate EID, both of which "point" to the same host. Mark From owner-big-internet@munnari.oz.au Fri Apr 23 04:45:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03270; Fri, 23 Apr 1993 04:45:27 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23785; Fri, 23 Apr 1993 01:20:05 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11573>; Thu, 22 Apr 1993 08:19:40 PDT Received: by redwing.parc.xerox.com id <57154>; Thu, 22 Apr 1993 08:19:28 -0700 Date: Thu, 22 Apr 1993 08:19:17 PDT Sender: Lixia Zhang From: Lixia Zhang To: dee@skidrow.ljo.dec.com, big-Internet@munnari.oz.au Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) In-Reply-To: Your message of Wed, 21 Apr 1993 12:40:06 -0700 Message-Id: > No. An EID is something like a Social Security Number. It is not an > address, which is geography based, or a name which can be ambiguous > especially when abbreviated. And yes, SSN's do have a little bit of > strucutre because blocks are assigned to offices to give out. I'm afraid that the EIDs will require a sufficient (much more than just "a little bit") strucutre to make efficient search in realtime possible. Where you are now has no relation whatsoever with where you got your SSN. IRS can find your record by a flat space search. For host EIDs, (my naive thinking says) - the EID space would be at least a few orders of magnitude larger than SSN space. - the info in EID database would be at least a few orders of magnitude more dynamic than info in SSN databse. - a centralized EID database will not do the job, has to be highly distributed. - thus an EID must contain adequate information/hint about where to obtain info for this EID within the next few msec or sec. Lixia From owner-Big-Internet@munnari.oz.au Fri Apr 23 06:01:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06367; Fri, 23 Apr 1993 06:01:44 +1000 (from owner-Big-Internet) Return-Path: Received: from pooh.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06359; Fri, 23 Apr 1993 06:01:35 +1000 (from john@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Thu, 22 Apr 93 15:01:28 -0500 Date: Thu, 22 Apr 93 15:01:28 -0500 From: john@iastate.edu Message-Id: <9304222001.AA27795@iastate.edu> To: big-internet@munnari.oz.au Subject: A compromise scheme for IPng address length In Bill Simpson's Internet Draft, _Administrative Allocation of the 64-bit Number Space_ (hereafter the AA64NS ID), a scheme of address prefixes for various countries is developed using population and population growth as criteria. The prefixes range from 6 bits (India and China) to 24 bits (Vatican City, The Falklands, Pitcairn Island). This leaves from 56 to 40 bits to be divided among the population of these areas. While this is certainly adequate to provide a large number of IPng addresses to each person, there may be significant benefits to a large address space. Two such benefits could be (I am avoiding the EID debate here...): * using 48 bit MAC address as the low-order bits for easy configuration (call this an interface id or IID) * using the low-order 48 bits as an EID It would seem that both of these could be used simultaneously by restricting an EID to having what would be the multicast-bit in a MAC address set (presumably 2^47 [1.4e14] EIDs are enough). The scheme below uses the prefixes established in the AA64NS ID in a 96 bit address scheme. The addresses look like this: +---------------------/----------------------+------------------+ | country prefix part \ "local" network part | EID and/or IID | +---------------------/----------------------+------------------+ <-- 6 to 24 bits --> <-- 24 to 42 bits --> <--- 48 bits ----> For example, in the United States (a 7 bit prefix) a possible arrangement might be: +---------+-------------------------------------------+-----+ | USA <7> | local part <41> (see below) | xID | +---------+-------------------------------------------+-----+ / / / / / / +-+------------------------+----------------+ |0| network <24> | subnet <16> | 2^24 of "class A" +-+------------------------+----------------+ +--+-------------------------------+--------+ |10| network <31> | sn <8> | 2^31 of "class B" +--+-------------------------------+--------+ +---+--------------------------------------++ |110| network <38> || 2^38 of "class C" +---+--------------------------------------++ Now, clearly you would not want 2^38 + 2^31 + 2^24 [2.8e11] routes at the US backbone! You would want to use a CIDR-like scheme to aggregate large chunks together for example, "Large Provider Inc" might get a chunk of class C like: +---+--------------------------------------++ |110|11111111111110|network <24> || 2^24 of "class C" +---+--------------------------------------++ which they would route to their customers as they saw fit. Of course, they could also get chunks of other classes to provide services to larger customers. Another possible option would be to have a second variable prefix after the country prefix. Perhaps a provider, or a state or regional network. For example: +---------+-------/-----------------------------------+-----+ | USA <7> | state \ local part | xID | +---------+-------/-----------------------------------+-----+ For example: 000. .... CA 1000 0... GA 1010 00.. IN 0010 .... NY 1000 1... NC 1010 01.. MA 0011 .... TX 1001 0... NJ 1010 10.. MD 0100 .... FL 1001 1... WA 1010 11.. MN 0101 .... IL 1011 00.. MO 0110 .... PA 1011 01.. TN 0111 0... OH 1011 10.. WA 0111 1... MI 1011 11.. WI 1100 000. \ 1110 000. \ : > 16 small states : > 14 small states 1101 111. / 1111 110. / (plus D.C) 1111 1110 \ territories, etc. 1111 1111 / For example, if the USA decided upon using states as the second level, then Iowa might decide upon: +---------+--------+----------------------------------+-----+ | USA <7> | IA <7> | local part <34> (see below) | xID | +---------+--------+----------------------------------+-----+ / / / / / / +-+--------------+----------------+ |0| network <17> | subnet <16> | 2^17 of "class A" +-+--------------+----------------+ +--+---------------------+--------+ |10| network <24> | sn <8> | 2^24 of "class B" +--+---------------------+--------+ +---+----------------------------++ |110| network <31> || 2^31 of "class C" +---+----------------------------++ Vatican City (24 bit prefix) might decide upon: +-------------------+--------------+------------------+-----+ | Vatican City <24> | provider <6> | local part <18> | xID | +-------------------+--------------+------------------+-----+ under the assumption that 64 providers is plenty and they are free to subdivide their 2^18 [256K] networks among their customers as they see fit. Perhaps one of the providers might choose: +-+---------------------+--------------+ |0| network <9> | subnet <8> | 2^9 of "class B" +-+---------------------+--------------+ +--+----------------------+------------+ |10| network <10> | subnet <6> | 2^10 of "class B-" +--+----------------------+------------+ +---+-------------------------+--------+ |110| network <11> | sn <4> | 2^11 of "class C+" +---+-------------------------+--------+ +---+---------------------------------++ |111| network <15> || 2^15 of "class C" +---+---------------------------------++ Of course, each country and/or state/province and/or provider would be perfectly free to sub-divide as it saw fit. Also when I use terms like "class B" this is rather loose. This means you have 2^8 subnets (like the most popular class B subnetting scheme), but since the "host part" is a 48-bit unique ID (xID) there can be more or less than 256 (254) hosts on these subnets. John Hascall Iowa State U From owner-big-internet@munnari.oz.au Fri Apr 23 08:35:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB12144; Fri, 23 Apr 1993 08:35:15 +1000 (from owner-big-internet) Return-Path: Received: from radiomail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08100; Fri, 23 Apr 1993 06:43:43 +1000 (from ewilliams@radiomail.net) Received: by radiomail.net; id AA19231; Thu, 22 Apr 93 13:43:15 -0700 Message-Id: <9304222043.AA19231@radiomail.net> Date: Thu, 22 Apr 1993 13:43:13 -0800 GMT From: Eric Williams (via RadioMail) Reply-To: eric@isci.com Subject: EIDs and mobile IPC To: jnc@ginger.lcs.mit.edu Cc: Big-Internet@munnari.oz.au Noel, How would the following scenario breakdown: A mobile process with EID x wants to do IPC with a remote process on a host with the same EID x (ie. the system the remote process was started from) Would a seperate EID y have to be used for the IPC between the mobile process and the host system (EID x)? Eric Eric Williams - Integrated Systems & Communications, Inc. ewilliams@ radiomail.net or isci.com ISC, Inc. - "Delivering GOSIP/OSI Now!" From owner-Big-Internet@munnari.oz.au Fri Apr 23 11:35:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20572; Fri, 23 Apr 1993 11:36:56 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA20527; Fri, 23 Apr 1993 11:35:15 +1000 (from tcs@ccci.com) Received: from toaster (via toaster.CCCI.COM) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AB20925; Thu, 22 Apr 93 21:08:23 -0400 Received: by toaster (4.1/SMI-4.1) id AA00205; Thu, 22 Apr 93 19:57:54 EDT Date: Thu, 22 Apr 93 19:57:54 EDT From: tcs@ccci.com (Terry Slattery) Message-Id: <9304222357.AA00205@toaster> To: mulligan@future.Eng.Sun.COM Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Geoff Mulligan's message of Wed, 21 Apr 93 22:21:52 PDT <9304220521.AA01177@future.Eng.Sun.COM> Subject: article in info-world Geoff, When did you start working for Sun? The last I heard, you were working for Dec. How are things going for you there? -tcs ibuted. - thus an EID must contain adequate information/hint about where to obtain info for this EID within the next few msec or sec. I agree with the first three points, but I'm wondering about the fourth. I would think that the speed needed for EID lookups would be related to how often and how integral to normal operation those lookups are. I.e. if you do them all the time, in the normal course of things, it would need to be fast, but if you only do them in rare circumstances (like on some error conditions) it could be slower. My model is that you wouldn't often (except in a transitional mode for reinterpreting the 32-bit files in IPv4 headers as EID's) be looking up EID's to translate them into something else; you'd do the DNS name -> (EID, address) tuple translation once, and then pass them around together to everyone who needs them. If you wanted to change the binding from EID to address (e.g. for a mobile host) you'd use an explicit transaction (e.g. ICMP) to do so. So, what model for the use of EID's do you have where you need to look them up a lot, and quickly? I need to know this before I know if I agree with your fourth point. Noel From owner-big-internet@munnari.oz.au Fri Apr 23 13:04:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24960; Fri, 23 Apr 1993 13:04:59 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02298; Fri, 23 Apr 1993 04:28:09 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA11077; Thu, 22 Apr 93 11:28:01 -0700 Message-Id: <9304221828.AA11077@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: SAP RFA Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Thu, 22 Apr 93 11:28:01 -0700 From: Dave Crocker X-Mts: smtp While the recent discussion about EID has, as always, been generally interesting, some thoughts in the thread over the last 2 days, culminating with the synthesis in Howard Berkowitz's note, prompts me to see what is potentially a very large opportunity with respect to the new hat I now wear, as area director for the Service Applications (sap) area. As a new area, Service Applications is still going through definition. However, I am currently characterizing it as covering the set of services which make the world a friendlier place for writing distributed applications. The simplest language for this is that we need to define a coherent set of services which combine to provide a distributed operating system interface. This permits resources, underneath an application, to be distributed, and also makes it easier for the application itself to be distributed (and mobile!). In the extreme, this will allow applications to see the entire Internet as one, big distributed o/s. I am beginning to suspect that some part of the IPng discussion is attempting to pursue a similar goal, but by puting whatever new functionality is required into the Internet layer. Discussing EIDs as referring to machines, rather than interfaces, leads one to look at the lower layers. Discussing them in terms of (possibly mobile) processes makes it plausible to view them as a value-added feature in the upper layers. This message is a Request for Architecture (RFA) discussion and proposals, about the placement of distributed o/s constructs ABOVE the transport layer, to provide a common infrastructure for those applications that need it, but to allow simpler applications to retain the simpler services that are currently available. One aspect of the debate over EID's has to do with cost. One aspect of the concern for cost is whether ALL Internet uses should incur a cost which possibly is needed for only a subset. I believe that discussion of distruted o/s features can allow us to distinguish the services that are needed for these advanced, integrated applications, as distinct from the services needed by the simpler, more 'network-oriented' applications. This request is highly expoloratory. I am characterizing it as an RFA, much like some agencies issues RFP or RFT (technology) solicitations. EIDs have served as the trigger to this query, but they are not the focus. I am hoping that it will cause some folks to think in terms of architectural enhancement by means of incremental facilities, rather than by imposing additional mechanisms on all consumers of the underlying service. This may turn out to be a controversial view. At this point, I think that's fine. I'm trying to see whether there is interest in exploring it. Dave From owner-Big-Internet@munnari.oz.au Fri Apr 23 16:39:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03882; Fri, 23 Apr 1993 16:39:44 +1000 (from owner-Big-Internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03866; Fri, 23 Apr 1993 16:39:26 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05113; Fri, 23 Apr 1993 08:39:01 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA12588; Fri, 23 Apr 1993 08:39:00 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9304230639.AA12588@dxcern.cern.ch> Subject: Re: A compromise scheme for IPng address length To: john@iastate.edu Date: Fri, 23 Apr 1993 08:39:00 +0200 (MET DST) Cc: big-internet@munnari.oz.au In-Reply-To: <9304222001.AA27795@iastate.edu> from "john@iastate.edu" at Apr 22, 93 03:01:28 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 454 Well, I'm going to be blunt, I don't see what this gives me that I haven't got in RFC 1237 and RFC 1347, except rather less address space and flexibility. (Dons flameproof suit, fails to leave forwarding address.) Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of | | PIP, SIP, IPv7, Nimrod, TUBA or anything. | From owner-big-internet@munnari.oz.au Sat Apr 24 00:22:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23869; Sat, 24 Apr 1993 00:22:37 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20432; Fri, 23 Apr 1993 23:20:09 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14410>; Fri, 23 Apr 1993 09:19:43 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA20967 (5.65a/IDA-1.4.2 for eric@isci.com); Fri, 23 Apr 93 09:09:10 -0400 Received: by dino.alias.com id AA18083 (5.65a/IDA-1.4.2 for eric@isci.com); Fri, 23 Apr 93 09:09:08 -0400 Date: Fri, 23 Apr 1993 09:09:08 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9304231309.AA18083@dino.alias.com> To: eric@isci.com Cc: big-internet@munnari.oz.au Subject: Re: EIDs and mobile IPC >A mobile process with EID x wants to do IPC with a remote process on a host >with the same EID x (ie. the system the remote process was started from) They should never have the same EID. The mobile process should have its own EID and all resident processes on the host in question would have the same EID. >Would a seperate EID y have to be used for the IPC between the mobile process >and the host system (EID x)? Yes Mark From owner-Big-Internet@munnari.oz.au Sat Apr 24 01:07:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB26453; Sat, 24 Apr 1993 01:07:21 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26430; Sat, 24 Apr 1993 01:07:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06838; Fri, 23 Apr 93 11:06:58 -0400 Date: Fri, 23 Apr 93 11:06:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304231506.AA06838@ginger.lcs.mit.edu> To: hitchcoc@oerv01.er.doe.gov, mandrews@alias.com Subject: Re: EIDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Assuming that the DNS hands out EIDs when queried with a hostname, what about the cases when a hostname is a CNAME for another host OR when a site has two names (i.e.: ftp.a.edu and h.a.edu)? ... In the second case, I don't know! I can see the possibility that each has their separate EID, both of which "point" to the same host. Having one EID might be advantageous, in that it allows you to discover that the two DNS names refer to the same entity. What would be the utility of having two EID's for the same host? I can imagine a number of reasons (aliases are a time-honoured tradition in more than just computers :-). So, I don't think there is a "yes" or "no" answer, it would depend on the circumstances, and *why* you wanted two names (either DNS or EID) for the same host; you might have a good reason. Noel From owner-big-internet@munnari.oz.au Sat Apr 24 04:30:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08284; Sat, 24 Apr 1993 04:30:33 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24591; Sat, 24 Apr 1993 00:39:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06492; Fri, 23 Apr 93 10:38:40 -0400 Date: Fri, 23 Apr 93 10:38:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304231438.AA06492@ginger.lcs.mit.edu> To: Garrett.Wollman@uvm.edu, jnc@ginger.lcs.mit.edu Subject: Multicast EID's? Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > An EID is just a name for an individual endpoint. If you can see > some good reason to have several with the same name, perhaps this > could be allowed, but it makes me very uneasy. Multicast groups. ... Now, you could argue that this is really a single endpoint (the group) with a very large fanout.. A number of people have suggested this, but I don't think so. Remember, EID's name "endpoints", and the whole concept of an endpoint is that it is the entity of end-end communication (i.e. a thing which can have TCP, etc connections opened to it). I'm a little confused as to exactly what an end-end reliable channel is in the context of a multicast group. If I send out some data, and most of the group members get it and ack it, but some have crashed and did not, did the group "get the data" or not? If you define the group to consist only of those people who got the data, that fixes that problem, but I suspect there are other similar issues out there. Also, an endpoint is an end-end "fatesharing" region; i.e. it is a line drawn around a bunch of stuff that is either all up or all down. (If you will recall, "fatesharing" is *the* key architectural principle of TCP/IP; all the critical state for the communication channel is co-located with the application using the channel, so it's either all there or all gone.) For example, if you have several distinct things which are trying to emulate an endpoint (for example, a group of systems which load-share to provide a service), it would only be appropriate to claim the group was a (presumably mulit-cast) endpoint if they all had exact copies of all the critical state for each instance of the service; i.e. if one blew up with no warning, another could take over without the far end noticing. I know it's attractive to think of a multi-cast group as just like a single host, and treat them that way, but a collection of indenpendant things is going to have behaviour modes, and be able to do things, that a single thing cannot, and you can't sweep that under the rug, you have to deal with it explicitly. I have said this all poorly; let me finish the I-D and I'll try and make it clearer. Noel From owner-big-internet@munnari.oz.au Sat Apr 24 05:28:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10687; Sat, 24 Apr 1993 05:28:52 +1000 (from owner-big-internet) Return-Path: Received: from uu5.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06856; Sat, 24 Apr 1993 03:46:08 +1000 (from eric@isci.com) Received: from port8.reston.pub-ip.psi.net by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AB19890 for Big-Internet@munnari.oz.au; Fri, 23 Apr 93 13:44:54 -0400 Message-Id: <9304231744.AB19890@uu5.psi.com> Received: from isc1.isci.com by isc1.isci.com id <8124-0@isc1.isci.com>; Fri, 23 Apr 1993 13:36:24 +0000 From: "Eric D. Williams" Subject: Re: EIDs and mobile IPC To: Mark Andrews Cc: Big-Internet Date: Fri, 23 Apr 93 13:36:16 EDT In-Reply-To: Your message of Fri, 23 Apr 1993 09:09:08 -0400.<9304231309.AA18083@dino.alias.com> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 36 TEXT , 4 TEXT >>A mobile process with EID x wants to do IPC with a remote process on a host >>with the same EID x (ie. the system the remote process was started from) > >They should never have the same EID. The mobile process should have its >own EID and all resident processes on the host in question would have the >same EID. I get it %-) There is not a one-one relationship between a process and its EID but when a process "becomes mobile" it gets a new EID, all its own (I think this is cool but...)! Where does the mobile endpoint get its EID from? Is this a case for some type of automatic mechanism for the allocation of EIDs to mobile endpoints? >>Would a seperate EID y have to be used for the IPC between the mobile process >>and the host system (EID x)? > >Yes > I see this now, I thought the endpoints would be distinguished by the EID->Address pair for flow between the mobile process (endpoint) and the remote process (endpoint). As in a distributed computing enviroment, where a process may be distributed across endpoints. I would think then a "foreign" endpoint would see the "distributed process" as one endpoint (service). I really don't think this is the paradigm intended by the EID but, I hope a "layer" of services can eventually be provided by an EID which accesses a plethora of other EIDs/endpoints (this is invisible to the user of course) and provides access to processing services distributed across all the EIDs involved. (I think I said that right, I am at a loss for words :-) maybe someone out there can see what I am saying). Peace, Eric Eric D. Williams Integrated Systems and Communications, Inc. ISC 1899 L Street N.W. Suite 500 - Washington, DC 20036-3884 - Voice +1(202)331-3990 ewilliams@isci.com or guru@isci.com - Fax +1(202)331-4049 or +1(202)872-0896 "Delivering Integrated Solutions Now" From owner-big-internet@munnari.oz.au Sat Apr 24 05:32:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10863; Sat, 24 Apr 1993 05:32:54 +1000 (from owner-big-internet) Return-Path: Received: from world.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28016; Sat, 24 Apr 1993 01:27:27 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA12175; Fri, 23 Apr 1993 11:27:19 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199304231527.AA12175@world.std.com> Subject: The Thread Thread (and EIDs) To: big-internet@munnari.oz.au Date: Fri, 23 Apr 1993 11:27:18 -0400 (EDT) Cc: hcb@world.std.com (Howard C Berkowitz), dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu, tli@cisco.com, chk@alias.com, mandrews@alias.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6406 My refined comments after consideration of observations including those of Noel Chiappa, Mark Andrews, Dave Crocker, C. Harald Koch, and Tony Li. NC>No; "process" is an operating system concept, "endpoint" is a network NC> concept (although, to some people, I concede, networks are a subset NC>of operating systems :-). Almost, Noel. Operating systems are a subset of networks. :-) Let me preface my remarks. I am trying to get a better sense of applications for EIDs. Both the applications and usages are somewhat elusive for many people. I don't suggest that threads are the only use of EIDs, merely that threads across a network are one potential application for EIDs. Tony Li, I believe, commented earlier on a possible placement of EIDs in a stack position near a thread. I also find it interesting that potential host-oriented applications of threads (is this some of what you're looking for in the RFA, Dave Crocker?) are at the "extremes" of timing: the real-time thread things here, and C. Harald Koch's example of a week-long FTP session. NC> This is not to say your ideas are bad: just don't snarf other terms NC> to describe them. You may not be sure what an EID is, but I am! No problem, and your response helped me clarify my "thought-experiment" of how EIDs might be used. For sake of argument, let me discuss what I see as the potential use of EIDs for multithreaded multiprocessing, and ignore for the moment other applications of EIDs.I suggested in the earlier message, ...an EID is a thread identifier, and the justification for EIDs is the justification for OS threads that can have globally known identifiers. Thread identifiers normally have local significnce only. Let me refine my definition of EIDs WRT threads, at least for my context. (See, everyone? Even the _discussion_ of EIDs is useful for context swapping). 1. An EID identifies an addressable "place" at which a thread can run, not the thread itself as previously proposed. 2. Not all EIDs identify places at which all threads can run, but an EID can belong to one or more thread-acceptor-groups (TAG). #1 and #2 seem to agree with Mark Andrews' suggestion that an EIDidentifies a "protocol entity" that may move. Perhaps, for the thread case, we could think of the EID proper as the part that finds where a thread might run, and the TAG ID as something like a port ID or service selector. 3. There may be a need for a "Thread Processing Resolution Protocol,"based on ARP principles, which an EID willing to accept a threadbelonging to a particular thread-group responds to a multicast query looking for an EID to run the thread. Rather than a query/response thread acceptors could advertise their willingness to accept threads. 4. Once a thread acceptor is located, the thread dispatcher sends a datagram with the information necessary to run the thread If there is a need to return to the dispatcher, that return is the responsibility of the completed dispatched thread. NC> Probably in the (distant :-) future there will be a Standard for NC> the definition of a "mobile process", so that it can wander NC> from machine to machine in an interoperable way. .... NC> First, we have the issue of different processor architectures to NC> deal with (a process can't just stop running on a 68K, move to a NC> 80?86 and keep rrolling). NC> Second, much as all modern operating systems look reasonably alike NC>... there are still a lot of differences... Agreed. Different processor or OS architectures cannot be in the same thread-acceptor-group. Defining a "mobile process" is more ambitious than a "mobile thread." For my discussion, a thread is a sufficiently lightweight process as to requirethat all threads of a group run on a specific processor and operating system architecture. A thread identifier -- whatever that is, which is not an EID -- would need, to be "mobile," some sort of thread group identifier that identifies what the thread is willing to run on. Scenario: Processor #1 is starts a task and decides it wants to spawn a thread to execute some function concurrently with the main task. This thread can run on any processor that belongs to thread-acceptor-group A. Processor #1 then broadcasts something along the line of an ARP Request: "I am EID 1.1. Is anyone willing to execute a thread of group A?" One or more "things-that-have-EIDs" respond. Processor #1 handshakes with the first responder (processor #2) and passes a pointer or data to #2 using a reliable transfer (probably NOT an RPC). If processor #1 itself had multiple processing capabilities, it would have multiple EIDs and could respond to itself that it has a local tightly-coupled processing resource available. This response would probably stay in the thread dispatcher. NC> We will probably need identifiers for mobile processes, and to the NC> extent that a mobile process is also an endpoint, NC> perhaps we can identify them by the names of their associated NC> endpoints. However, all this has nothing to do with endpoints (which NC>are *defined* as a purely networking concept - an indivisible end/end NC>communication entity), and EID's (which are *defined* as names for NC>endpoints). How about a more network-oriented definition of a pair of endpoints, one belonging to the thread dispatcher and one to the thread acceptor, as the source and destination addresses in a connectionless interaction? (groan) this network vs. host-orientation stuff is getting very threatening;my self-image is as a lower layers type (you know, real men do it in silicon, or at least in router code), but someone hurls me back in the application and/or OS swamp. In my sordid past when I did OS/360 system programming, one of my colleagues, Barry Lewis, explained his project as "a software performance monitor. Look at it this way: a user is a test program for an application,an application is a test program for an operating system, and an operating system is a test program for a performance monitor." I then commented that a host with a performance monitor must be a test program for my network. Are no truisms true anymore? ;-) Howard From owner-big-internet@munnari.oz.au Sat Apr 24 09:35:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20561; Sat, 24 Apr 1993 09:35:49 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13274; Sat, 24 Apr 1993 06:31:12 +1000 (from chk@dino.alias.com) Received: from yonge.csri.toronto.edu by shark.mel.dit.csiro.au with SMTP id AA16990 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 24 Apr 1993 06:30:37 +1000 Received: from alias by yonge.csri.toronto.edu with UUCP id <14507>; Fri, 23 Apr 1993 16:24:20 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA28374 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Fri, 23 Apr 93 16:13:50 -0400 Received: by dino.alias.com id AA25315 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Fri, 23 Apr 93 16:13:47 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9304232013.AA25315@dino.alias.com> Subject: Re: EIDs To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 23 Apr 1993 17:13:45 -0400 Cc: mandrews@alias.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9304231506.AA06838@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 23, 93 11:06:58 am X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1277 > What would be the utility of having two EID's for the same host? A local example come immediately to mind; we have a host-alias called "mail"; this is the internal email server (for various different non-intelligent clients). The actual machine "mail" points to in the DNS changes from time to time, depending on host and network load, administrative policies, and so on, which is why we gave the mail sub-functions their own hostname. "mail" currently points to "barney", but just last week it was "dino", my home machine. I can think of a situation where I'd like to take "mail" down for maintenance. If all "mail" associated functions (SMTP, POP, IMAP, PHQuery) were assigned a separate EID, then I could temporarily move them to another machine without any clients (even currently active ones) noticing. This is merely another example of the mobile processes function of EIDs, but to me it's a concrete example of the kind of flexibility lacking today. Ah, what a dream... :-) -- C. Harald Koch, Network Manager | "He who knows does not speak, Alias Research Inc. Toronto, ON | He who speaks does not know." chk@alias.com | -Taoist philosopher Lao-Tzu in the chk@gpu.utcc.utoronto.ca | Tao Te Ching, circa 300 BC From owner-Big-Internet@munnari.oz.au Sat Apr 24 11:02:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24659; Sat, 24 Apr 1993 11:02:30 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24656; Sat, 24 Apr 1993 11:02:18 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA08366; Fri, 23 Apr 93 18:01:56 -0700 Message-Id: <9304240101.AA08366@Mordor.Stanford.EDU> To: chk@alias.com (C. Harald Koch) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), mandrews@alias.com, big-internet@munnari.oz.au Subject: Re: EIDs Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 23 Apr 93 17:13:45 -0400. <9304232013.AA25315@dino.alias.com> Date: Fri, 23 Apr 93 18:01:56 -0700 From: Dave Crocker X-Mts: smtp Perhaps I'm missing something fundamental, but: ---- Included message: > What would be the utility of having two EID's for the same host? A local example come immediately to mind; we have a host-alias called "mail"; this is the internal email server (for various different non-intelligent clients). The actual machine "mail" points to in the DNS changes from time to time, depending on host and network load, administrative policies, and so on, which is why we gave the mail sub-functions their own hostname. "mail" currently points to "barney", but just last week it was "dino", my home machine. I can think of a situation where I'd like to take "mail" down for maintenance. If all "mail" associated functions (SMTP, POP, IMAP, PHQuery) I believe this is an example of "process" (or "role") based referencing and has been characteristic of distributed processing approaches since no later than 1971 with the work done on the Irvine Ring. Curiously, Netbios has the same model. Rather than referencing processes on a machine, one references the processes without explicit knowledge of the machine. Magic is required to map from the process name to the machine that holds the process. Most such systems are small-scale and use multicasting to achieve the rendezvous function. For those processing roles that can benefit from machine-independent naming, it can be quite powerful. To my knowledge, there has been no demonstration of such a facility operating in a very large scale and heterogeneous system. Further, it is not clear that such a facility needs to be built into the core of the communications infrastructure, rather than layered on top of it. Comments? Dave From owner-big-internet@munnari.oz.au Sat Apr 24 13:09:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28973; Sat, 24 Apr 1993 13:10:03 +1000 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25605; Sat, 24 Apr 1993 11:38:57 +1000 (from hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04665; Fri, 23 Apr 93 18:38:38 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA22612; Fri, 23 Apr 93 18:38:43 PDT Received: from by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AB16402; Fri, 23 Apr 93 18:38:27 PDT Message-Id: <9304240138.AB16402@bigriver.Eng.Sun.COM> Date: Fri, 23 Apr 1993 18:39:15 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: hinden@Eng.Sun.COM (Bob Hinden) X-Sender: hinden@hacketorium.eng.sun.com (Unverified) Subject: Re: still trying to understand EIDs Cc: big-Internet@munnari.oz.au Content-Length: 1690 Noel, >The latter; one EID to name *all* the network stuff in an endpoint, including >the IP layer itself, ICMP, UDP, TCP, the lot. For the average host, where the >endpoint includes the entire machine, one EID would name the whole host. > >Another way to look at it is that, when you get to the host, an EID does just >about the same things an IP address does now. It's just that the EID doesn't >say *where* in the network the thing is, and the routers do not construct >routes based directly on it. By this definition, wouldn't the current 32-bit IP network numbers qualify as EIDs? Ignoring subneting, they do not contain any information which tells a router how to reach another network number with out running a routing algorithm which computes to topological relationships. Just looking at the network number, which "identifies" the network, does not provide any information on what the topology is. For example, in the case of mobile networks (not mobile hosts), we can support moving a particular IP network to another location today. You just plug in your router to the new location, it exchanges routing updates with other routers, and everyone learns about the new route to the network. The hosts on the mobile network do not have to change addresses, DNS tables do not need to be updated, etc. TCP connections would even continue from where they left off. Granted we haven't built the routing protocols which would allow this to scale, but it will work today. The strength and weakness of the current IP network addresses is that they do not contain topological information. It makes the routing scaling problem hard but provides flexibility in other areas. Bob From owner-Big-Internet@munnari.oz.au Sun Apr 25 01:03:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29191; Sun, 25 Apr 1993 01:04:00 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29185; Sun, 25 Apr 1993 01:03:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14574; Sat, 24 Apr 93 11:03:38 -0400 Date: Sat, 24 Apr 93 11:03:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304241503.AA14574@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, hinden@eng.sun.com Subject: Mobility and EID's Cc: big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu From: Dave Crocker I believe this is an example of "process" (or "role") based referencing and has been characteristic of distributed processing approaches since no later than 1971 with the work done on the Irvine Ring. Funny you should mention the Irvine Ring; the first project I worked on at MIT-LCS was the new, improved Irvine Ring interface, which was designed by someone called Paul Mockapetris! Small world! :-) (I bet we both wish we could forget that Ring, but that's another story. :-) Rather than referencing processes on a machine, one references the processes without explicit knowledge of the machine. Magic is required to map from the process name to the machine that holds the process. Well, referencing the processes without knowledge of where they are is not necessarily the wrong thing. It just depends on how and where you do it. For instance, the aforementioned new Irvine Ring interface had *hardware* support for mobile processes, which I don't think is really the right thing! A protocol stack (going all the way up to the application) is just a set of nested abstractions, yes? I would say that at some layer within the abstraction stack, it is useful and appropriate to view processes as (possibly mobile) objects, without necessarily knowing where they are. Some lower layer then has the responsibility of *binding* references to these mobile objects to their current location. Most such systems are small-scale and use multicasting to achieve the rendezvous function. Ah, that's just an example of providing the mobility function at the wrong place, or with the wrong mechanism, just like the Irvine Interface was wrong. If you have a mobile object, and the *only* name you have for the mobile object *stays the same* wherever it goes, then either: i) to find it, you ask for it throughout the network (multicast), or ii) your routing system tracks those names directly, so the packet switches always know where it is. Neither scales to a large system. To my knowledge, there has been no demonstration of such a facility operating in a very large scale and heterogeneous system. You've just indirectly hit the nail upon the head. In small systems, it often works to intermingle two functions in a single mechanism. A classic example is the ARPANet, which did routing *and* congestion control with one mechanism. Nobody is trying to do this in the Internet! (Two *interacting* ones, sure, it has to be, but let's not get into that.) As a general system design principle, as systems get larger, you wind up pulling functions apart into separate mechanisms. The reason is obvious: a small system can withstand functions X and Y being done half-way well by one mechanism, but as the system gets larger, X and Y usually have to be done much better, and you can't do that with one mechanism; you wind up with two, each of which does one thing well. This is exactly the case for explicit recognition of endpoints (and naming them with EID's). The two functions of 'location/routing' and 'end-end naming' used to be performed with one name, the 'IP address'. We now need two different ones, the "interface address" and "endpoint id", *each with different characteristics appropriate to the tasks they have to do*. Further, it is not clear that such a facility needs to be built into the core of the communications infrastructure, rather than layered on top of it. This is the key question: at what layer is it appropriate to provide that functionality? To answer this, we ask: Do we want end-end transport connections to survive a move on the part of one end, essentially invisible to the client of the connection on the other end? The alternative is that such transport connections *do not* survive, but rather a new one must be set up, perhaps via some high layer mechanism which keeps some abstract end-end connectivity going across multiple transport connections. The answer seems to be the former: everyone want to keep TCP connections open, there is just no agreement on exactly how. To me, it's obvious that if we do not want to put this function into a *higher* layer than the transport, then the transport layer itself must do it, which means having names for transport entities which survive motion on the part of those entities. Hence, the EID. So why have EID's in the internetwork layer as well? Well, you have to have a *binding* between transport entity names (EID's) and the interfaces names (addresses) the internetworking layer uses to deliver packets. We could put this into an intermediate layer, but that seems to me to be too inefficient. (Yes, I do think about implementation issue, believe it or not! :-) Since the primary function of the transport layer is to provide reliable streams, and the primary function of the internetwork layer is unreliable end-end delivery, it makes more sense to me to package it in with the latter, effectively as a sub-layer on top of interface-interface. Mechanisms at the internetwork layer would provide the binding, and alter it if needed. From: Bob Hinden By this definition, wouldn't the current 32-bit IP network numbers qualify as EIDs? Ignoring subneting, they do not contain any information which tells a router how to reach another network number with out running a routing algorithm which computes to topological relationships. In at least two respects (even ignoring subnetting) current IP addresses do not follow the 'precepts' of EID's. To begin with, IP addresses *still* have the property that X.A and X.B (where X is the IP network number) are co-located. So, this does not match one of the key properties of EID's (as names, in and of themselves), which is that they contain no topological information whatsoever. EID's *deliberately* cannot contain such information, so that an EID *can* stay the same no matter where the endpoint it names goes. Second, to the extent that it is clear *what* IP addresses *name* (since this was never made clear explicitly at the time the architecture was designed), it seems that they name *interfaces*. Sample test: a host with two interfaces has two IP addresses. ("If it walks like a duck, and quacks like a duck...." :-) EID's deliberately do not name interfaces, since they wish to remain the same no matter which interface traffic to the endpoint they name is going through; they thus name transport, end-end, entities. ... they do not contain any information which tells a router how to reach another network number with out running a routing algorithm which computes to topological relationships. Just looking at the network number, which "identifies" the network, does not provide any information on what the topology is. ... The strength and weakness of the current IP network addresses is that they do not contain topological information. It makes the routing scaling problem hard but provides flexibility in other areas. Well, this is just another general facet of the point I made above about separate mechanisms. Old style IP network addresses tried to do two things at once: provide a name for use by the routing, but be able to stay the same when the network "moves" in the topology. This works OK when the system is small, but ceases to work when it gets larger; it results in the binding function getting stuck into a mechanism which won't scale well (the routing). The time has come to split this functionality up into two separate mechanisms. Noel From owner-Big-Internet@munnari.oz.au Mon Apr 26 22:32:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27060; Mon, 26 Apr 1993 22:32:45 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27057; Mon, 26 Apr 1993 22:32:38 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Mon, 26 Apr 1993 05:32:23 -0700 Date: Mon, 26 Apr 1993 05:32:23 -0700 From: Tony Li Message-Id: <199304261232.AA04970@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: still trying to understand EIDs From: Tony Li But at some point, this concept needs to have a concrete implementation... While I'm NOT trying to design that implementation, it would very much help this junior engineer ;-) grok the concept if I had an example of an implementation of an endpoint. Well, here's an example for you; I have a system in which processes can migrate among a small group of machines, while retaining their existence, and open TCP connections. Each such mobile process would have its own EID. To do this, you *can't* use the address and TCP port to name the connection, since the port number used at the old machine may clash with an already allocated port number at the new machine. (In addition to which, since the host, and most of the processes and open TCP connections, didn't leave the old address, it would be be pretty damned confusing to a machine on the other end if half of the TCP connections on a machine got up and went somewhere else, and the other ones didn't!) However, this does not mean that there's a one-one map from processes to EID; on a normal Unix host, where processes stay on one machine, you only need one EID for the whole machine. Sigh. Noel, this is a description of an application. NOT an implementation. There's a difference. Thus, I propose an implementation: An endpoint is a logical entity which a thread may(must?) allocate from the operating system before opening a transport level connection. When the endpoint is allocated, it comes complete with EID. There is some mechanism for the thread to learn the EID of it's endpoint. The thread may also specify the EID when it allocates the endpoint. The operating system should insure that any EID specified in this manner does not duplicate any other EID in the local operating system. [It would be nice to verify this globally, but....] A process may allocate multiple endpoints. When the thread opens a transport connection (e.g., BSD socket), it must refer to a particular endpoint. From that point on, the transport connection is bound to that endpoint. The endpoint may not be released until all related connections are closed. The connections inherit the EID of the endpoint. Well, the thing is that a lot of use want to use them to help solve things like the mobile host problem and the multi-homed host problem, and if they are only visible at the transport layer they wouldn't be very helpful for those goals. Mebbe I'm dumb. I don't see how the network layer is supposed to use EIDs to fix these problems unless there is some mapping from EID to address. But I thought that you and I agreed that there was no need for this mapping. Tony From owner-Big-Internet@munnari.oz.au Tue Apr 27 04:16:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10374; Tue, 27 Apr 1993 04:16:51 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10361; Tue, 27 Apr 1993 04:16:25 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA02383; Mon, 26 Apr 93 11:16:03 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA09074 for big-Internet@munnari.oz.au; Mon, 26 Apr 93 14:17:43 -0400 Message-Id: <9304261817.AA09074@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Steve Deering Cc: carlberg@cseic.saic.com (Kenneth Carlberg), big-Internet@munnari.oz.au Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) In-Reply-To: Your message of "Mon, 19 Apr 93 09:42:15 PDT." <93Apr19.094221pdt.12171@skylark.parc.xerox.com> Date: Mon, 26 Apr 93 14:17:43 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Steve Deering >There is *a* John Smith who is the consumer of the mail, but the string >"John Smith" on an envelope serves to demux the incoming mail to that >person. If two John Smiths live at the same address, they need different >strings to unambiguously sort out their mail without examining the content >(e.g., "John Smith, Sr." and "John Smith, Jr."). If a John Smith moves to >a new address, his "name" is not necessarily portable to that new address -- >there might another John Smith already living there. My son and I have the same name except that I use a "3rd" or "III" suffix and he uses "4th" or "IV". I had to interact with a bank officer once about my safe deposit box. They had a terminal on their desk attached to some sort of accounts database. There was also an account at that bank in trust for and under the name of my son. The offier asked for my first and last name and got multiple hits. Then they asked for my address/ZIPcode. When that didn't disambiguate things, they asked for my middle initial. Finally, they asked for my social security number which was the only key field that differentiated the two account. >... >By the way, mobility and address changes are handled in the postal system >the same way as we propose for SIP: a letter sent to a person's "permanent" >or "old" address is redirected to the "temporary" or "new" address by >having some entity at or near the permanent/old address stick a new address >on the envelope (or put the original letter inside an envelope addressed >to the current location) and resubmit it to the delivery system. These days there is also the NCOA system (national change of address) where you can send your mailing list on a floppy to a contractor who processes it against an National Change of Address database and sends you back a heuristically corrected version. >Steve Donald From owner-Big-Internet@munnari.oz.au Tue Apr 27 04:23:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10650; Tue, 27 Apr 1993 04:23:31 +1000 (from owner-Big-Internet) Return-Path: Received: from jpmorgan.jpmorgan.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10645; Tue, 27 Apr 1993 04:23:18 +1000 (from bhatiani@jpmorgan.com) Received: by jpmorgan.jpmorgan.com (5.65/fma-120691); id AA16586; Mon, 26 Apr 93 14:23:11 -0400 Received: by tcpg01a.ny.jpmorgan.com (5.65/fma-120691); id AA15515; Mon, 26 Apr 93 14:23:10 -0400 Received: by athena1 id AA03369; Mon, 26 Apr 93 14:21:09 -0400 From: bhatiani@jpmorgan.com Received: by in-the-bits.lsi.ny.jpmorgan.com (4.1/4.7) id AA04831; Mon, 26 Apr 93 14:21:07 EDT Message-Id: <9304261821.AA04831@in-the-bits.lsi.ny.jpmorgan.com> Subject: EID Visibility... To: jnc@ginger.lcs.mit.edu Date: Mon, 26 Apr 1993 14:21:07 -0400 (EDT) Cc: big-Internet@munnari.oz.au Organization: JPMorgan, New York X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1009 Hi, In the middle of trying to understand EID's. I came up with this question: EID's are a networking concept and separate current naming and routing functions. EID's perform naming and routing will be left to something else. right? Unlike IP addresses, a process/thread can have multiple EID's. My question is, what is the normal scope of an EID created by a process. I think Tony Li sort of referred to this when he mentioned checking the EID against a global database (this is ofcourse not feasible, as he observed). Since the global case is not feasible, is there going to be some way of setting the scope of the EID when you create it? The reason this is an issue is because EID's unlike IP addresses can be assigned by operating system entities like threads. Since I have just grasped the concept of an EID, ths question may be just plain ignorance. Regards, Amit ------------------------------------------------ Amit Bhatiani bhatiani@jpmorgan.com LAN Systems Integration JPMorgan, NY From owner-big-internet@munnari.oz.au Tue Apr 27 23:35:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27261; Tue, 27 Apr 1993 23:35:59 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304271335.27261@munnari.oz.au> Received: from rschp1.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23186; Tue, 27 Apr 1993 21:49:15 +1000 (from hugh@rschp1.anu.edu.au) Received: by rschp1.anu.edu.au (16.8/16.2) id AA22585; Tue, 27 Apr 93 21:49:35 +1000 From: Hugh Fisher Subject: EIDs for app programmers To: big-internet@munnari.oz.au Date: Tue, 27 Apr 93 21:49:35 EST X-Face: %Y=q|_=@?d$0;1u<%JiKdr~y6W.j4EUl6/>UNBRsq:ZYde6!><;G#F(-qY7CGW0H(^?x1Nv iVV0I,N]qeX35pkh/X7i1!+v668\'j#^Fv)GT=YIyKM)?iCA;U=w5_j#^.P!}O'~[1~F\j`.U[ Mailer: Elm [revision: 70.30] The EID debate seems never ending, with both sides convinced that they are right. Speaking as an application programmer and interested lurker, I'd like to suggest that both sides _are_ right, in their own ways. The pro EID camp are right, in that EIDs would allow transparent process migration and other wonderful things. The anti camp are right, because EIDs do not belong in IP/SIP/PIP/etc. Think about what an endpoint moving really means in these cases: 1) several file servers exporting replicated read only data. Here it would be pretty good to have transparent movement, so if the primary server goes down a backup could take over. (But how does this happen?) 2) An X Window connection to a Sparc being moved to a DECstation for some reason. The endpoint may move, but the application will collapse in a heap. When the connection was opened the app told the Sparc that it would be sending, say, big endian data, but how is the DECstation to know this? 3) If your local personnel/admin people are also using TCP/IP, try telling them that in the next version of the networking software a telnet session to the payroll database server could be transparently redirected to another host without them noticing. I don't think they will be impressed. I can also understand why the anti camp want to see more concrete examples. Exactly _how_ will a TCP connection to an EID get transferred from a Macintosh running System 7 to a VAX? What will happen to data received and acked by the network software on the first host but not yet transferred to user code? Can the new host refuse to accept the transfer if it would impose too much load? Suppose the original host closes down its part of the connection and the new host then crashes? What should the sender do if data is acknowledged by both the old and new hosts? No doubt all these can be solved, but I suspect the answer will be some sort of negotiation protocol - in which case we might as as well include both ends of the connection in the process to take account of application requirements. Hugh Fisher (Fools rush in...) From owner-big-internet@munnari.oz.au Tue Apr 27 23:31:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27085; Tue, 27 Apr 1993 23:31:45 +1000 (from owner-big-internet) Return-Path: Received: from searn.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21032; Tue, 27 Apr 1993 20:48:49 +1000 (from @SEARN.SUNET.SE:rafal@camk.edu.pl) Received: from camk.edu.pl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Tue, 27 Apr 93 12:46:49 +0200 Received: from delta.camk.edu.pl.camk.edu.pl by camk.edu.pl (4.1/RP-1.0) id AA11821; Tue, 27 Apr 93 12:46:31 +0200 Date: Tue, 27 Apr 93 12:46:31 +0200 From: rafal@camk.edu.pl (Rafal Pietrak) Message-Id: <9304271046.AA11821@camk.edu.pl> To: big-Internet@munnari.oz.au Subject: Re: EIDs revisited (was Re: What's wrong with this picture?) Hi all, (IMHO) I beleve that often putting the same concept in different words helps understand it. So let me express my understanding of the whole EID bussiness. FIRST requirement: TCP connection should not depend on host's address. One needs TCP to open on host 'invariant' i.e. on an EID. Now the disscussion lead to the conclusion that it may be feasable to have this EID translated into an address dynamicaly (although it's not clear by what means...multicast DNS?), according to the host movement in network topology. This scheme saves routers the job of tracking hosts movement thus leaving the job for the interested host, and saves the TCP layer the job of tracking the updates to the host's actuall address. This is a well defined job and may be encapsulated in a well separated sublayer while keeping the network and TCP layers' functionality as they are today. So, addresses serve routing purpose, EIDs serve in 'knowing' your communicating party. Having the snail-mail example handy, I tend to see _everything_ one writes on the envelope as an address, while EID is the drivers licence (or whatever, like Social Security Card) the recepient shows at the PO when retrieving registered mail. SECOND requirement: process migration; one may like a process (i.e something above the TCP layer, might be a thread) to have its own EID. It's worth seeing, that it would allow for changing of the host's address, the host itself (different host-EID), transport port and even the transport itself, while still maintaining the ?connection?service. Cool. Still, even if hosts and processes may share the same Network Name Space (I'd use DNS here, for it has _vary_ appropriate functionality, but the NNS _must_ have a little different implementation, so let's not mix them), it would be better if they occupy _different_ fields in a packet -- that is host-EID out off, while thread-EID within the TCP layload. It's not yet clear to me, how to get this (sub)layer implemented. On the other hand; may be all the layers above the network layer deserve an EID sublayer? ...managed by a common NNS code? And one more comment on the EID validation required. Trying to think about feasable EID hierarchy I came to the conclusion that possibly the end-node (host) should be responsable for its own validation. You Are Your Own Net Name Server (YAYO NNS) would _have_ to implement some sort of public key encryption. I beleve that, apart from the actual PK selection used, there are standard procedures to do so: host A encripts its EID(+net_time?) with its private key, while comminicating party (host B) retrieves host's A public key from the NNS/DNS/"EID issuing authority". When the decripted and open (present in every packet) EIDs match -- you know who you are talking to. The trick would be not to store critical data in the net -- its the hosts responsibility to get its key(s) and make them publicly known -- i.e by registering them in a directory service (X.500, NNS). And again, a host may not register its public key enywhere and still have trusted communication with some parties by sending it directly to them -- once the communication is established, it can be trustfully maintained without external assistance. In that case one may have IEEE MAC address as EID and still be able to validate the conversation partner. -Rafal From owner-big-internet@munnari.oz.au Wed Apr 28 07:28:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14894; Wed, 28 Apr 1993 07:28:23 +1000 (from owner-big-internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09192; Wed, 28 Apr 1993 04:39:09 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA02359; Tue, 27 Apr 93 14:34:13 -0400 Date: Tue, 27 Apr 93 14:34:13 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9304271834.AA02359@er.doe.gov> To: Hugh.Fisher@anu.edu.au, big-internet@munnari.oz.au Subject: Re: EIDs for app programmers The EID discussion seems to be now wandering into new directions such as what services could be location independantly defined. I agree that this is a useful discussion and that these ideas are important. However, the EID discussion began with the conceptually simple idea that it might be useful to separate the two concepts of the identity of the endpoint and the topologically significant address of the endpoint's network connection. In most cases an EID would identify a computer system. Yes I know there are multiprocessors where addressing individual processors within a single box would be useful and network attached groups of processors running under some network OS which it might be useful to refer to as one "system". In addition, there are issues in multilevel secure systems where multiple EID's per box might be useful. There is also the question of distributed processes and how they map onto boxes; however, this is primarily an application level problem and is distinct from the network layer EID's whihc were discussed initially (due to issues of data format, access control,...etc.) The EID's that we have been talking around for the past n months (n>1, naddress binding is critical to make the network deliver bits anywhere and this binding must be able to change when addresses change so that topology changes do not affect open process to process links. This suggests that EID is appropriate for the network layer where other transport protocols and services can build on it. O(1) EID's per system is also probably a sensible choice because it makes assigning unique EID's easier to guarantee. In terms of how to assign EID's there are two sorts of proposals around: automatic assignment based on something like ethernet address and hierarchical assignment based on administrative unit or something like that. My particular view is that for local site manageability it would be useful to have at least a weakly hierarcical assignment scheme. Dan Hitchcock From owner-big-internet@munnari.oz.au Wed Apr 28 11:25:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25135; Wed, 28 Apr 1993 11:25:16 +1000 (from owner-big-internet) Return-Path: Received: from postoffice1.psc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16837; Wed, 28 Apr 1993 08:20:24 +1000 (from news@psc.edu) Received: by postoffice1.psc.edu (5.57/Ultrix3.0-C 02/11/93 boone) id AA00505; Tue, 27 Apr 93 18:19:51 -0400 To: big-internet@munnari.oz.au Path: munnari.oz.au!owner-big-internet From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Newsgroups: psc.pscnet.maillists.ietf.big-internet Subject: Re: EIDs for app programmers Date: Tue, 27 Apr 93 14:34:13 -0400 Organization: Pittsburgh Supercomputing Center, Pittsburgh PA, USA Lines: 48 Message-Id: <9304271834.AA02359@er.doe.gov> Reply-To: Hugh.Fisher@anu.edu.au, big-internet@munnari.oz.au Nntp-Posting-Host: mailer.psc.edu Originator: daemon@mailer.psc.edu The EID discussion seems to be now wandering into new directions such as what services could be location independantly defined. I agree that this is a useful discussion and that these ideas are important. However, the EID discussion began with the conceptually simple idea that it might be useful to separate the two concepts of the identity of the endpoint and the topologically significant address of the endpoint's network connection. In most cases an EID would identify a computer system. Yes I know there are multiprocessors where addressing individual processors within a single box would be useful and network attached groups of processors running under some network OS which it might be useful to refer to as one "system". In addition, there are issues in multilevel secure systems where multiple EID's per box might be useful. There is also the question of distributed processes and how they map onto boxes; however, this is primarily an application level problem and is distinct from the network layer EID's whihc were discussed initially (due to issues of data format, access control,...etc.) The EID's that we have been talking around for the past n months (n>1, naddress binding is critical to make the network deliver bits anywhere and this binding must be able to change when addresses change so that topology changes do not affect open process to process links. This suggests that EID is appropriate for the network layer where other transport protocols and services can build on it. O(1) EID's per system is also probably a sensible choice because it makes assigning unique EID's easier to guarantee. In terms of how to assign EID's there are two sorts of proposals around: automatic assignment based on something like ethernet address and hierarchical assignment based on administrative unit or something like that. My particular view is that for local site manageability it would be useful to have at least a weakly hierarcical assignment scheme. Dan Hitchcock From owner-Big-Internet@munnari.oz.au Thu Apr 29 01:42:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29256; Thu, 29 Apr 1993 01:42:46 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9304281542.29256@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29249; Thu, 29 Apr 1993 01:42:22 +1000 (from clynn@BBN.COM) Date: Wed, 28 Apr 93 11:34:44 EDT From: Charles Lynn To: big-internet@munnari.oz.au Subject: Re: EIDs for app programmers Dan, You said: Therefore, EID's could let your network manager change service providers with out breaking your AFS link to the file server across the network. There is no way within the network layer for these EID's to let you change your file server from a SPARC to an SGI or whatever because the data format infomation required for this to work IS NOT AVAILABLE TO the network layer! Since EID's really represent a stateful fate-sharing endpoint, e.g., TCP ports, sequence #s, etc., it is also the case that higher layer information, e.g., data format, etc. would be part of the same fate sharing region that would be moved with the EID to a new host. The higher layer information does not need to be available to the network layer; it needs to be moved as part of the state which also contains the EID so that the appropriate layer can access the information that it requires. EIDs won't magically cause folks to write code that can move through the network. They enable code that is written that way to transparently bring their "communications stacks" along with them. Charlie From owner-big-internet@munnari.oz.au Thu Apr 29 05:18:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07377; Thu, 29 Apr 1993 05:18:14 +1000 (from owner-big-internet) Return-Path: Received: from postoffice1.psc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03204; Thu, 29 Apr 1993 03:33:40 +1000 (from news@psc.edu) Received: by postoffice1.psc.edu (5.57/Ultrix3.0-C 02/11/93 boone) id AA19623; Wed, 28 Apr 93 13:33:17 -0400 To: big-internet@munnari.oz.au Path: munnari.oz.au!owner-Big-Internet From: clynn@bbn.com (Charles Lynn) Newsgroups: psc.pscnet.maillists.ietf.big-internet Subject: Re: EIDs for app programmers Date: Wed, 28 Apr 93 11:34:44 EDT Organization: Pittsburgh Supercomputing Center, Pittsburgh PA, USA Lines: 23 Message-Id: <9304281542.29256@munnari.oz.au> Reply-To: big-internet@munnari.oz.au Nntp-Posting-Host: mailer.psc.edu Originator: daemon@mailer.psc.edu Dan, You said: Therefore, EID's could let your network manager change service providers with out breaking your AFS link to the file server across the network. There is no way within the network layer for these EID's to let you change your file server from a SPARC to an SGI or whatever because the data format infomation required for this to work IS NOT AVAILABLE TO the network layer! Since EID's really represent a stateful fate-sharing endpoint, e.g., TCP ports, sequence #s, etc., it is also the case that higher layer information, e.g., data format, etc. would be part of the same fate sharing region that would be moved with the EID to a new host. The higher layer information does not need to be available to the network layer; it needs to be moved as part of the state which also contains the EID so that the appropriate layer can access the information that it requires. EIDs won't magically cause folks to write code that can move through the network. They enable code that is written that way to transparently bring their "communications stacks" along with them. Charlie From owner-big-internet@munnari.oz.au Fri Apr 30 15:50:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04312; Fri, 30 Apr 1993 15:51:23 +1000 (from owner-big-internet) Return-Path: Message-Id: <9304300551.4312@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08211; Fri, 30 Apr 1993 05:40:51 +1000 (from ULLMANN@PROCESS.COM) Date: Thu, 29 Apr 1993 15:38 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: expansion on my note about IPv7 and EIDs Hi, This expands a little on a previous posting; I was told it was way too concise trying to explain migrating IPv4/v7 addressing to EIDs. --- Picking out one little bit from Noel to make a starting point: Date: Sat, 24 Apr 93 11:03:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Second, to the extent that it is clear *what* IP addresses *name* (since this was never made clear explicitly at the time the architecture was designed), it seems that they name *interfaces*. Sample test: a host with two interfaces has two IP addresses. ("If it walks like a duck, and quacks like a duck...." :-) Actually, it is more like "Since we call it a duck, it must be a duck!" ("Sooo... if she _weighs_ the same as a duck ... ", "yes ...", " ... she's a witch!! Burn her!") I disagree. We clearly have multiple interfaces to the same logical net (which want the same address) and multiple networks present on the same interface. (RFC791: "That is, provision must be made for a host to have several physical interfaces to the network with EACH HAVING SEVERAL logical internet addresses.") What an IP address names is a host's logical presence on a network. This has little or nothing to do with an "interface", except that they are _sometimes_ one-to-one. (A good example is a single host slip-linked to a LAN; the simplest thing to do is to give it a host number on the LAN's network, and have the intermediary proxy-ARP. The point of the setup is to give the host a logical presence on the LAN network; the address names that presence.) The idea that an interface has exactly one IP address was an ASSUMPTION, a design decision made (without realization, I suspect) by the implementors of the Berkeley Unix TCP/IP. (Or did they get it from a precursor?) In my opinion, it was a very bad decision; it is painful to fix. (Now we have "unnumbered interfaces", as though they were supposed to have numbers, and "secondary addresses".) It led directly to the perversity of a "loopback" address, to talk to the "loopback interface". Using all-zeros (this host on this net) would have been, and still is, a better choice. (Now you even see the perversity propagated into the DNS, with a name like "localhost." for the address that shouldn't exist in the first place.) Much better to have zero or more addresses for the host, and have a default selected for each interface for selecting the transport layer source EID (since the model does overload "address" and "EID" on the same number, as Noel points out.) Zero or more you say? Sure, so even on an isolated host I can do telnet 0.0.0.0.0.0.0.0. --- There is another assumption made, by the logical fallacy of deriving the converse. The IP catenet model does say: "If a host has an address on network X, it can send directly to any other host with an address on network X." It does NOT say: (the converse) "If a host can send directly to a host with an address (only) on network X, the host must have an address on network X." Since it can't be derived, we can assign the truth value either way (it is an independent axiom of the system), and we get two different models: The Strict Catenet Model: "If a host (only) on network X sends to a host (only) on network Y, it must send through a host (router) that is on both networks X and Y. (Or a series of such hosts.)" The Loose Catenet Model: "A host may send directly to a host on a different network." The latter is much more useful in the real world. There are some implementations (a particular router comes to mind) that insist on the strict model, and this forces assignment of addresses to hosts that really don't need or want them. (It is amusing to watch such routers operating in the belief that they are routing traffic between different logical nets on the same physical cable, while all the hosts happily talk directly to each other. :-) A good example is X.25 and ISDN, where it is perfectly reasonable to have the host talking directly to other hosts on thousands of other nets. --- With the loose catenet model you don't need the inane business of assigning "network" numbers to point-to-point links (and hence don't need to configure any). The routing simply knows (e.g. learns via the ordinary routing protocol) which networks are (best) reached by going to the other end of the link. (One of my favorite quotes, Radia Perlman in Interconnections, on not needing link addresses: "Hey, you! Yes, of course, I mean you. Who else would I be talking to? The cable?" ;-) When you are building a network of P-P links, like a WAN backbone, you assign a net number to the local net in each switching center, and a host number to each switch. (IMP/host :-) --- Now that we don't have all those extraneous addresses around, we can start doing proper Level I routing of them, treating them as EIDs. (The routing tracks the location on the physical net of each fate- sharing endpoint.) --- Then if you have a routing protocol (like RAP) that can do Level I, intra-area, and interdomain routing with the same protocol, you can start letting those EIDs wander as far as your router thrust and authentication can take you. This moves to an even looser model, no longer described by catenated networks: "A host may be able to send directly to another host, or maybe not." --- The "address" now has the proper semantics of EIDs: they appear in the datagrams for use by the transport layer and for use by the "entrance" router to assign them to a flow or forward-route (you don't want every host to have to do that, do you? Sure, _some_ will. Particularily if the host wants to do a bandwidth-reserved flow, or wants to be able to check (ala Perlman robust paths) that the datagram came via a particular path.) The EIDs are tracked directly (to the limit of thrust/bandwidth,) or indirectly by the routing layer. No, this isn't a requirement of the EID concept, it is _one_way_ for the net to follow movements of EIDs. This is the design choice made by IPv7/RAP. They are assigned administrativly. Again, this is a design choice. Part of the reason is to expand on the IPv4 EID assignment system rather than changing the world; i.e. in IPv4, EIDs (one of the two overloaded functions of the v4 "address") are in fact administrative assignments. The other reason is that it is going to be useful for a long time to be able to route blocks of these things, even though the eventual system may be able to do pure EID->(DNS or something*)->path->destination. (* See RFC1183 sect 3, and make _sure_ you look at reference [13] :-) Yes, you detect another design choice. Say an application (session layer for purists) wants to communicate with a remote process it knows by name (delta.process.com/smtp). There are two possibilities: 1) map name->(EID,pathID), then offer both EID (in the transport header), and pathID (in the network header) to the network service interface at each transmission. (If the EID is part of the pathID, it just means it doesn't need to be in the transport header.) 2) map name->EID, offer EID to the network service interface, the network service interface maps EID->pathID. The network forwards on pathID. IPv7 chooses the latter. Rationale: It means the session/transport doesn't have to know about the pathIDs. The advantages are that the network service isn't involved in the session/transport layer binding; that means it doesn't have to be on the same machine, and doesn't need to know if higher layers have retained the bound values. Most end-node hosts won't use the pathID at all, relying on the entrance router to do this. Which is a good thing, because most end nodes will be IPv4 for a long time. Possibly some may be hybrid hosts, using IPv4 + the v7AE option and enjoying universal connectivity. With my Best Regards, Robert