From owner-big-internet@munnari.oz.au Sat May 1 03:26:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29119; Sat, 1 May 1993 03:26:49 +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 AA23100; Sat, 1 May 1993 00:11:13 +1000 (from jmh@anubis.network.com) Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA29683; Fri, 30 Apr 93 09:11:56 -0500 Received: from petunia.network.com by anubis.network.com (4.1/SMI-4.1) id AA02202; Fri, 30 Apr 93 09:08:46 CDT Date: Fri, 30 Apr 93 09:08:46 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9304301408.AA02202@anubis.network.com> To: big-internet@munnari.oz.au Subject: Re: expansion on my note about IPv7 and EIDs In his recent note, Robert Ullman talks about the Strict Catanet Model (Hosts may only talk to hosts on the same net), and the Looses Catanet Model (A host may send directly to a host on a different network). Robert quotes from the standards that the current actual formal requirement is merely that hosts on the same net must be able to talk directly. He then goes on to suggest loosening the requirements even further. I am all for this. However, I should point out one thing. In the IP over ATM working group, when discussion of support for what Robert is calling the Loose Catanet Model comes up, the IESG representative has repeated said that if we want to consider that, we should ask upstairs (from the IAB) for permission to violate (or change) the architecture. His assertion, which has somewhat interfered with discussion of support for the desired model, is that the current architecture mandates the Strict Catanet Model. If this group, as one of the largest collections of routing and addressing architects in the IETF, can help get clarity on whether there is an issue here, and somehow arrange that the loose (or even the "looser") model are acceptable with current protocol, it would help much of the IP over Switched Wide Area Stuff. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.oz.au Sat May 1 04:02:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29965; Sat, 1 May 1993 04:03:00 +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 AA29959; Sat, 1 May 1993 04:02:53 +1000 (from news@psc.edu) Received: by postoffice1.psc.edu (5.57/Ultrix3.0-C 02/11/93 boone) id AA07999; Fri, 30 Apr 93 14:02:35 -0400 To: big-internet@munnari.oz.au Path: munnari.oz.au!owner-big-internet From: jmh@anubis.network.com (Joel Halpern) Newsgroups: psc.pscnet.maillists.ietf.big-internet Subject: Re: expansion on my note about IPv7 and EIDs Date: Fri, 30 Apr 93 09:08:46 CDT Organization: Pittsburgh Supercomputing Center, Pittsburgh PA, USA Lines: 27 Message-Id: <9304301408.AA02202@anubis.network.com> Reply-To: big-internet@munnari.oz.au Nntp-Posting-Host: mailer.psc.edu Originator: daemon@mailer.psc.edu In his recent note, Robert Ullman talks about the Strict Catanet Model (Hosts may only talk to hosts on the same net), and the Looses Catanet Model (A host may send directly to a host on a different network). Robert quotes from the standards that the current actual formal requirement is merely that hosts on the same net must be able to talk directly. He then goes on to suggest loosening the requirements even further. I am all for this. However, I should point out one thing. In the IP over ATM working group, when discussion of support for what Robert is calling the Loose Catanet Model comes up, the IESG representative has repeated said that if we want to consider that, we should ask upstairs (from the IAB) for permission to violate (or change) the architecture. His assertion, which has somewhat interfered with discussion of support for the desired model, is that the current architecture mandates the Strict Catanet Model. If this group, as one of the largest collections of routing and addressing architects in the IETF, can help get clarity on whether there is an issue here, and somehow arrange that the loose (or even the "looser") model are acceptable with current protocol, it would help much of the IP over Switched Wide Area Stuff. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.oz.au Sat May 1 04:30:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00978; Sat, 1 May 1993 04:31: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 AA00973; Sat, 1 May 1993 04:30:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00674; Fri, 30 Apr 93 14:30:52 -0400 Date: Fri, 30 Apr 93 14:30:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9304301830.AA00674@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, jmh@anubis.network.com Subject: Re: expansion on my note about IPv7 and EIDs Cc: iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu In his recent note, Robert Ullman talks about the Strict Catanet Model (Hosts may only talk to hosts on the same net), and the Looses Catanet Model (A host may send directly to a host on a different network). ... In the IP over ATM working group, when discussion of support for what Robert is calling the Loose Catanet Model comes up, the IESG representative has repeated said that if we want to consider that, we should ask upstairs (from the IAB) for permission to violate (or change) the architecture. I don't think we need to get the IAB to formally OK this. This is the kind of thing the IETF can perfectly well decide, although I certainly would bring the IAB in at an early stage. However, let's ignore the politics and focus on the technical. It's really a routing issue; the thing is that IP routing sort of relies on the fact that addresses X.1 and X.2 (where X is an IP (sub)network) can reach each other without going through a router. The converse (X.1 and Y.1 *can't* communicate except through a router) has been assumed, since the whole concept of an IP (sub)network is that it's a line drawn around all the things which *can* commmunicate directly without benefit of a router. It's true that there's no fundamental reason to prohibit X.1 and Y.1 communicating directly if they can (and this is getting to be more common as the administrative hassle of sharing an IP (sub)network among many autonomous entities on a WAN is causing people not to do so, as the architectural model sort of requires), but it ought to be done in a clear and general-purpose way as a formal change to the architecture, not kludged into the operation of IP on one particular type of network. I've felt for a while that we should change the host IP layer so that it no longer includes the "mask and match" test to route outgoing packets. Rather, I'd rather see the hosts rely *entirely* on the routers to know where things are. I.e., whenever you go to send packets to an IP destination which is not in the cache on the host, it sends the packet to one of the routers which it can reach directly. The router will then reply (if necessary) with a redirect packet. This would allow us to hide a migration from the "strict" model to the "loose" model in the routers. This would help with a whole bunch of stuff, not just IP over WAN's, and it would allow us to get rid of some of the kludges in things like Directed ARP (which has got to be the ugliest idea since Multi-Media Bridges). I was gonna do this when I was Internet AD, but never got around to it. What does the IESG say? A new WG to write this RFC, or should IPLPDN do it? Noel From owner-Big-Internet@munnari.oz.au Sat May 1 04:53:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01588; Sat, 1 May 1993 04:56:27 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01509; Sat, 1 May 1993 04:53:40 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Fri, 30 Apr 1993 11:53:33 -0700 Date: Fri, 30 Apr 1993 11:53:33 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199304301853.AA29415@zephyr.isi.edu> To: big-internet@munnari.oz.au Subject: Re: expansion on my note about IPv7 and EIDs *> *> However, I should point out one thing. In the IP over ATM working group, *> when discussion of support for what Robert is calling the Loose Catanet *> Model comes up, the IESG representative has repeated said that if we want *> to consider that, we should ask upstairs (from the IAB) for permission to *> violate (or change) the architecture. His assertion, which has somewhat *> interfered with discussion of support for the desired model, is that the *> current architecture mandates the Strict Catanet Model. Joel, Wait a sec' while I find my hat that says "Old Boy" on the front and "Guardian of the Internet Architecture" at the back (and has a pointy top and dangling bells :-) ) ... OK. I think network architecture ought to be subject to the same process as physical theories: you use them until they begin to break, then you try to find a better one that encompasses all you knew before while fixing the breakage. Personally, I would say there are signs that the current architecture is groaning in a number of areas; public data networks is probably a good example. The Internet architecture features appealing simplicity in its catenet model, and after nearly 15 years of experience, we understand its consequences pretty well. While it is a good intellectual game to consider the implications of changing the fundamental model... we'd better be damned sure we really do understand all the consequences before we actually take real steps in that direction. Bob Braden From owner-big-internet@munnari.oz.au Sat May 1 04:56:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01589; Sat, 1 May 1993 04:56:29 +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 AA22177; Fri, 30 Apr 1993 23:46:46 +1000 (from news@psc.edu) Received: by postoffice1.psc.edu (5.57/Ultrix3.0-C 02/11/93 boone) id AA03703; Fri, 30 Apr 93 09:45:37 -0400 To: big-internet@munnari.oz.au Path: munnari.oz.au!owner-big-internet From: ULLMANN@process.com (Robert L Ullmann) Newsgroups: psc.pscnet.maillists.ietf.big-internet Subject: expansion on my note about IPv7 and EIDs Date: Thu, 29 Apr 1993 15:38 -0400 Organization: Pittsburgh Supercomputing Center, Pittsburgh PA, USA Lines: 173 Message-Id: <9304300551.4312@munnari.oz.au> Reply-To: big-internet@munnari.oz.au Nntp-Posting-Host: mailer.psc.edu Originator: daemon@mailer.psc.edu 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 From owner-Big-Internet@munnari.oz.au Sat May 1 05:11:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01952; Sat, 1 May 1993 05:11:27 +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 AA01940; Sat, 1 May 1993 05:11:12 +1000 (from news@psc.edu) Received: by postoffice1.psc.edu (5.57/Ultrix3.0-C 02/11/93 boone) id AA09723; Fri, 30 Apr 93 15:11:03 -0400 To: big-internet@munnari.oz.au Path: munnari.oz.au!owner-Big-Internet From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Newsgroups: psc.pscnet.maillists.ietf.big-internet Subject: Re: expansion on my note about IPv7 and EIDs Date: Fri, 30 Apr 93 14:30:52 -0400 Organization: Pittsburgh Supercomputing Center, Pittsburgh PA, USA Lines: 46 Message-Id: <9304301830.AA00674@ginger.lcs.mit.edu> Reply-To: big-internet@munnari.oz.au, jmh@anubis.network.com Nntp-Posting-Host: mailer.psc.edu Originator: daemon@mailer.psc.edu In his recent note, Robert Ullman talks about the Strict Catanet Model (Hosts may only talk to hosts on the same net), and the Looses Catanet Model (A host may send directly to a host on a different network). ... In the IP over ATM working group, when discussion of support for what Robert is calling the Loose Catanet Model comes up, the IESG representative has repeated said that if we want to consider that, we should ask upstairs (from the IAB) for permission to violate (or change) the architecture. I don't think we need to get the IAB to formally OK this. This is the kind of thing the IETF can perfectly well decide, although I certainly would bring the IAB in at an early stage. However, let's ignore the politics and focus on the technical. It's really a routing issue; the thing is that IP routing sort of relies on the fact that addresses X.1 and X.2 (where X is an IP (sub)network) can reach each other without going through a router. The converse (X.1 and Y.1 *can't* communicate except through a router) has been assumed, since the whole concept of an IP (sub)network is that it's a line drawn around all the things which *can* commmunicate directly without benefit of a router. It's true that there's no fundamental reason to prohibit X.1 and Y.1 communicating directly if they can (and this is getting to be more common as the administrative hassle of sharing an IP (sub)network among many autonomous entities on a WAN is causing people not to do so, as the architectural model sort of requires), but it ought to be done in a clear and general-purpose way as a formal change to the architecture, not kludged into the operation of IP on one particular type of network. I've felt for a while that we should change the host IP layer so that it no longer includes the "mask and match" test to route outgoing packets. Rather, I'd rather see the hosts rely *entirely* on the routers to know where things are. I.e., whenever you go to send packets to an IP destination which is not in the cache on the host, it sends the packet to one of the routers which it can reach directly. The router will then reply (if necessary) with a redirect packet. This would allow us to hide a migration from the "strict" model to the "loose" model in the routers. This would help with a whole bunch of stuff, not just IP over WAN's, and it would allow us to get rid of some of the kludges in things like Directed ARP (which has got to be the ugliest idea since Multi-Media Bridges). I was gonna do this when I was Internet AD, but never got around to it. What does the IESG say? A new WG to write this RFC, or should IPLPDN do it? Noel From owner-Big-Internet@munnari.oz.au Sat May 1 07:28:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06862; Sat, 1 May 1993 07:28:19 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06849; Sat, 1 May 1993 07:28:09 +1000 (from prue@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Fri, 30 Apr 1993 14:28:04 -0700 Date: Fri, 30 Apr 1993 14:28:04 -0700 From: prue@ISI.EDU (Walter Prue) Message-Id: <199304302128.AA05752@zephyr.isi.edu> To: big-internet@munnari.oz.au Subject: Re: expansion on my note about IPv7 and EIDs Cc: iesg@cnri.reston.va.us Noel, >... >I've felt for a while that we should change the host IP layer so that it no >longer includes the "mask and match" test to route outgoing packets. Rather, >I'd rather see the hosts rely *entirely* on the routers to know where things >are. I.e., whenever you go to send packets to an IP destination which is not >in the cache on the host, it sends the packet to one of the routers which it >can reach directly. The router will then reply (if necessary) with a redirect >packet. This would allow us to hide a migration from the "strict" model to >the "loose" model in the routers. This may be a good idea but I can think of one thing that it would break for me. I have had several experimental/psudo-private nets connecting various sites. The sites are already connected to the Internet and can communicate with each other. These nets wanted only hosts that were knowledgable about the experimental nets to route packets across it. If the host didn't have a specific route via the experimental gateway their traffic would default to the normal gateway towards the Internet. Some sites put their experimental hosts on a separate net or subnet but some didn't. They had hosts that were within the experiment on the same subnet as hosts that were not part of the experiment. At these sites we put static routes in each experimental host to the destinations in the experiment pointing towards the experimental gateway. Of course this is not secure. Among trusted peers this works fine however. By the way thanks again for the good commentary you have been adding to this list. Almost all of this recent discussion from you and others has been addressing technical issues, and not personality oriented. GREAT! Walt Prue From owner-big-internet@munnari.oz.au Sat May 1 08:02:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07841; Sat, 1 May 1993 08:02:21 +1000 (from owner-big-internet) Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07817; Sat, 1 May 1993 08:01:34 +1000 (from kre@munnari.OZ.AU) Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07290; Sat, 1 May 1993 07:41:51 +1000 (from solensky@andr.UB.com) Return-Path: Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA10654; Fri, 30 Apr 93 14:41:45 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA20344; Fri, 30 Apr 93 17:41:43 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA14558; Fri, 30 Apr 93 17:41:42 EDT Date: Fri, 30 Apr 93 17:41:42 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9304302141.AA14558@fenway.andr.UB.com> To: kre@munnari.oz.au Subject: New "growth" charts Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Sat, 01 May 1993 08:01:28 +1000 Resent-Message-Id: <5732.736207288@munnari.OZ.AU> Resent-From: Robert Elz Updated growth charts should now be available via anonymous ftp at munnari.oz.au:~big-internet/nsf-netnumbers-9305.ps. There are now 11,252 advertised network numbers compared to 5291 at this time last year, representing an annual growth rate of 112.67%. The "best-fit" logistic curve though the existing data also continues to accelerate: the curve now levels off at approximately 13.3 million network numbers, compared to about 4.4 million at the end of February and 13,674 this time last year. The degree of acceleration, however, seems to be less extreme than the previous number of months. This may reflect the model beginning to correct for the more recent growth rates -- the predicted numbers beginning to grow at a rate closer to reality. Prediction for June 1: 11,591 net numbers. -- Frank From owner-big-internet@munnari.oz.au Sat May 1 08:36:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08869; Sat, 1 May 1993 08:36:15 +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 AA03199; Sat, 1 May 1993 05:47:47 +1000 (from news@psc.edu) Received: by postoffice1.psc.edu (5.57/Ultrix3.0-C 02/11/93 boone) id AA10198; Fri, 30 Apr 93 15:46:53 -0400 To: big-internet@munnari.oz.au Path: munnari.oz.au!owner-Big-Internet From: braden@isi.edu (Bob Braden) Newsgroups: psc.pscnet.maillists.ietf.big-internet Subject: Re: expansion on my note about IPv7 and EIDs Date: Fri, 30 Apr 1993 11:53:33 -0700 Organization: Pittsburgh Supercomputing Center, Pittsburgh PA, USA Lines: 36 Message-Id: <199304301853.AA29415@zephyr.isi.edu> Reply-To: big-internet@munnari.oz.au Nntp-Posting-Host: mailer.psc.edu Originator: daemon@mailer.psc.edu *> *> However, I should point out one thing. In the IP over ATM working group, *> when discussion of support for what Robert is calling the Loose Catanet *> Model comes up, the IESG representative has repeated said that if we want *> to consider that, we should ask upstairs (from the IAB) for permission to *> violate (or change) the architecture. His assertion, which has somewhat *> interfered with discussion of support for the desired model, is that the *> current architecture mandates the Strict Catanet Model. Joel, Wait a sec' while I find my hat that says "Old Boy" on the front and "Guardian of the Internet Architecture" at the back (and has a pointy top and dangling bells :-) ) ... OK. I think network architecture ought to be subject to the same process as physical theories: you use them until they begin to break, then you try to find a better one that encompasses all you knew before while fixing the breakage. Personally, I would say there are signs that the current architecture is groaning in a number of areas; public data networks is probably a good example. The Internet architecture features appealing simplicity in its catenet model, and after nearly 15 years of experience, we understand its consequences pretty well. While it is a good intellectual game to consider the implications of changing the fundamental model... we'd better be damned sure we really do understand all the consequences before we actually take real steps in that direction. Bob Braden From owner-big-internet@munnari.oz.au Sat May 1 08:48:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09147; Sat, 1 May 1993 08:48:56 +1000 (from owner-big-internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03848; Sat, 1 May 1993 06:17:16 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Fri, 30 Apr 1993 13:15:53 -0700 Date: Fri, 30 Apr 1993 13:15:53 -0700 From: Dave Katz Message-Id: <199304302015.AA24543@regal.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, jmh@anubis.network.com, iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Fri, 30 Apr 93 14:30:52 -0400 <9304301830.AA00674@ginger.lcs.mit.edu> Subject: expansion on my note about IPv7 and EIDs I've felt for a while that we should change the host IP layer so that it no longer includes the "mask and match" test to route outgoing packets. Rather, I'd rather see the hosts rely *entirely* on the routers to know where things are. I.e., whenever you go to send packets to an IP destination which is not in the cache on the host, it sends the packet to one of the routers which it can reach directly. The router will then reply (if necessary) with a redirect packet. This would allow us to hide a migration from the "strict" model to the "loose" model in the routers. Hardly new technology; this is exactly how OSI first-hop routing works. From owner-Big-Internet@munnari.oz.au Sat May 1 09:00:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09518; Sat, 1 May 1993 09:01:06 +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 AA09515; Sat, 1 May 1993 09:00:59 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU From: Big-Internet-Request@munnari.OZ.AU Subject: Apologies for the duplicates Date: Sat, 01 May 1993 09:00:51 +1000 Message-Id: <5776.736210851@munnari.OZ.AU> Sender: kre@munnari.OZ.AU You have probably noticed the duplicate messages that Big-Internet has been sending in the past week or so. Apologies for those - a site with a mail->news gateway apparently also has a news->mail gateway, with the combination not working very well, and were returning all B-I articles to the list (fortunately only once). I left this happening, as until the past day or so, traffic has been fairly light (comparatively) so not too much harm was really being done (if you're on B-I and can't handle LOTS of mail, then you have a real problem), and I was hoping that someone at the offending site would fix the problem, or at least reply to my mail. They haven't, so they're deleted. Could I please remind everyone that Big-Internet is a mailing list, its not a newsgroup - gatewaying it into your local news system is fine, to provide a more convenient way for some people to access the information (or ignore it) as they choose. However, please *DO NOT* attempt to gateway your local news group back to the mailing list, and *DO NOT* make it a moderated group with the moderator's address set to be the list (or for that matter, anything at all at munnari, or anything that will be forwaded here). There are too many opportunities for things to go wrong. If people can't work out how to send messages to a mailing list, their input to B-I should probably wait until they can! kre ps: you may still see another duplicate or two - I have stopped sending messages to the offending site, but there might still be some messages either en-route to them or en-route back from them to the list, which will still appear. Apologies for those. From owner-Big-Internet@munnari.oz.au Sat May 1 09:02:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09537; Sat, 1 May 1993 09:02:24 +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 AA09532; Sat, 1 May 1993 09:02:15 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15886; Fri, 30 Apr 93 16:02:12 -0700 Message-Id: <9304302302.AA15886@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: Re: expansion on my note about IPv7 and EIDs Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 29 Apr 93 15:38:00 -0400. <9304300551.4312@munnari.oz.au> Date: Fri, 30 Apr 93 16:02:11 -0700 From: Dave Crocker X-Mts: smtp Stray thought: When attaching networks to an Internet, we use EXTERIOR gateway protocols, rather than INTERIOR gateway protocols. The purpose of this, as it has always been explained to me, is to provide serious routing and administration firewalls. So, The exterior gateways of two user networks might be able to send data packets directly to each other, and they should do exactly that. But the routing protocol packets that allow each to find out about the other are NOT sent directly to each other. They go through a third-party mediating router, to keep the routing information clean, administrative policies enforced, etc. I suspect that this distinction between data forwarding and routing protocol interaction is useful to the consideration of interactions the interactions for HOSTS (not just gateways) on different networks. Dave From owner-big-internet@munnari.oz.au Sat May 1 12:16:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14243; Sat, 1 May 1993 12:16:48 +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 AA09205; Sat, 1 May 1993 08:52:22 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15820; Fri, 30 Apr 93 15:52:12 -0700 Message-Id: <9304302252.AA15820@Mordor.Stanford.EDU> To: Noel Chiappa Cc: big-internet@munnari.oz.au, jmh@anubis.network.com, iesg@CNRI.Reston.VA.US Subject: Re: expansion on my note about IPv7 and EIDs Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 30 Apr 93 14:30:52 -0400. <9304301830.AA00674@ginger.lcs.mit.edu> Date: Fri, 30 Apr 93 15:52:11 -0700 From: Dave Crocker X-Mts: smtp Noel, This is a personal, and not a formal, response to your query about how to proceed. (I haven't a clue what the formal answer is, but I appreciate your asking the question that way and assume that a formal response will be forthcoming.) I think it is essential that most IETF work include some thought about "environmental impact", the key feature of which would be to recognize things which are outside of the architecture. When a thing is recognized as being outside of the architecture, then deep, community-wide, careful discussion about the costs and benefits should ensue. It may be that changes in underlying technology (e.g., truly huge wide-area networks) force us to make the change. It may be that apparently huge changes (moving from ethernet to fddi) don't. But recognizing that a piece of work steps over the architectural line means that we acknowledge an impact which we are likely NOT to understand immediately, since it entails behaviors that are significantly new. Get the discussion. Get the analysis. Get the consensus. Approval will be automatic. D/ From owner-Big-Internet@munnari.oz.au Sun May 2 02:03:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12439; Sun, 2 May 1993 02:04:04 +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 AA12428; Sun, 2 May 1993 02:03:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11228; Sat, 1 May 93 12:03:51 -0400 Date: Sat, 1 May 93 12:03:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9305011603.AA11228@ginger.lcs.mit.edu> To: dkatz@cisco.com, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EIDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Hardly new technology; this is exactly how OSI first-hop routing works. Pretty much. It also would have the same operating mode if no routers are present; you assume the destination is local and try and send to it. Sure, this model looks a lot like the OSI model. That's not a big deal to me. I never said that the OSI architecture was awful, or that it didn't have some places in which it had minor advantages over TCP/IP. This is such a place. However, that's not saying I think we should switch protocols, which is a whole different argument (and not one we can settle, so let's not start that again, OK? :-). There are a number of differences in the model, though. For one, I think that in the long run Redirects (in their current form) are headed for the ash-heap. As we routing gets more and more policy based, routes from a source to a destination will be set up as the result of some negotiation between the client and a "route generator"; routers simply won't be able to look at a destination address and say "oh, X is a better first hop router to that". However, that's still to come. Noel From owner-Big-Internet@munnari.oz.au Mon May 3 08:18:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07593; Mon, 3 May 1993 08:18:27 +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 AA07589; Mon, 3 May 1993 08:18:17 +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 AA00395; Sun, 2 May 93 15:18:11 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA22436; Sun, 2 May 93 15:18:26 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25505; Sun, 2 May 93 15:18:09 PDT Date: Sun, 2 May 93 15:18:09 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9305022218.AA25505@bigriver.Eng.Sun.COM> To: braden@ISI.EDU (Bob Braden) Cc: big-internet@munnari.oz.au In-Reply-To: <199304301853.AA29415@zephyr.isi.edu> Subject: Re: expansion on my note about IPv7 and EIDs Content-Length: 721 I agree with Bob Braden's message. I was at the front of the room at the IPoverATM meeting when the issue of changing the architecture came up. My response was of the form that if there was a good reason to relax the architecture (allow hosts on one IP network to send directly to host on a different IP network without going through a router) and a well engineered mechanism was developed to use it, then I didn't think it would be difficult to have the changes adopted. Work in this area in the recent past has desired the former but has been lacking in the latter. If the current work going on in the IPoverATM develops a workable solution, then I don't think the architectural issues will be insurmountable. Bob From owner-Big-Internet@munnari.oz.au Mon May 3 11:59:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16492; Mon, 3 May 1993 12:00:45 +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 AA16432; Mon, 3 May 1993 11:59:19 +1000 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB06142; Sun, 2 May 93 18:57:08 PDT Date: Sun, 2 May 93 18:57:08 PDT Message-Id: <9305030157.AB06142@wc.novell.com> To: bhatiani@jpmorgan.com From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com Subject: Re: EID Visibility... Cc: big-Internet@munnari.oz.au OK, i'm a bit confused by your questions. > 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. I don't know what it means for a process/thread to "have" an IP address or an EID. A process/thread can certainly have open various "sockets" (in the general networking sense, not in the BSD sense), each with a different IP address assigned to it (or different EID in some people's vision of the future). > > My question is, what is the normal scope of an EID created by a >process. Processes don't create EID's. Processes (whatever a process is...) create things (endpoints, sockets, whatever you would like to call them) which are bound to EID's (or to IP addresses). Greg Minshall minshall@wc.novell.com Novell, Inc. +1 510 975-4507 From owner-Big-Internet@munnari.oz.au Tue May 4 03:12:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02554; Tue, 4 May 1993 03:12:46 +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 AA02551; Tue, 4 May 1993 03:12:32 +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 AA01044; Mon, 3 May 93 10:12:27 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA24524; Mon, 3 May 93 13:12:26 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA17144; Mon, 3 May 93 13:12:25 EDT Date: Mon, 3 May 93 13:12:25 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9305031712.AA17144@fenway.andr.UB.com> To: big-internet@munnari.oz.au Subject: Re: New "growth" charts I've been correctly reminded by Terry Gray (gray@cac.washington.edu) that there's an important distinction one must keep in mind when using these graphs: the numbers being plotted represent the "network numbers" as opposed to "number of networks". If an individual organization has sixteen Class C network numbers, it would represent 16 numbers on this chart rather than the single network. In the beginning of April, I had estimated the actual number of networks then to be 7333 nets in 10693 numbers. At that ratio, there would be about 7716 connected networks. -- Frank From owner-Big-Internet@munnari.oz.au Tue May 4 04:35:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05806; Tue, 4 May 1993 04:35:22 +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 AA05800; Tue, 4 May 1993 04:35:09 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA00232; Mon, 3 May 93 11:34:58 PDT Date: Mon, 3 May 93 11:34:58 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9305031834.AA00232@saffron.acc.com> To: solensky@andr.UB.com Subject: Re: New "growth" charts Cc: big-internet@munnari.oz.au >> I've been correctly reminded by Terry Gray (gray@cac.washington.edu) >> that there's an important distinction one must keep in mind when >> using these graphs: the numbers being plotted represent the >> "network numbers" as opposed to "number of networks". If an >> individual organization has sixteen Class C network numbers, it >> would represent 16 numbers on this chart rather than the single >> network. From a very technical perspective, this is probably right. However, now we are measuring two different things: attached "customers", and network numbers that the routers need to store and maintain routes to. From a marketing perspective, customer count is interesting. But from a "to what requirements do I need to engineer my router and my routing protocols" perspective, actual network numbers is what's interesting. Fred From owner-big-internet@munnari.oz.au Wed May 5 02:49:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00976; Wed, 5 May 1993 02:50:08 +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 AA26790; Wed, 5 May 1993 01:07:08 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11731>; Tue, 4 May 1993 08:06:32 PDT Received: by redwing.parc.xerox.com id <57154>; Tue, 4 May 1993 08:06:16 -0700 Date: Tue, 4 May 1993 08:06:10 PDT Sender: Lixia Zhang From: Lixia Zhang To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: EID lookups In-Reply-To: Your message of Thu, 22 Apr 1993 18:42:11 -0700 Message-Id: > 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. > > > 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. Noel, enlighten me a bit more on this one: say we use EID for mobile host support, when I want to send to a mobile host and I know its EID, shouldn't this lookup of (EID -> current adrress) be fast? (no matter what transaction you use, ICMP or whatever). > 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. I must confess that I'm not a regular big-internet reader, just peek in now and then. Do I recall discussions about using EIDs for security purpose, or for accounting purpose? both would need authentication, need to verify whether the supplied EID is a valid one, right? And if I'm yet to be convinced that everything in the future would be long-lasting flows, I have to worry about doing this sort of lookups for short-lived transfers or datagrams. So, how could I not demand a fast EID lookup speed? I'd like to repeat my earlier point again: yes our SSN system is in a flat space, but one cannot derive a conclusion that computer EIDs can also live in a flat space. We need a proof, and I have not seen one. From owner-Big-Internet@munnari.oz.au Wed May 5 05:50:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07978; Wed, 5 May 1993 05:50:55 +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 AA07975; Wed, 5 May 1993 05:50:47 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA29369 (5.65c/IDA-1.4.4nsd for ); Tue, 4 May 1993 12:50:39 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA09633 (5.65c/IDA-1.4.4-910725); Tue, 4 May 1993 12:50:37 -0700 Message-Id: <199305041950.AA09633@remmel.NSD.3Com.COM> To: Lixia Zhang Cc: big-Internet@munnari.oz.au Subject: Re: EID lookups In-Reply-To: Your message of "Tue, 04 May 93 08:06:10 PDT." Date: Tue, 04 May 93 12:50:36 -0700 From: tracym@NSD.3Com.COM > Noel, enlighten me a bit more on this one: say we use EID for mobile > host support, when I want to send to a mobile host and I know its EID, > shouldn't this lookup of (EID -> current adrress) be fast? > (no matter what transaction you use, ICMP or whatever). > I must confess that I'm not a regular big-internet reader, just peek > in now and then. Do I recall discussions about using EIDs for > security purpose, or for accounting purpose? both would need > authentication, need to verify whether the supplied EID is a valid > one, right? > > And if I'm yet to be convinced that everything in the future would be > long-lasting flows, I have to worry about doing this sort of lookups > for short-lived transfers or datagrams. > So, how could I not demand a fast EID lookup speed? > > I'd like to repeat my earlier point again: yes our SSN system is in a > flat space, but one cannot derive a conclusion that computer EIDs can > also live in a flat space. We need a proof, and I have not seen one. Is it really an all or nothing issue? Why must ALL lookups be fast? My expectations fall near the middle of those expressed in recent messages. I expect/hope to use EIDs relatively frequently for many purposes (that's why I included the second paragraph above), BUT I expect that the actual lookup will normally only be slow once in a while, usually when I want to reach a host with whom I haven't conversed in a while. Having looked up the EID in the recent past, either I or the directory service I'm using should be able to optimize following lookups for the same EID so long as I use it often enough and don't otherwise interfere, for instance by changing my own location too rapidly, or changing directory servers, etc. I can imagine a flat space working. I can also imagine the utility of 64-bit EID's with some structure, but I think that the main purpose of the structure should be to support allocation mechanisms that would guarantee uniqueness. Regards, Tracy From owner-big-internet@munnari.oz.au Wed May 5 08:48:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14652; Wed, 5 May 1993 08:48:31 +1000 (from owner-big-internet) Return-Path: Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09171; Wed, 5 May 1993 06:29:51 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA24591; Tue, 4 May 93 13:21:10 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: expansion on my note about IPv7 and EIDs Message-Id: Date: Tue, 4 May 1993 20:19:36 GMT stev@ftp.com (stev knowles) writes: > ... > >I've felt for a while that we should change the host IP layer so that it no > >longer includes the "mask and match" test to route outgoing packets. Rather, > >I'd rather see the hosts rely *entirely* on the routers to know where things > >are. I.e., whenever you go to send packets to an IP destination which is not > >in the cache on the host, it sends the packet to one of the routers which it > >can reach directly. The router will then reply (if necessary) with a redirect > >packet. This would allow us to hide a migration from the "strict" model to > >the "loose" model in the routers. > > is this "nimrod"? I must be missing something. Besides IS-ES and maybe nimrod, isn't this "router discovery" of blessed status, as evidenced by an holy RFC? For that matter, how does this differ from the ancient "default static route" beloved by system administrators the world around? Vernon Schryver, vjs@sgi.com From owner-big-internet@munnari.oz.au Wed May 5 22:47:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26648; Wed, 5 May 1993 22:47:37 +1000 (from owner-big-internet) Return-Path: Received: from dkuug.dk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24897; Wed, 5 May 1993 21:58:37 +1000 (from kbe@sony.craynet.dk) Received: from mips.uucp by dkuug.dk with UUCP id AA19076 (5.65c8/IDA-1.4.4j for big-internet@munnari.oz.au); Wed, 5 May 1993 13:58:19 +0200 Received: from sony by craynet.dk (5.61/SMI-4.1) id AA23896; Wed, 5 May 93 14:53:51 +0200 Received: by sony.craynet.dk (4.0/SMI-4.1) id AA17379; Wed, 5 May 93 13:53:44 +0100 From: kbe@sony.craynet.dk (Kjeld Borch Egevang) Message-Id: <9305051253.AA17379@sony.craynet.dk> Subject: help To: big-internet@munnari.oz.au Date: Wed, 5 May 1993 13:53:43 +0100 (WET DST) Organization: Cray Networks A/S - Denmark X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1 X-Charset: ASCII X-Char-Esc: 29 From owner-Big-Internet@munnari.oz.au Thu May 6 03:04:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06960; Thu, 6 May 1993 03:04:51 +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 AA06952; Thu, 6 May 1993 03:04:38 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA15244; Wed, 5 May 93 13:06:13 -0400 Date: Wed, 5 May 93 13:06:13 -0400 Message-Id: <9305051706.AA15244@worldlink.worldlink.com> From: David M. Piscitello To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: big-internet@munnari.oz.au Subject: clarification Hey, folks, let's not dump on Stev as the fall guy for this statement, and let's get the record straight. I was equally mortified at the direction the conversation was taking precisely because (as some mail long deleted so aptly indicated) that we were suggesting a change based on a single network technology rather than looking at this problem and how it affected or might affect IP networking in general. (Stev, this is a tardy acknowledgement of your mention that "the other Internet AD"--a.k.a. bastard #2, and of course, a title I'll long cherish, "IP bigot"-- agreed) Let's examine the issue in the broad context, and fix the architecture if it is indeed broken. From owner-big-internet@munnari.oz.au Thu May 6 07:16:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16627; Thu, 6 May 1993 07:16:59 +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 AA09927; Thu, 6 May 1993 04:28:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08692; Wed, 5 May 93 14:28:43 -0400 Date: Wed, 5 May 93 14:28:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9305051828.AA08692@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu From: stev@ftp.com (stev knowles) the IAB is the group responsible for the purity of the IP protocol suite. any RFC that violates this that is submitted to the Internet Area *must* get signoff from the IAB. Sigh, I don't think the IAB has an eternal veto on changes the IETF wants, but I don't want to re-run Ethernet_MIB/Kobe_IPv7/etc. Let's just take the path of least uproar, and involve them early then. > I 've felt for a while that we should change the host IP layer so that > it no longer includes the "mask and match" test to route outgoing > packets. Rather, I'd rather see the hosts rely *entirely* on the routers > to know where things are. I.e., whenever you go to send packets to an IP > destination which is not in the cache on the host, it sends the packet > to one of the routers which it can reach directly. The router will then > reply (if necessary) with a redirect packet. This would allow us to hide > a migration from the "strict" model to the "loose" model in the routers. is this "nimrod"? Not really (and I'm speaking here of getting rid of the "match and mask" test in the hosts). The name 'Nimrod' covers several distinct things, including a) a routing architecture, and b) a *particular* deployment plan for a) in the context of IPv4 which reinterprets the 32-bit fields in IP packets as EID's. That particuular deployment plan would be marginally more pleasant with this change, but it's not necessary. > What does the IESG say? A new WG to write this RFC, or should IPLPDN do > it? where did IPLPDN come into it? ATM is the one interested currently. i could see a new WG, but the IAB will have something to say about the charter (as is allowed in the "new world order(tm)". Oh, sorry, I was slightly confused. I was thinking of the "Directed ARP" document (RFC1433) which does pretty much the same thing, and that document came from the IPLPDN group. That document makes a change to the way routing is done in the host IP layer, just doesn't call it out explicitly as a change to the basic IP architeture. (The actual mechanism in that document I'm not too thrilled about, since I think it mixes together inter-network->local-network address resolution and inter-network level packet routing a little too tightly, at least if I understood it correctly, but that's a different debate.) I think perhaps a new WG is the right thing; that way the charter can be tightly drawn to handle just i) whether to change what the architectural model of what an IP (sub)network says about the addresses which are part of that (sub)network, and ii) how that would affect the host routing. Once that is done, the WG can be rechartered (or a new one formed, or IPLPDN can be told to do it) to consider what actual mechanism to use to get the needed info to the host. From: David M. Piscitello we were suggesting a change based on a single network technology rather than looking at this problem and how it affected or might affect IP networking in general. ... Let's examine the issue in the broad context, and fix the architecture if it is indeed broken. Well, that was to some degree the whole concept of IPLPDN, to examine generic WAN issues like address resolution and provide mechanisms which could (within the limits of practicality) be used across them all. For a number of reasons (and I have to take part of the blame here, for not starting all the needed 'IP over ' groups) IPLPDN never focused in on this. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) I must be missing something. Besides IS-ES and maybe nimrod [sic], isn't this "router discovery" of blessed status, as evidenced by an holy RFC? For that matter, how does this differ from the ancient "default static route" beloved by system administrators the world around? Neither RD nor DSR proposes getting rid of the step that says (in effect) "check to see if the destination is on the local network, and in that case *only* send it directly to the destination". There is no individual step which does this, but the treatment of incoming ICMP Redirects in Host Requirements (RFC1122) - "A Redirect message SHOULD be silently discarded if the new gateway address it specifies is not on the same connected (sub-)net through which the Redirect arrived ..., or if the source of the Redirect is not the current first-hop gateway for the specified destination" - together with the outbound packet routing algorithm - "If the destination is on a connected network, the datagram is sent directly to the destination host; otherwise, it has to be routed to a gateway on a connected network. ... To decide if the destination is on a connected network, the following algorithm MUST be used..." - effectively make this the current standard. Noel From owner-Big-Internet@munnari.oz.au Fri May 7 01:33:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29786; Fri, 7 May 1993 01:33:49 +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 AA29783; Fri, 7 May 1993 01:33:43 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA01753; Thu, 6 May 93 06:41:27 -0400 Date: Thu, 6 May 93 06:41:27 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9305061041.AA01753@er.doe.gov> To: big-internet@munnari.oz.au, hugh@csis.dit.csiro.au From hughf@csis.dit.csiro.au Mon May 3 01:17:19 1993 Received: from algol.csis.dit.csiro.au by lynx (4.1/1.4S) id AA18716; Mon, 3 May 93 15:21:26 EST Received: by algol.csis.dit.csiro.au (4.1/1.3C) id AA23489; Mon, 3 May 93 15:21:24 EST From: hughf@csis.dit.csiro.au Message-Id: <9305030521.AA23489@algol.csis.dit.csiro.au> Subject: Re: EIDs for app programmers To: hitchcoc@oerv01.er.doe.gov Date: Mon, 3 May 93 15:21:23 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[ X-Mailer: ELM [version 2.3 PL11] Status: RO You wrote on 27 April: >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. ... Your concept of an EID seems much more practical than what I've been reading on the list lately. My perspective is that of an application programmer and Unix system administrator rather than a networking guru. Currently I tend to regard IP addresses as EIDs: they uniquely identify a host, and at least 95% of the time a host will have only one address. To clear up my confusion about the "semantics of EIDs", could you answer these questions with respect to your idea of how they would work? Just yes or no would do fine if you don't want to repeat earlier discussions - I can dig those out. Would EIDs be assigned dynamically when a session/connection (Telnet, AFS link, socket) is opened? Or would they be relatively permanent as are IP addresses? Would a sysadmin below the level of a campus/building network administrator need to use addresses in addition to EIDs - to install a newly purchased host? - for simple troubleshooting? (ie ping) address binding might get fouled up you would probably need to sometimes use the address too.> Would EIDs replace IP addresses in the DNS - for application routines such as gethostbyname? - for nslookup and similar 'domain browsing' tools? Would mapping from EID to domain name - be possible, but slow? - be fast enough for frequent use? Would reverse mappping from network address to EID - be possible, but slow? - be fast enough for frequent use? I understand that EIDs would allow the network topology outside the local subnet to be changed without affecting "live" connections. < I think this is major point of attractiveness> Would EIDs also allow portable hosts to be shut down, moved, and reattached to a different network? Would EIDs also allow mobile hosts to move around on the local subnet without connections being disrupted? Oh, a comment on assignment: if end host installers have to be responsible for two sets of unique numbers, I suspect the scheme isn't going to work. The easiest and most reliable way to get unique EIDs will be to use the network address or some derivation of. It will work wonderfully until the service provider changes and your old numbers get assigned to someone new. Hugh Fisher From owner-big-internet@munnari.oz.au Fri May 7 03:50:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05657; Fri, 7 May 1993 03:50: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 AA23649; Thu, 6 May 1993 23:22:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27980; Thu, 6 May 93 09:22:25 -0400 Date: Thu, 6 May 93 09:22:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9305061322.AA27980@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, lixia@parc.xerox.com Subject: Re: EID lookups Cc: big-Internet@munnari.oz.au From: Lixia Zhang > My model is that you wouldn't often ... 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. Noel, enlighten me a bit more on this one: say we use EID for mobile host support, when I want to send to a mobile host and I know its EID, shouldn't this lookup of (EID -> current adrress) be fast? (no matter what transaction you use, ICMP or whatever). Hmm, we aren't communicating; I thought my paragraph above was a possible answer, but clearly not. Let me try this again. You are trying to communicate with a mobile host. In what circumstances would you have the EID of the endpoint for that mobile host, and nothing else? As far as I can see, in communicating with a mobile host, you either a) have an open connection or b) do not. In the former circumstance, the mobile host knows you are there, and when it moves, it will advise you (via an ICMP 'new address for endpoint' message or a base station, or some other easily imagined mechanism) that the endpoint has moved to a new address. In the latter I imagine you'd have a DNS name; when you look that up, you get back both the EID of the endpoint, and the address the endpoint is currently at. (I don't know of too many people or applications which go around using IP addresses instead of DNS names now. I'm darned if I know the IP address of *anything* I currently use... I mean, I know ginger is 18.something, but that's about it.) Do I recall discussions about using EIDs for security purpose, or for accounting purpose? both would need authentication, need to verify whether the supplied EID is a valid one, right? Yes, but exactly the same thing is true of IP addresses. Look, take EID's out of the picture: presumably in the circumstances about which you enquire above in which you would have only had an EID, in the model without EID's you would have only an IP address. How are the problems associated with doing any of the above with EID's any worse than doing them with IP addresses? And if I'm yet to be convinced that everything in the future would be long-lasting flows, I have to worry about doing this sort of lookups for short-lived transfers or datagrams. If you don't believe in flows, that just makes it slightly less useful to have EID's in all packets, since you'd pretty much have to have an address in every packet as well. It doesn't mean that endpoints or EID's are any less useful in all the other ways they are good ideas. yes our SSN system is in a flat space, but one cannot derive a conclusion that computer EIDs can also live in a flat space. Well, the SSN is not a truly flat space (i.e. they don't hand the numbers out randomly). There is structure there (I'm not positive of what it all is, but I think some of it is related to which office you get your SSN from), but it is not visible to most *users* of the SSN. They only care about its *unique*, and to a much lesser degree, *fixed-length* properties. I maintain the same thing will be true of EID's. End-end protocols such as TCP *won't care* about how we allocate EID's, or look them up if and when we need to; they will simply care that they are unique and of a shortish, fixed length, and identify the endpoint no matter where it is, which interface you get to it through, etc, etc. So, how could I not demand a fast EID lookup speed? Again, I'm trying to see in what *common* circumstances you'd have *only* an EID, and need to do a fast lookup of something else associated with it. (If it's not common, it won't kill us if it's not fast, right?) I maintain that we should, and can easily, engineer things in the complete system so that anytime you need something *other* than the EID, it's already there. From: tracym@nsd.3com.com Is it really an all or nothing issue? Why must ALL lookups be fast? ... I expect that the actual lookup will normally only be slow once in a while, usually when I want to reach a host with whom I haven't conversed in a while. Having looked up the EID in the recent past, either I or the directory service I'm using should be able to optimize following lookups for the same EID... Another good point. I can imagine a flat space working. I can also imagine the utility of 64-bit EID's with some structure, but I think that the main purpose of the structure should be to support allocation mechanisms that would guarantee uniqueness. Exactly. Noel From owner-big-internet@munnari.oz.au Fri May 7 04:18:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06598; Fri, 7 May 1993 04:18:42 +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 AA26733; Fri, 7 May 1993 00:32:02 +1000 (from jmh@anubis.network.com) Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA24534; Thu, 6 May 93 09:34:23 -0500 Received: from petunia.network.com by anubis.network.com (4.1/SMI-4.1) id AA11461; Thu, 6 May 93 09:30:58 CDT Date: Thu, 6 May 93 09:30:58 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9305061430.AA11461@anubis.network.com> To: atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us Subject: A Proposal for consideration In the course of the ongoing work in the IP over Large Public Data Networks (IPLPDN) working group and the IP over ATM (IP/ATM) working group, certain needs have become clear. In particular, there are two coupled problems of wide applicability which need to be addressed. 1) It is taken as a given that large switched virtual circuit networks will exist. These may be Frame Relay, ATM, a combination of both, or even X.25. In these networks, it is envisioned that the economics will be such that there is a significant advantage if two entities (routers or end stations) attached to the switched fabric can communicate directly. Most analysis shows advantages in cost, performance, and resource usage. However, in such a large network, it is neither feasible nor desirable to insist that there be one common network number for everyone. Therefore, to permit this mode of operation, it is necessary to permit direct communication between peer IP entities which do not have a common network number. Rather than blithely permitting this and going on our way, it is recommended that sufficient time and energy be spent exploring the implications of this, so as to satisfy all interested participants that the problem has been addressed properly. Among the demonstrations that some work is needed is that fact that address resolution in such a network bears a striking similarity to proxy ARP. While proxy ARP is widely used, it is also widely known as somewhat dangerous. Therefore, we must address how the address resultion will tie in with routing (see item 2 below) so as to avoid the pitfalls that have been found. 2) Given such a large switched virtual fabric, there is the open question of how, in a logical and protocol sense, routing should be performed. Our current model assumes that two routers who can exchange data will be exchanging routing protocol. Obviously, every router in a large topology can not peer with every other router. Nor can we treat the entire network as one lan, and use a single designated router. Note that the problem being addressed here is the IP routing one, not the VC Routing. That is the question to be asked is, given a host/router on the switched network, and a destination IP address, how will the host/router pick a peer over the switched network to establish a circuit with, for this traffic. This is distinct from the VC routing problem of what path the circuit should take within the cloud. There are some approaches available to this problem, but they need refinement and analysis. Can BGP servers use BGP next hop information to handle this? Can IDRP work similarly? How can we facilitate end-points which have a lower connectivity requirement, and do not wish to buffer the entire topology description? Clearly, the routing work here, the address resolution, and the architectural changes to enhance direct communication are closely related. These items should be considered as either a focussed topic for an existing working group, or as the agenda for a new working group (in which case this proposal could be redrafted into the form of a proposed charter with deliverables identified). From owner-Big-Internet@munnari.oz.au Fri May 7 05:42:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09530; Fri, 7 May 1993 05:43:04 +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 AA09519; Fri, 7 May 1993 05:42:48 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA28394; Thu, 6 May 93 12:42:39 -0700 Message-Id: <9305061942.AA28394@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: lixia@parc.xerox.com, big-Internet@munnari.oz.au Subject: Re: EID lookups Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 06 May 93 09:22:25 -0400. <9305061322.AA27980@ginger.lcs.mit.edu> Date: Thu, 06 May 93 12:42:38 -0700 From: Dave Crocker X-Mts: smtp Noel, et al, Small point: Social Security Numbers are not unique. Collisions occasionally happen. d/ From owner-Big-Internet@munnari.oz.au Fri May 7 06:09:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10505; Fri, 7 May 1993 06:09:45 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9305062009.10505@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10500; Fri, 7 May 1993 06:09:26 +1000 (from ULLMANN@PROCESS.COM) Date: Thu, 6 May 1993 16:06 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: ipv7@world.std.com Cc: big-internet@munnari.oz.au Subject: Amsterdam WG query Hi, I have been asked to determine more accurately the interest level in a (proposed) WG meeting in Amsterdam for IPv7 (and RAP, initially). Please send me a note if you are planning on attending Amsterdam and are interested in the WG meeting. If you are one of the people already involved in the project, please respond anyway (i.e. don't assume I will count you) because I don't know yet if you are going to the IETF. Following is the DRAFT charter that has been submitted to the Area Directorate. Best Regards, Robert Ullmann Ariel@Process.COM Intl: +1 508 879 2960 x226 in US: (800) 722-7770 x226 ----------------------------------------------------------------------------- Internet Protocol Version 7 (ipv7) Charter Chair: Vladimir Sukonnik Internet Area Directors: Stev Knowles David Piscitello Mailing List: Discussion: ipv7@world.std.com To Subscribe: ipv7-request@world.std.com Archive: world.std.com:/pub/ipv7/... Description of Working Group: Internet Version 7 is a new version of the IP and TCP/UDP protocols, to advance the Internet technology to the scale and performance of the next generation of internetwork technology. The IPv7 project was started in 1988 to speculate on what a new version might look like, as it was becoming clear that version 4 would presently be reaching its limits. The specification (including RAP, TCP extensions, and the AD plan now in separate drafts) was circulated informally in late 1989, and again in 1990 and 1991. It was then issued as an internet-draft in August 1992. The Working Group is chartered to evaluate issues arising during product development and deployment planning, and to document problems and explanations for any parts of the coexistance with IPv4 not covered directly in the IPv7-IPv4 interoperation design. The WG will also be the initial forum for development of the RAP protocol while it is experimental; this work will need to be moved to the Routing Area when it is to be advanced. The WG is also chartered to provide an open industry forum for coordination of commercial deployment plans. Goals and Milestones: Mar 93 (26th IETF) Issue revised internet drafts, plenary presentation. (completed) Apr 93 Issue Experimental RFCs for IPv7 and RAP. (Approved by IESG, sent to RFC editor) Jun 93 Start of RAP deployment. Jul 93 (27th IETF, first WG meeting) Discuss additional definitions needed, e.g. TCP SACK and TS options, LSRR and others for IP layer. Possible AD allocation plan. Report on ongoing experimentation. Either recommend to IESG that IPv7 be advanced to Proposed Standard, or determine detailed criteria to be met prior to recommendation. Nov 93 (28th IETF) Preliminary vendor deployment coordination. Review advancement criteria, make recommendation to IESG. Revised I-Ds for options and planning due prior to IETF. Review status and WG assignment of RAP protocol. Jan 94 Start of IPv7 deployment. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------ Aug 92 Mar 93 TCP/IP: Internet Version 7 Feb 93 Mar 93 RAP: Route Access Protocol From owner-big-internet@munnari.oz.au Fri May 7 09:43:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19086; Fri, 7 May 1993 09:43:36 +1000 (from owner-big-internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16647; Fri, 7 May 1993 08:36:54 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Thu, 6 May 1993 15:36:46 -0700 Date: Thu, 6 May 1993 15:36:46 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199305062236.AA09340@zephyr.isi.edu> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@cnri.reston.va.us *> *> - together with the outbound packet routing algorithm - *> *> "If the destination is on a connected network, the datagram is sent *> directly to the destination host; otherwise, it has to be routed to a *> gateway on a connected network. ... To decide if the destination is on a *> connected network, the following algorithm MUST be used..." *> *> - effectively make this the current standard. *> *> *> Noel *> *> Yes, RFC-1122 did intend to mandate the mask-and-match algorithm, which was considered part of the current architecture. I agree that it is appropriate to reconsider this requirement. Bob Braden From owner-Big-Internet@munnari.oz.au Fri May 7 10:55:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22577; Fri, 7 May 1993 10:55:18 +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 AA22558; Fri, 7 May 1993 10:55:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15191; Thu, 6 May 93 20:55:00 -0400 Date: Thu, 6 May 93 20:55:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9305070055.AA15191@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, braden@isi.edu, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu Yes, RFC-1122 did intend to mandate the mask-and-match algorithm, which was considered part of the current architecture. I agree that it is appropriate to reconsider this requirement. Mmmm, any guesses on what the attitude of the IAB as a whole would be? You want to ask at their next telecon? Noel From owner-Big-Internet@munnari.oz.au Fri May 7 12:36:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26764; Fri, 7 May 1993 12:36:28 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA26756; Fri, 7 May 1993 12:36:16 +1000 (from myron@ktxc3.kentrox.com) Received: from kentrox (via kentrox.kentrox.com) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25204; Thu, 6 May 93 22:28:06 -0400 Received: from ktxc3.ktxnet by kentrox (4.1/SMI-4.1) id AA10189; Thu, 6 May 93 09:47:55 PDT Received: by ktxc3.ktxnet (4.1/SMI-4.1) id AA04284; Thu, 6 May 93 09:47:53 PDT Date: Thu, 6 May 93 09:47:53 PDT From: myron@ktxc3.kentrox.com (Myron Hattig) Message-Id: <9305061647.AA04284@ktxc3.ktxnet> To: big-internet@munnari.oz.au Subject: information Hello, Could someone please give me information about this list (big-internet@munnari.oz.au) including some combination of the purpose of the list, FAQs, and the administrative address. Thank you, Myron Hattig - myron@kentrox.com From owner-Big-Internet@munnari.oz.au Fri May 7 18:35:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12881; Fri, 7 May 1993 18: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 AA12876; Fri, 7 May 1993 18:35:36 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26258; Fri, 7 May 1993 10:35:21 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA21810; Fri, 7 May 1993 10:35:18 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9305070835.AA21810@dxcern.cern.ch> Subject: Re: A Proposal for consideration To: jmh@anubis.network.com (Joel Halpern) Date: Fri, 7 May 1993 10:35:18 +0200 (MET DST) Cc: atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us In-Reply-To: <9305061430.AA11461@anubis.network.com> from "Joel Halpern" at May 6, 93 09:30:58 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 643 Joel, You ask where we should discuss 2 questions, how are IP addresses resolved to physical addresses in a switched network (a network in which the classical catenet model does not apply), and how is IP routing information exchanged in such a network. This problem is not limited to ATM so it seems to me that iplpdn is the right place. Maybe Juha's NBMA ARP should move to iplpdn? I think there is a third question, how can we move to the use of an individual switched circuit per transaction (TONIC, TCP over nonexistent IP connection). 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 Fri May 7 23:25:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23517; Fri, 7 May 1993 23:26:39 +1000 (from owner-Big-Internet) Return-Path: Received: from NR-TECH.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23474; Fri, 7 May 1993 23:25:26 +1000 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB28006; Fri, 7 May 93 09:24:31 EDT Message-Id: <9305071324.AB28006@mitchell.cit.cornell.edu> Date: Fri, 7 May 1993 09:24:56 -0500 To: brian@dxcern.cern.ch (Brian Carpenter CERN-CN), jmh@anubis.network.com (Joel Halpern) From: Scott_Brim@cornell.edu X-Sender: swb@132.236.199.25 (Unverified) Subject: Re: A Proposal for consideration Cc: atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us On the other hand every working group and every person has its own style, its own focus, and ironically things often get done faster in multiple meetings (with information exchange between them) than they would in one big meeting. These are complex issues, and based on past observation I think the individual working groups should keep their own identities even if their discussions overlap a lot. You need occasional joint meetings, and frequent communication between the chairpersons, but I don't think any topic should be limited a priori to just one WG. IETFers just don't work that way. Scott At 10:35 AM 5/7/93 +0200, Brian Carpenter CERN-CN wrote: >Joel, > >You ask where we should discuss 2 questions, how are IP addresses >resolved to physical addresses in a switched network (a network >in which the classical catenet model does not apply), and how is >IP routing information exchanged in such a network. > >This problem is not limited to ATM so it seems to me >that iplpdn is the right place. Maybe Juha's NBMA ARP should >move to iplpdn? > >I think there is a third question, how can we move to the use >of an individual switched circuit per transaction >(TONIC, TCP over nonexistent IP connection). > >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 Sat May 8 00:34:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26645; Sat, 8 May 1993 00:34:40 +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 AA26640; Sat, 8 May 1993 00:34:27 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18812; Fri, 7 May 1993 16:34:09 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA26762; Fri, 7 May 1993 16:34:05 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9305071434.AA26762@dxcern.cern.ch> Subject: Re: A Proposal for consideration To: Scott_Brim@cornell.edu Date: Fri, 7 May 1993 16:34:05 +0200 (MET DST) Cc: jmh@anubis.network.com, atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us In-Reply-To: <9305071324.AB28006@mitchell.cit.cornell.edu> from "Scott_Brim@cornell.edu" at May 7, 93 09:24:56 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1768 It occurs to me that a focussed joint meeting of atm and iplpdn at Amsterdam might lead to a conclusion on where to handle this. It's very kind of Joel to volunteer to write a draft paper :-) Brian >--------- Text sent by Scott_Brim@cornell.edu follows: > > On the other hand every working group and every person has its own style, > its own focus, and ironically things often get done faster in multiple > meetings (with information exchange between them) than they would in one > big meeting. These are complex issues, and based on past observation I > think the individual working groups should keep their own identities even > if their discussions overlap a lot. You need occasional joint meetings, > and frequent communication between the chairpersons, but I don't think any > topic should be limited a priori to just one WG. IETFers just don't work > that way. > Scott > > At 10:35 AM 5/7/93 +0200, Brian Carpenter CERN-CN wrote: > >Joel, > > > >You ask where we should discuss 2 questions, how are IP addresses > >resolved to physical addresses in a switched network (a network > >in which the classical catenet model does not apply), and how is > >IP routing information exchanged in such a network. > > > >This problem is not limited to ATM so it seems to me > >that iplpdn is the right place. Maybe Juha's NBMA ARP should > >move to iplpdn? > > > >I think there is a third question, how can we move to the use > >of an individual switched circuit per transaction > >(TONIC, TCP over nonexistent IP connection). > > > >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 Sat May 8 00:38:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26867; Sat, 8 May 1993 00:39:03 +1000 (from owner-Big-Internet) Return-Path: Received: from NR-TECH.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26861; Sat, 8 May 1993 00:38:51 +1000 (from Scott_Brim@cornell.edu) Received: from [132.236.199.71] (SLUF.CIT.CORNELL.EDU) by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA01407; Fri, 7 May 93 10:37:36 EDT Message-Id: <9305071437.AA01407@mitchell.cit.cornell.edu> Date: Fri, 7 May 1993 10:38:43 -0500 To: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) From: Scott_Brim@cornell.edu X-Sender: swb@132.236.199.25 Subject: Re: A Proposal for consideration Cc: jmh@anubis.network.com, atm@eng.sun.com, big-internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us Great idea. See you there. At 10:34 AM 5/7/93 -0400, Brian Carpenter CERN-CN wrote: >It occurs to me that a focussed joint meeting of atm and iplpdn >at Amsterdam might lead to a conclusion on where to handle this. >It's very kind of Joel to volunteer to write a draft paper :-) From owner-Big-Internet@munnari.oz.au Sat May 8 02:59:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03143; Sat, 8 May 1993 02:59:28 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03140; Sat, 8 May 1993 02:59:19 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-10) id ; Fri, 7 May 1993 09:59:14 -0700 Date: Fri, 7 May 1993 09:59:14 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199305071659.AA22112@zephyr.isi.edu> To: big-internet@munnari.oz.au, braden@ISI.EDU, jnc@ginger.lcs.mit.edu Subject: Re: expansion on my note about IPv7 and EID Cc: iesg@cnri.reston.va.us *> From jnc@ginger.lcs.mit.edu Thu May 6 17:55:26 1993 *> Date: Thu, 6 May 93 20:55:00 -0400 *> From: jnc@ginger.lcs.mit.edu (Noel Chiappa) *> To: big-internet@munnari.oz.au, braden@ISI.EDU, jnc@ginger.lcs.mit.edu *> Subject: Re: expansion on my note about IPv7 and EID *> Cc: iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu *> Content-Length: 314 *> X-Lines: 8 *> *> Yes, RFC-1122 did intend to mandate the mask-and-match algorithm, which *> was considered part of the current architecture. *> I agree that it is appropriate to reconsider this requirement. *> *> Mmmm, any guesses on what the attitude of the IAB as a whole would be? You *> want to ask at their next telecon? *> *> Noel *> As a matter of fact, Noel, it has already been brought up in the IAB, by Yakov Rekhter. There was no disagreement with the view I expressed above, and Yakov, John Romkey, and I took an action to write down something about it. Bob From owner-big-internet@munnari.oz.au Tue May 11 13:53:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29012; Tue, 11 May 1993 13:53:52 +1000 (from owner-big-internet) Return-Path: Message-Id: <9305110353.29012@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24992; Tue, 11 May 1993 12:27:03 +1000 (from ULLMANN@PROCESS.COM) Date: Mon, 10 May 1993 22:26 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: just when you thought it was safe to go outside ... Hi, At the request of Stev Knowles, AD for the Internet area, the name of the IPv7 project has been changed to TP/IX. This was an old acronym for the project (one tributary of it), that hasn't been used in several years; but will serve. The mail-list and archive names will stay the same for the moment; watch for announcements. I apologize for any confusion this may cause. If you need a press contact, please refer them to me. With My Best Regards, Robert Ullmann From owner-Big-Internet@munnari.oz.au Tue May 25 03:28:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11816; Tue, 25 May 1993 03:28:44 +1000 (from owner-Big-Internet) Return-Path: Received: from dkuug.dk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11755; Tue, 25 May 1993 03:28:12 +1000 (from kbe@sony.craynet.dk) Received: from mips.uucp by dkuug.dk with UUCP id AA21056 (5.65c8/IDA-1.4.4j for Big-Internet@munnari.OZ.AU); Mon, 24 May 1993 19:27:51 +0200 Received: from sony by craynet.dk (5.61/SMI-4.1) id AA12596; Mon, 24 May 93 20:26:18 +0200 Received: by sony.craynet.dk (4.0/SMI-4.1) id AA23179; Mon, 24 May 93 19:26:17 +0100 From: kbe@sony.craynet.dk (Kjeld Borch Egevang) Message-Id: <9305241826.AA23179@sony.craynet.dk> Subject: experimental network To: Big-Internet@munnari.OZ.AU (Big-Internet mailing list) Date: Mon, 24 May 1993 19:26:16 +0100 (WET DST) Organization: Cray Networks A/S - Denmark X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 289 X-Charset: ASCII X-Char-Esc: 29 I believe I read somewhere that 89.0.0.0 was reserved as an experimental network. Can anybody confirm this? -- Kjeld Borch Egevang kbe@craynet.dk Research & Development Voice: +45 44530100 Cray Networks A/S - Denmark Fax: +45 44531415 From owner-Big-Internet@munnari.oz.au Tue May 25 06:46:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18365; Tue, 25 May 1993 06:47:06 +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 AA18360; Tue, 25 May 1993 06:46:58 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA02032); Mon, 24 May 93 15:46:52 CDT Received: by sabine.is.rice.edu (AA01711); Mon, 24 May 93 15:46:51 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9305242046.AA01711@sabine.is.rice.edu> Subject: Re: experimental network To: kbe@sony.craynet.dk (Kjeld Borch Egevang) Date: Mon, 24 May 93 15:46:50 CDT Cc: Big-Internet@munnari.oz.au In-Reply-To: <9305241826.AA23179@sony.craynet.dk>; from "Kjeld Borch Egevang" at May 24, 93 7:26 pm X-Mailer: ELM [version 2.3 PL11] Kjeld Borch Egevang > > I believe I read somewhere that 89.0.0.0 was reserved as an experimental > network. Can anybody confirm this? > Don't know for sure about that one. 192.0.2.0 has been reserved for that purpose by IANA though. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Thu May 27 07:16:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02124; Thu, 27 May 1993 07:16:53 +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 AA02115; Thu, 27 May 1993 07:16:36 +1000 (from news@freenet.carleton.ca) Received: from freenet.carleton.ca by ux1.cso.uiuc.edu with SMTP id AA23697 (5.67a8/IDA-1.5 for ); Wed, 26 May 1993 16:16:12 -0500 Received: by freenet.carleton.ca (4.1/SMI-4.0) id AA03463; Wed, 26 May 93 17:15:49 EDT Newsgroups: info.big-internet Path: Freenet.carleton.ca!aa158 From: aa158@freenet.carleton.ca (Les Casey) Subject: Bombing Run Message-Id: Sender: news@freenet.carleton.ca (News Administrator) Organization: National Capital Freenet, Ottawa, Canada Date: Wed, 26 May 1993 21:15:44 GMT Lines: 12 Apparently-To: info-big-internet@ux1.cso.uiuc.edu Problem: I have a mailing list of approx. 30 people that I wish to send email to, but not let each person know who else is on my list. Presently, I use the "cc:" feature, but this lists all of the others who receive the same email message. I think the feature I am looking for is called a "bombing run". Any suggestions? -- y From owner-big-internet@munnari.oz.au Thu May 27 11:35:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15438; Thu, 27 May 1993 11:35:49 +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 AA03375; Thu, 27 May 1993 07:38:56 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA25234; Wed, 26 May 93 14:38:50 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA24281 for Big-Internet@munnari.OZ.AU; Wed, 26 May 93 17:39:57 -0400 Message-Id: <9305262139.AA24281@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: kbe@sony.craynet.dk (Kjeld Borch Egevang) Cc: Big-Internet@munnari.OZ.AU (Big-Internet mailing list) Subject: Re: experimental network In-Reply-To: Your message of "Mon, 24 May 93 19:26:16 BST." <9305241826.AA23179@sony.craynet.dk> Date: Wed, 26 May 93 17:39:57 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: kbe@sony.craynet.dk (Kjeld Borch Egevang) To: Big-Internet@munnari.OZ.AU (Big-Internet mailing list) Organization: Cray Networks A/S - Denmark >I believe I read somewhere that 89.0.0.0 was reserved as an experimental >network. Can anybody confirm this? 192.0.2.* is assigned for experimental use only and in general routers (unless they are involved in the experiment) are justified is dropping any packed addressed to that net. The last domain name survey found the following hosts in 89.*.*.*: 89.0.0.1 tgateway.nat.com 89.0.0.111 brg1.nat.com 89.0.0.112 brg2.nat.com 89.0.0.125 mtr5.nat.com 89.0.0.157 rb9d.nat.com 89.0.0.209 mtr.nat.com 89.0.0.209 rarpmtr.nat.com 89.0.0.219 natbrg.nat.com 89.0.0.220 engsvrbrg.nat.com 89.0.0.221 nat0.nat.com 89.0.0.224 mtr1.nat.com 89.0.0.226 mtr2.nat.com 89.0.0.227 mtr3.nat.com 89.0.0.228 colmtr.nat.com 89.0.0.233 mtr4.nat.com 89.0.0.240 rbf0.nat.com 89.0.0.251 brg.nat.com 89.0.0.252 trbg1.nat.com 89.0.0.3 tmpbrg.nat.com 89.0.0.44 opus.as.utexas.edu 89.0.0.49 engmtr.nat.com 89.0.0.67 rb43.nat.com 89.0.0.69 rb45.nat.com 89.0.0.70 rb46.nat.com 89.0.1.100 mtr164.nat.com 89.0.1.100 natmeter.nat.com 89.0.1.101 aphpa150.nat.com 89.0.1.110 tstmtr.nat.com 89.0.1.43 rb12b.nat.com 89.0.1.72 rb148.nat.com 89.0.13.111 dupbrg.nat.com 89.0.2.1 ice250.nat.com 89.0.2.2 rand.nat.com 89.0.255.255 tmpnode.nat.com 89.0.3.250 engsalebrg.nat.com 89.0.4.25 bbb.nat.com 89.0.4.25 lobrg.nat.com 89.0.5.209 mmtr.nat.com 89.0.83.111 dupmtr.nat.com 89.0.85.95 natrt.nat.com 89.0.9.12 capture.nat.com 89.1.4.1 b250.nat.com 89.111.0.40 rmeng.nat.com 89.111.12.20 c3po.nat.com 89.111.22.22 jedi.nat.com 89.144.0.232 rmeter1.nat.com 89.144.0.99 remotemtr.nat.com 89.16.32.53 austin.practic.com 89.160.1.30 mtr109.nat.com 89.168.0.131 alpha250.nat.com 89.168.0.181 b155.nat.com 89.168.0.221 alpha155.nat.com 89.168.0.34 v230x.nat.com 89.22.33.44 tbrg2.nat.com 89.254.254.1 rt.nat.com 89.254.254.2 rt2.nat.com 89.3.10.7 ilc250.nat.com 89.7.254.1 henry.nat.com 89.7.254.10 simon.nat.com 89.7.254.11 mitchell.nat.com 89.7.254.12 phil.nat.com 89.7.254.13 ldyer.nat.com 89.7.254.14 cheng.nat.com 89.7.254.15 shu.nat.com 89.7.254.16 bille.nat.com 89.7.254.17 jimh.nat.com 89.7.254.18 dicks.nat.com 89.7.254.19 test1.nat.com 89.7.254.2 yang.nat.com 89.7.254.20 test2.nat.com 89.7.254.21 test3.nat.com 89.7.254.22 test4.nat.com 89.7.254.23 ram.nat.com 89.7.254.25 jeffc.nat.com 89.7.254.250 mftlab.nat.com 89.7.254.254 d135.nat.com 89.7.254.26 ernie.nat.com 89.7.254.27 celeste.nat.com 89.7.254.28 cindy.nat.com 89.7.254.29 jennifer.nat.com 89.7.254.3 david.nat.com 89.7.254.30 ashan.nat.com 89.7.254.31 toshiko.nat.com 89.7.254.32 audrey.nat.com 89.7.254.33 davidl.nat.com 89.7.254.34 holly.nat.com 89.7.254.35 jean.nat.com 89.7.254.36 mike.nat.com 89.7.254.37 janique.nat.com 89.7.254.38 bon.nat.com 89.7.254.39 doris.nat.com 89.7.254.4 ycw.nat.com 89.7.254.40 susan.nat.com 89.7.254.41 harvey.nat.com 89.7.254.42 billp.nat.com 89.7.254.43 billc.nat.com 89.7.254.44 homer.nat.com 89.7.254.46 lissu.nat.com 89.7.254.5 maurice.nat.com 89.7.254.6 hanna.nat.com 89.7.254.7 honda.nat.com 89.7.254.8 jane.nat.com 89.7.254.9 constance.nat.com 89.7.7.7 i960.nat.com 89.7.8.9 apollo.nat.com >-- >Kjeld Borch Egevang kbe@craynet.dk >Research & Development Voice: +45 44530100 >Cray Networks A/S - Denmark Fax: +45 44531415 Donald From owner-Big-Internet@munnari.oz.au Thu May 27 12:27:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17771; Thu, 27 May 1993 12:27:49 +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 AA17766; Thu, 27 May 1993 12:27:27 +1000 (from ariel@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA25599; Wed, 26 May 1993 22:27:21 -0400 Date: Wed, 26 May 1993 22:27:21 -0400 From: ariel@world.std.com (Robert L Ullmann) Message-Id: <199305270227.AA25599@world.std.com> To: big-internet@munnari.oz.au, staff@world.std.com Hi, As I said previously, the IPv7 project is now named TP/IX, its original name 5 years ago. (pronounced TEE-PICKS, in case that wasn't obvious :-) The mail list is now: tpix@world.std.com to subscribe, send to tpix-request@world.std.com The ipv7 address still works, but not ipv7-request or owner-ipv7. The archive is world.std.com:/pub/tpix/... and, of course, the ipv7 path still works. The TP/IX working group charter is on the IESG agenda, awaiting a final decision. If you have any items for the Amsterdam agenda, please send a note to me or the tpix list. Aside: in case you are wondering why the list and archive are based on World, and not some system at Process Software; the answer is real simple: World is an AWESOME service provider, and it is both easier and more cost-effective to use it than to do it ourselves. (Yes, you read that right: MORE CHEAPER.) This shows, BTW, that commercial networking is coming into its own; it ought to be less expensive to buy services than to do them yourselves. After all, we rent green plants, and pay people to vacuum the carpets; why not pay someone to run anon-FTP and mail on a 24x7 basis? It is MUCH more cost effective than having anyone on staff at Process have to spend time on it. (But just watch: STD will raise my rates now ... ;-) Of course, this is just dissembling (though true); the real reason is that most people read world.std.com as World Standard (for) Computing. (STD = "Software Tool & Die") Best Regards, Robert From owner-Big-Internet@munnari.oz.au Thu May 27 16:27:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28606; Thu, 27 May 1993 16:28:11 +1000 (from owner-Big-Internet) Return-Path: Received: from oliveb.ATC.Olivetti.Com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28597; Thu, 27 May 1993 16:27:22 +1000 (from roode@arezzo.oas.olivetti.com) Received: by oliveb.ATC.Olivetti.Com (5.65/1.34) id AA14579; Wed, 26 May 93 23:27:02 -0700 Received: by oliveb.ATC.Olivetti.Com (5.51/smail2.5/12-18-87) id AA14576; Wed, 26 May 93 23:26:59 PDT Received: by arezzo.oas.olivetti.com (4.1/SMI-3.2) id AA00877; Wed, 26 May 93 23:26:54 PDT Date: Wed, 26 May 93 23:26:53 BST From: David Roode To: dee@skidrow.ljo.dec.com Cc: kbe@sony.craynet.dk (Kjeld Borch Egevang), Big-Internet@munnari.OZ.AU (Big-Internet mailing list) Subject: Re: experimental network In-Reply-To: Your message of Wed, 26 May 1993 14:39:57 -0700 Message-Id: Interesting, because the Internic network number registry lists class A 89 as being unassigned and reserved: whois -h rs.internic.net 89.0.0.0 IANA (RESERVED-7) Netname: Reserved Netblock: 64.0.0.0 - 95.0.0.0 Coordinator: Reynolds, Joyce K. (JKR1) JKRey@ISI.EDU (310) 822-1511 Record last updated on 03-Apr-92. The InterNIC Registration Services Host ONLY contains Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. From owner-Big-Internet@munnari.oz.au Thu May 27 17:37:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01890; Thu, 27 May 1993 17:37:39 +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 AA01880; Thu, 27 May 1993 17:37:11 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA05233; Thu, 27 May 93 00:36:52 -0700 Date: Thu, 27 May 93 0:36:51 PDT From: Vince Fuller To: David Roode Cc: dee@skidrow.ljo.dec.com, kbe@sony.craynet.dk (Kjeld Borch Egevang), Big-Internet@munnari.OZ.AU (Big-Internet mailing list) Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: experimental network In-Reply-To: Your message of Wed, 26 May 93 23:26:53 BST Message-Id: Interesting, because the Internic network number registry lists class A 89 as being unassigned and reserved: whois -h rs.internic.net 89.0.0.0 IANA (RESERVED-7) Netname: Reserved Netblock: 64.0.0.0 - 95.0.0.0 Look closer - ALL of the class-A's above 63 are reserved. --Vince From owner-Big-Internet@munnari.oz.au Thu May 27 20:16:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08394; Thu, 27 May 1993 20:16:55 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9305271016.8394@munnari.oz.au> Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08390; Thu, 27 May 1993 20:16:44 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (16.8/16.2) id AA07465; Thu, 27 May 93 20:16:40 +1000 From: Darren Reed Subject: Re: experimental network To: big-internet@munnari.oz.au Date: Thu, 27 May 1993 20:16:40 +1000 (EST) In-Reply-To: from "Vince Fuller" at May 27, 93 00:36:51 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: 483 > > Interesting, because the Internic network number registry lists class A > 89 as being unassigned and reserved: > > whois -h rs.internic.net 89.0.0.0 > IANA (RESERVED-7) > > Netname: Reserved > Netblock: 64.0.0.0 - 95.0.0.0 > > Look closer - ALL of the class-A's above 63 are reserved. Does anyone know why this was done ? Other class A's are also reserved.... 10.0.0.0 (old .arpa network) is just one other I have noticed... Darren From owner-Big-Internet@munnari.oz.au Thu May 27 22:43:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13387; Thu, 27 May 1993 22:44:17 +1000 (from owner-Big-Internet) Return-Path: Received: from dkuug.dk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13323; Thu, 27 May 1993 22:43:47 +1000 (from kbe@sony.craynet.dk) Received: from mips.uucp by dkuug.dk with UUCP id AA02780 (5.65c8/IDA-1.4.4j for Big-Internet@munnari.OZ.AU); Thu, 27 May 1993 14:43:22 +0200 Received: from sony by craynet.dk (5.61/SMI-4.1) id AA16896; Thu, 27 May 93 15:41:26 +0200 Received: by sony.craynet.dk (4.0/SMI-4.1) id AA05600; Thu, 27 May 93 14:41:25 +0100 From: kbe@sony.craynet.dk (Kjeld Borch Egevang) Message-Id: <9305271341.AA05600@sony.craynet.dk> Subject: Internet Draft on NAT To: Big-Internet@munnari.OZ.AU (Big-Internet mailing list) Date: Thu, 27 May 1993 14:41:25 +0100 (WET DST) Organization: Cray Networks A/S - Denmark X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2126 X-Charset: ASCII X-Char-Esc: 29 In the January issue of ACM SIGCOMM, Computer Communication Review, Paul Francis (formerly Tsuchiya) and Tony Eng had an article about IP NAT. NAT refers to Network Address Translators, a topic that has been discussed a lot on this mailing-list. It seems NAT has been reinvented several times, so no surprise: I invented it too. I wrote to Paul and asked him if he would put out an RFC. He said he didn't have time and suggested me to do it. I think the idea deserves to get out to more people, so, I've written an Internet Draft, based on Paul's article. You can get it as big-internet/IP-NAT on munnari.OZ.AU [128.250.1.21]. Here's the abstract: "The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses. It is possible that CIDR will not be adequate to maintain the IP internet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons." -- Kjeld Borch Egevang kbe@craynet.dk Research & Development Voice: +45 44530100 Cray Communications A/S - Denmark Fax: +45 44531415 From owner-big-internet@munnari.oz.au Fri May 28 06:40:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01325; Fri, 28 May 1993 06:40:18 +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 AA22696; Fri, 28 May 1993 02:53:47 +1000 (from dee@skidrow.ljo.dec.com) Received: by inet-gw-2.pa.dec.com; id AA00844; Thu, 27 May 93 09:50:13 -0700 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA26795 for big-internet@munnari.oz.au; Thu, 27 May 93 12:51:17 -0400 Message-Id: <9305271651.AA26795@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Darren Reed Cc: big-internet@munnari.oz.au Subject: Re: experimental network In-Reply-To: Your message of "Thu, 27 May 93 20:16:40 +1000." <9305271016.8394@munnari.oz.au> Date: Thu, 27 May 93 12:51:17 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Darren Reed To: big-internet@munnari.oz.au In-Reply-To: from "Vince Fulle r" at May 27, 93 00:36:51 am >> Interesting, because the Internic network number registry lists class A >> 89 as being unassigned and reserved: >> >> whois -h rs.internic.net 89.0.0.0 >> IANA (RESERVED-7) >> >> Netname: Reserved >> Netblock: 64.0.0.0 - 95.0.0.0 >> >> Look closer - ALL of the class-A's above 63 are reserved. > >Does anyone know why this was done ? I remember seeing something from the IAB or IESG saying they were reserving half of the Class A space in case they were needed as a transition resource in connection with the exhaustion of the IP address space. The idea would be that they could be used by some kind of dynamic address translations scheme where IP addresses in that range were temporarily bound to some IPng address. >Other class A's are also reserved.... 10.0.0.0 (old .arpa network) is >just one other I have noticed... > >Darren Donald From owner-Big-Internet@munnari.oz.au Fri May 28 17:24:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27893; Fri, 28 May 1993 17:25:04 +1000 (from owner-Big-Internet) Return-Path: Received: from lux.levels.unisa.edu.au (via mulga) by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA27882; Fri, 28 May 1993 17:24:50 +1000 (from ccdps%lux.levels.unisa.edu.au@lux.levels.unisa.edu.au) Received: by lux.levels.unisa.edu.au (4.1/SMI-4.1) id AA09497 for big-internet@munnari.oz From: ccdps%lux.levels.unisa.edu.au%lux.levels.unisa.edu.au@lux.levels.unisa.edu.au (Dan Shearer) Message-Id: <9302160320.AA09497@lux.levels.unisa.edu.au> Subject: Big Internet To: big-internet@munnari.oz.au Date: Tue, 16 Feb 1993 13:50:26 +1030 (GMT+1030) X-Mailer: ELM [version 2.4 PL6] Content-Type: text Content-Length: 544 After numerous attempts to get off this list with the -request address, I am in desperation posting to the list itself. Please please please please pretty-please remove me. Like the previous poster I am willing to ascribe every possible virtue to the contributers and maintainers of this list, so long as I get off it. :-) Kindest regards, -- Dan Shearer email: Dan.Shearer@UniSA.edu.au Information Technology Branch Phone: +61 8 302 3479 University of South Australia Fax : +61 8 302 3385 From owner-big-internet@munnari.oz.au Fri May 28 21:37:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08236; Fri, 28 May 1993 21:37:52 +1000 (from owner-big-internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20158; Fri, 28 May 1993 14:20:15 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 2474; Fri, 28 May 93 00:19:54 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.10 ptf000) with BSMTP id 0963; Fri, 28 May 93 00:19:53 EDT Date: Fri, 28 May 93 00:16:55 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: experimental network To: Darren Reed Cc: big-internet@munnari.oz.au In-Reply-To: <9305271651.AA26795@skidrow.ljo.dec.com> Message-Id: <930528.001655.EDT.VALDIS@vtvm1.cc.vt.edu> On Thu, 27 May 93 12:51:17 -0400 you said: > Interesting, because the Internic network number registry lists class A > 89 as being unassigned and reserved: > > whois -h rs.internic.net 89.0.0.0 > IANA (RESERVED-7) > > Look closer - ALL of the class-A's above 63 are reserved. Is anybody besides me feeling just a *little* concerned that ZEALOT (or whatever they call the DNS walker) found a bunch of .com nodes in a reserved net? Do you suppose these people are in for a surprise? Or are we for thinking the space is reserved? Are there any *other* "reserved" net with squatters in them? Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Sat May 29 03:23:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22761; Sat, 29 May 1993 03:23:21 +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 AA22756; Sat, 29 May 1993 03:23:04 +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, 28 May 93 13:22:58 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 28 May 93 13:22:56 EDT Date: Fri, 28 May 93 13:22:56 EDT From: francis@thumper.bellcore.com (Paul Francis (formerly Paul Tsuchiya)) Message-Id: <9305281722.AA07959@tsuchiya.bellcore.com> To: big-internet@munnari.oz.au Subject: Re: Internet Draft on NAT I want to mention that the main reason Kjeld and I have put out this draft at this time is not because we propose to replace CIDR, but because Kjeld has implemented it (independent of my previous work....) and so now there is something to play with. I have considered NAT something of last-ditch fix for the case where we don't have an IPng before CIDR crashes. I think Kjeld has more confidence in NAT than that, however, which is interesting since he built it and is running it. Anyway, I think it would be good if we have experience with NAT just in case we *need* to use it, if for no other reason. PX ps. A description from Kjeld on his implementation is attached. ____________ It is not a product (yet), just a little experiment I made when I had some spare time. I implemented it in our remote routers equipped with an R33000 and 4 MByte RAM. The router has 5 slots where you can have several kinds of cards. We have Ethernet, X21, V24, V35, V36 and Token Ring (maybe a few more I haven't worked with). The setup I made looked like this: +---+ V.24 zero-modem cable +---+ |RT1|-----------------------|RT2| +---+ ^ NAT here +---+ | | ============== ============== | 89.0.0.0 | 156.13.0.0 (simulates global net) | | +-+ +-+ +-+ +-+ /___\ PC running FTP /___\ PC running FTPD I translate addresses on the WAN line so I don't have to deal with ARP. If you switch who is running FTP (client) and FTPD (server) you don't have to translate PORT commands.