From owner-big-internet@munnari.oz.au Sun Aug 1 04:33:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21477; Sun, 1 Aug 1993 04:33:51 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307311833.21477@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16458; Sun, 1 Aug 1993 01:37:59 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <04447-0@datanet.tele.fi>; Sat, 31 Jul 1993 18:37:11 +0300 To: bsimpson@morningstar.com Cc: jnc@ginger.lcs.mit.edu, atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com In-Reply-To: <922.bill.simpson@um.cc.umich.edu> Subject: Routing Over Large Clouds Date: Sat, 31 Jul 1993 18:37:11 +0300 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi i oppose delaying any IP developments "before we have picked IPng", since noone knows when that will happen (if ever). we have god knows how many IP hosts out there which will have a long life still ahead of them. -- juha From owner-Big-Internet@munnari.oz.au Mon Aug 2 11:33:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18194; Mon, 2 Aug 1993 11:34:17 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18176; Mon, 2 Aug 1993 11:33:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10400; Sun, 1 Aug 93 21:33:39 -0400 Date: Sun, 1 Aug 93 21:33:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308020133.AA10400@ginger.lcs.mit.edu> To: wollman@uvm-gen.emba.uvm.edu Subject: Re: Variable length addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > If we could simply embed 802 addresses directly, autoconfiguration > of hosts addresses is trivial; it's the wire address (which you get > from any router), plus the 802 address... You still have to update > the DNS, but there's no way to avoid that. No, you don't have to update the DNS ... an alternative model would be to tell the host its DNS name. It then uses a temporary address and ID (perhaps concocted out of the 802 numbers it has lying around) to find out what its information is supposed to be. I'm afraid I'm missing something. My host, with DNS name H, used to be on subnet X, and an internetwork address on that subnet is in the DNS for H. I now move H to subnet Y. Sure, I can use a temporary address to find out what's in the DNS for H, but how do incoming connections attempts figure out that H is now on Y, and not X, unless you update the address in the DNS? Noel From owner-Big-Internet@munnari.oz.au Mon Aug 2 15:36:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28076; Mon, 2 Aug 1993 15:36:47 +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 AA28042; Mon, 2 Aug 1993 15:36:13 +1000 (from kre@munnari.OZ.AU) Received: from world.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27085; Mon, 2 Aug 1993 15:15:28 +1000 (from solensky@world.std.com) Return-Path: Received: by world.std.com (5.65c/Spike-2.0) id AA17982; Mon, 2 Aug 1993 01:15:03 -0400 Date: Mon, 2 Aug 1993 01:15:03 -0400 From: solensky@world.std.com (Frank T Solensky) Message-Id: <199308020515.AA17982@world.std.com> To: kre@munnari.oz.au Subject: New Growth Charts Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Mon, 02 Aug 1993 15:35:58 +1000 Resent-Message-Id: <9452.744269758@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-9308.ps, as well as a compressed version (".Z") for those who find that more convienent. There are now 14,124 advertised network numbers compared to 6013 at this time last year, representing an annual growth rate of 134.9%. The predicted value of 13,502 nets for August 1 was surpassed arount the 10th. The "best-fit" logistic curve though the existing data also continues to accelerate: the curve now levels off above 75 million network numbers, compared to about 37.6 million at the end of June. -- Frank From owner-Big-Internet@munnari.oz.au Mon Aug 2 17:01:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01328; Mon, 2 Aug 1993 17:01:39 +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 AA01325; Mon, 2 Aug 1993 17:01:25 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23395; Mon, 2 Aug 1993 09:00:52 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA20872; Mon, 2 Aug 1993 09:00:44 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9308020700.AA20872@dxcern.cern.ch> Subject: Re: Routing Over Large Clouds To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 2 Aug 1993 09:00:42 +0200 (MET DST) Cc: bill.simpson@um.cc.umich.edu, jmh@anubis.network.com, atm@Sun.COM, big-internet@munnari.oz.au, iesg@cnri.reston.va.us, iplpdn@ietf.cnri.reston.va.us, jnc@ginger.lcs.mit.edu, rolc@network.com In-Reply-To: <9307301701.AA28659@ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 30, 93 01:01:39 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 992 Noel, everybody, >--------- Text sent by Noel Chiappa follows: ... > The Right Thing *is* to dissolve IPLPDN, and set up two WG's: one each > *specifically* for i) address resolution mechanisms on large WAN's (since we > have current need for this, plus at least one IPng candidate with a very > determined camp of shortish-fixed-length-internetwork-address advocates), and > ii) routing mechanisms for large WAN's. The charters should *specifically > prohibit* any work on stuff outside the charters, and the Chair's and AD's > have to enforce these. > I'm concerned that the basic architectural dilemma faced by ATM proponents (does ATM support a catenet architecture, or render it obsolete?) has to be faced at the same time as these two issues. You need to read Bob Cole's IP/ATM framework draft to see this spelled out. Of course, if ATM fails in the market, then it doesn't matter. 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 Tue Aug 3 01:14:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18999; Tue, 3 Aug 1993 01:14:22 +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 AA18990; Tue, 3 Aug 1993 01:14:12 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA04943; Mon, 2 Aug 93 10:51:35 -0400 Date: Mon, 2 Aug 93 10:51:35 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9308021451.AA04943@er.doe.gov> To: jnc@ginger.lcs.mit.edu, wollman@uvm-gen.emba.uvm.edu Subject: Re: Variable length addresses Cc: big-internet@munnari.oz.au wouldn't it be nice if either: The DNS could automatically learn the new address from the host; or the DNS could automatically change the address in the host DH From owner-Big-Internet@munnari.oz.au Tue Aug 3 01:23:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19339; Tue, 3 Aug 1993 01:23:16 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19309; Tue, 3 Aug 1993 01:23:01 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12525; Mon, 2 Aug 93 11:22:49 -0400 Date: Mon, 2 Aug 93 11:22:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308021522.AA12525@ginger.lcs.mit.edu> To: brian@dxcern.cern.ch, iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu Subject: Re: Routing Over Large Clouds Cc: atm@sun.com, big-internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us, rolc@network.com > The Right Thing *is* to ... set up two WG's: one each ... for i) address > resolution mechanisms on large WAN's ..., and ii) routing mechanisms for > large WAN's. I'm concerned that the basic architectural dilemma faced by ATM proponents (does ATM support a catenet architecture, or render it obsolete?) has to be faced at the same time as these two issues. Excuse me while I fall off my chair laughing! (I'm only laughing because the other option is getting pissed off, and that's not a useful feeling. :-) You may have missed my massive rant to the VC-Routing WG a while back, but as sure as the sun is going to come up tomorrow i) the ATM mesh is going to be part of a global internet, ii) such internet systems have system-wide problems like routing, resource allocation, etc which *cannot* be solved at a purely local level, iii) some parts of the ATM community are going to try to solve these issues at the local level, viewing the ATM mesh as an isolated component, and iv) it won't work. There is nothing you can do to prevent this. While I agree with you that it would be *nice* to solve that basic architetural dilemma, too many people either i) aren't going to see it, or ii) aren't going to get the answer right. I don't know of *any* technique to get through to them; there is an old saying you may know, "there are no so blind as those who will not see"? Only when reality has administered some sharp lessons will people be more receptive. You can't avoid it, so you might as well just sit back and enjoy it. All that can be done is that work can be done in parallel on the Right Answer, so that when the need becomes obvious the solution is in hand, ready to go. Hence, the two working groups. (Actually, the address resolution thing is a temporary kludge, I think, but we still need it for a variety of reasons.) Of course, if ATM fails in the market, then it doesn't matter. Oh, I think ATM is going to succeed, just not quite in the form that's usually visualized. I'll omit the argument as to why and how for now... Noel From owner-Big-Internet@munnari.oz.au Tue Aug 3 01:30:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19512; Tue, 3 Aug 1993 01:31: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 AA19509; Tue, 3 Aug 1993 01:30:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12630; Mon, 2 Aug 93 11:30:53 -0400 Date: Mon, 2 Aug 93 11:30:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308021530.AA12630@ginger.lcs.mit.edu> To: hitchcoc@oerv01.er.doe.gov, jnc@ginger.lcs.mit.edu, wollman@uvm-gen.emba.uvm.edu Subject: Re: Variable length addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu wouldn't it be nice if either: The DNS could automatically learn the new address from the host; or the DNS could automatically change the address in the host Sure. It would also be a giant security hole. Noel From owner-Big-Internet@munnari.oz.au Tue Aug 3 01:54:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20191; Tue, 3 Aug 1993 01:54:18 +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 AA20188; Tue, 3 Aug 1993 01:54:08 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04492; Mon, 2 Aug 1993 17:48:25 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA20790; Mon, 2 Aug 1993 17:48:22 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9308021548.AA20790@dxcern.cern.ch> Subject: Re: Routing Over Large Clouds To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 2 Aug 1993 17:48:22 +0200 (MET DST) Cc: iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu, atm@Sun.COM, big-internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us, rolc@network.com In-Reply-To: <9308021522.AA12525@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 2, 93 11:22:49 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2515 Noel, et al, >--------- Text sent by Noel Chiappa follows: > > > The Right Thing *is* to ... set up two WG's: one each ... for i) address > > resolution mechanisms on large WAN's ..., and ii) routing mechanisms for > > large WAN's. > > I'm concerned that the basic architectural dilemma faced by ATM proponents > (does ATM support a catenet architecture, or render it obsolete?) has to be > faced at the same time as these two issues. > > Excuse me while I fall off my chair laughing! (I'm only laughing because the > other option is getting pissed off, and that's not a useful feeling. :-) The strange thing is, I agree with you, and I'm glad you said that... > > You may have missed my massive rant to the VC-Routing WG a while back, but as Yes, that list got too much for me :-) > sure as the sun is going to come up tomorrow i) the ATM mesh is going to be > part of a global internet, ii) such internet systems have system-wide problems > like routing, resource allocation, etc which *cannot* be solved at a purely > local level, iii) some parts of the ATM community are going to try to solve > these issues at the local level, viewing the ATM mesh as an isolated > component, and iv) it won't work. ATM cannot solve problems outside itself. That does not mean that systems within an ATM cloud are not allowed to use innovative solutions. What won't work is confusing the two problem spaces. The ATM Forum has already increased the risk of that by confusing the two address spaces. > > There is nothing you can do to prevent this. While I agree with you that it > would be *nice* to solve that basic architetural dilemma, too many people > either i) aren't going to see it, or ii) aren't going to get the answer right. > I don't know of *any* technique to get through to them; there is an old saying > you may know, "there are no so blind as those who will not see"? Only when > reality has administered some sharp lessons will people be more receptive. You > can't avoid it, so you might as well just sit back and enjoy it. > > All that can be done is that work can be done in parallel on the Right Answer, > so that when the need becomes obvious the solution is in hand, ready to go. > Hence, the two working groups. (Actually, the address resolution thing is a > temporary kludge, I think, but we still need it for a variety of reasons.) > I did not comment at all whether the rolc WG should be set up. If you're flushing me out, I think it should be. There. Brian From owner-Big-Internet@munnari.oz.au Tue Aug 3 04:16:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25797; Tue, 3 Aug 1993 04:17:01 +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 AA25778; Tue, 3 Aug 1993 04:16:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13713; Mon, 2 Aug 93 14:15:45 -0400 Date: Mon, 2 Aug 93 14:15:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308021815.AA13713@ginger.lcs.mit.edu> To: brian@dxcern.cern.ch, jnc@ginger.lcs.mit.edu, rcoltun@sura.net Subject: Re: Routing Over Large Clouds Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@cnri.reston.va.us, iplpdn@ietf.cnri.reston.va.us I may be off base with this ... but I would say that the IPv4 and CLNP models are one source of your views that there is broken-ness in the problem with building catenets of ATM networks. I'm not positive I understand what exactly your point is, but don't think that I'm saying that IPv4 or CLNP has the solution to using ATM. I think we need a whole new internetwork layer, one which is neither pure VC nor pure packet, (for many reasons, not just to incorporate ATM). I think the optimal design of data networks is somewhere in the middle. To the extent that this describes the basic concept of ATM, it says that ATM will be a good match to what the future internetwork architecture will be. However, I'm positive we will still need an internetwork layer *above* ATM (for reasons I gave in my long rant to VC-routing). One artifact of this model is a big address vs a multi-tier address such as PIP uses. PIP would nicely support ATM as one (or more) level of the hierarchy. I think that viewing the Internet as one big address space is flawed as opposed to multiple levels. Again, I'm not sure exactly what your point is; if you're saying that a large, flat address space is bad, I absolutely agree with that. If you're saying that a flexible, hierarchical address space is what's needed I agree with that too. Howver, I would think that just makes my point; such an address space is for use by a system-wide routing architecture, not local stuff. Noel From owner-big-internet@munnari.oz.au Tue Aug 3 05:52:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28463; Tue, 3 Aug 1993 05:53:19 +1000 (from owner-big-internet) Return-Path: Received: from noc.sura.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22877; Tue, 3 Aug 1993 02:57:17 +1000 (from rcoltun@sura.net) Received: by noc.sura.net for big-internet@munnari.oz.au (5.65b/(SURAnet $Revision: 1.29 $)) id AA02248; Mon, 2 Aug 93 12:56:25 -0400 Date: Mon, 2 Aug 93 12:56:25 -0400 From: Rob Coltun Message-Id: <9308021656.AA02248@noc.sura.net> To: brian@dxcern.cern.ch, jnc@ginger.lcs.mit.edu Subject: Re: Routing Over Large Clouds Cc: atm@Sun.COM, big-internet@munnari.oz.au, iesg@cnri.reston.va.us, iplpdn@ietf.cnri.reston.va.us Brian and Noel, I may be off base with this (won't be the first time) but I would say that the IPv4 and CLNP models are one source of your views that there is broken-ness in the problem with building catenets of ATM networks. One artifact of this model is a big address vs a multi-tier address such as PIP uses. PIP would nicely support ATM as one (or more) level of the hierarchy. I think that viewing the Internet as one big address space is flawed as opposed to multiple levels. A handful of large corporations that I know of define their networks such that access to and from the Internet has to go through specific entry points and the internal addresses are completely hidden from the outside world (their data-center buildings don't even have signs on the outside, why would they want to allow someone to telnet in?). An ATM network will support using another ATM network as a transit network so a corporate backbone may use a provider for transit traffic to other parts of their corporate net. I think a more useful model of the future Internet is a multi-tiered hierarchy of catenets (ie supported by PIP) of which ATM may be one level. My 2 cents. Got to get back to coding.... ---rob > sure as the sun is going to come up tomorrow i) the ATM mesh is going to be > part of a global internet, ii) such internet systems have system-wide problems > like routing, resource allocation, etc which *cannot* be solved at a purely > local level, iii) some parts of the ATM community are going to try to solve > these issues at the local level, viewing the ATM mesh as an isolated > component, and iv) it won't work. ATM cannot solve problems outside itself. That does not mean that systems within an ATM cloud are not allowed to use innovative solutions. What won't work is confusing the two problem spaces. The ATM Forum has already increased the risk of that by confusing the two address spaces. From owner-big-internet@munnari.oz.au Tue Aug 3 06:48:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00478; Tue, 3 Aug 1993 06:48:41 +1000 (from owner-big-internet) Return-Path: Received: from titan.dss.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25963; Tue, 3 Aug 1993 04:23:21 +1000 (from mike@titan.dss.com) Received: by titan.dss.com (4.1/SMI-4.0) id AA12796; Fri, 30 Jul 93 08:08:59 EDT Date: Fri, 30 Jul 93 08:08:59 EDT From: mike@titan.dss.com (Michael A. Davis) Message-Id: <9307301208.AA12796@titan.dss.com> To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au In-Reply-To: Craig Partridge's message of Tue, 27 Jul 93 17:38:36 -0700 <9307280038.AA07151@aland.bbn.com> Subject: Variable length addresses and security - On Tue, 27 Jul 93 17:38:36 -0700, Craig Partridge said: Craig> instructions is a lot. Van Jacobson showed code at SIGCOMM '90 that could Craig> forward an IP datagram in << 100 instructions, so an extra 10 instructions Craig> would be a 10% performance reduction (probably not a big deal) and an extra Craig> 50 instructions would be a 50% performance reduction (a big deal). I'm sure most of you will think me pedantic for saying so, but if a given implementation takes 50% longer to run than a baseline, the reduction in performance is only 33%. (3/2 as many instructions == 2/3 as many loops per time period, yes?) Still a big deal, I agree. Other than that, your points are well taken. Craig> Craig -mad Mike Davis mike@titan.dss.com Datability Communications Research Center 261 West Central Street, Natick, MA, 02160 Mike Davis mike@titan.dss.com Datability Communications Research Center 261 West Central Street, Natick, MA, 02160 From owner-big-internet@munnari.oz.au Tue Aug 3 20:05:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01743; Tue, 3 Aug 1993 20:05:28 +1000 (from owner-big-internet) Return-Path: Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29938; Tue, 3 Aug 1993 19:18:06 +1000 (from peter@cyklop.volvo.se) Received: by mail.swip.net (5.65c8-/1.2) id AA23958; Tue, 3 Aug 1993 11:17:57 +0200 Message-Id: <199308030917.AA23958@mail.swip.net> Received: from cyklop.volvo.se by volvo.volvo.se with SMTP (15.11/15.6) id AA13721; Tue, 3 Aug 93 11:16:51 met Received: by cyklop.volvo.se (16.8/16.2) id AA19315; Tue, 3 Aug 93 11:16:50 +0200 From: Peter Hakanson Subject: How about RFC1475 ? To: big-internet@munnari.oz.au Date: Tue, 3 Aug 93 11:16:49 METDST Mailer: Elm [revision: 70.30] Has rfc 1475 been discussed here ?If not why ? -- Peter Hakanson VolvoData Dep 2230 phone +46 31 66 74 27 From owner-Big-Internet@munnari.oz.au Tue Aug 3 21:49:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05312; Tue, 3 Aug 1993 21:49:33 +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 AA05304; Tue, 3 Aug 1993 21:49:09 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA29385; Tue, 3 Aug 93 07:48:08 -0400 Date: Tue, 3 Aug 93 07:48:08 -0400 Message-Id: <9308031148.AA29385@worldlink.worldlink.com> From: David M. Piscitello To: bsimpson@morningstar.com Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@cnri.reston.va.us Subject: Re: Routing Over Large Clouds Bill.Simpson writes: I think this should be delayed until we have picked IPng, and then all of the various existing IETF WGs would work on the problems in that context, the same as with multicast. Given that IP will be "out there" for at least another decade, I don't think we should postpone consideration of these problems any longer than we already have. The one positive thing that I note in Stev Knowles' message is that the WG will be in the Routing rather than the Internet Area. What the difference is, I don't know, but hopefully that will be more focused. Hmmm... I'm not sure how to interpret your "positive" then... From owner-big-internet@munnari.oz.au Tue Aug 3 22:34:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06548; Tue, 3 Aug 1993 22:34:30 +1000 (from owner-big-internet) Return-Path: Message-Id: <9308031234.6548@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05691; Tue, 3 Aug 1993 22:04:54 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 3 Aug 1993 12:53:35 +0100 To: Peter Hakanson Cc: big-internet@munnari.oz.au Subject: Re: How about RFC1475 ? In-Reply-To: Your message of "Tue, 03 Aug 93 11:16:49 +0700." <199308030917.AA23958@mail.swip.net> Date: Tue, 03 Aug 93 12:53:33 +0100 From: Jon Crowcroft >Has rfc 1475 been discussed here ?If not why ? Peter it has been discussed to some extent. one problem is that the debate over the bigness of internet problems has concetrated on solutions that have a logistical chance of being put in place -e.g. TUBA via the CLNP exisiting implementaions and SIP+PIP becuase of the effort invested in piloting them (and TUBA pilots, I should say)... TP/IX represents a good collection of input ideas ... and given other resources, would be another good contender...its as simple as that... the debate about what format the packets take, is not very important though, compared with basic ways to solve large scale addressing, large scale routing and high bandwidth nets... in my opinion the debate is now pretty much over and the pro's and con's understood as far as they can be without implemtnation experience in the large... as fart as i'm concerend, i see no way to choose between the technical excellence of the SIP + PIP proposals and the perceived operational advantage of the tuba/clnp .... all now have a variety of pilot implementations decisions will no doubt be forthcoming (and probably fifth, sixth and seventh-coming:-) jon From owner-Big-Internet@munnari.oz.au Wed Aug 4 01:30:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13302; Wed, 4 Aug 1993 01:30:58 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13204; Wed, 4 Aug 1993 01:30:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20018; Tue, 3 Aug 93 11:29:47 -0400 Date: Tue, 3 Aug 93 11:29:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308031529.AA20018@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, peter@cyklop.volvo.se Subject: Re: How about RFC1475 ? Cc: jnc@ginger.lcs.mit.edu > Has rfc 1475 been discussed here ?If not why ? I think Jon Crowcroft's message explained why pretty well; practically speaking, it doesn't have a realistic chance, since not enough people are interested enough in it. It's too bad really, because if you believe in fixed length addresses (and I don't :-), TPIX is better than SIP in a number of ways; e.g. various fields (header length, packet length, etc, etc) are correctly sized in TPIX and woefully undersized in SIP, not that SIP doesn't have an advantage or two, e.g. the flow ID. Noel From owner-big-internet@munnari.oz.au Wed Aug 4 05:34:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21499; Wed, 4 Aug 1993 05:34:21 +1000 (from owner-big-internet) Return-Path: Message-Id: <9308031934.21499@munnari.oz.au> Received: from hadar.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16475; Wed, 4 Aug 1993 03:08:05 +1000 (from VOLZ@PROCESS.COM) Date: Tue, 3 Aug 1993 13:03 -0400 From: VOLZ@PROCESS.COM (Bernie Volz) To: big-internet@munnari.oz.au Subject: Re: How about RFC1475 ? > > Has rfc 1475 been discussed here ?If not why ? > >It's too bad really, because if you believe in fixed length addresses (and I >don't :-), TPIX is better than SIP in a number of ways; e.g. various fields >(header length, packet length, etc, etc) are correctly sized in TPIX and >woefully undersized in SIP, not that SIP doesn't have an advantage or two, >e.g. the flow ID. Other nice things TP/IX has ... it "fixes" the TCP layer by making use of 64-bit sequence numbers and 32-bit window sizes (as well as 32-bit port numbers). UDP is also changed to make use of 32-bit port numbers. - Bernie Volz Process Software Corporation From owner-big-internet@munnari.oz.au Wed Aug 4 07:22:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25313; Wed, 4 Aug 1993 07:23:13 +1000 (from owner-big-internet) Return-Path: Received: from noc.sura.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15412; Wed, 4 Aug 1993 02:32:27 +1000 (from rcoltun@sura.net) Received: by noc.sura.net for big-internet@munnari.oz.au (5.65b/(SURAnet $Revision: 1.29 $)) id AA26234; Tue, 3 Aug 93 12:32:13 -0400 Date: Tue, 3 Aug 93 12:32:13 -0400 From: Rob Coltun Message-Id: <9308031632.AA26234@noc.sura.net> To: jnc@ginger.lcs.mit.edu Subject: Re: Routing Over Large Clouds Cc: big-internet@munnari.oz.au Noel, My main point is that large corporations are starting to view the internet as a big subnet (ie a large cloud) - the Internet is growing vertically as well as horizontally. In the last few months I've heard of corporations looking at connecting to the internet as a way of connecting their multi-national backbones - they own their corporate backbone in each country but international links are too expensive to buy. I've also heard of a large multi-national corporation looking at selling international backbone services to other corporations. These (subscriber) corporations don't want to be accessable from the outside (rest of the Internet) so they will keep their internal addresses separated from access to/from the internet and have access machines and perhaps a couple of class C address for internet access. ANS now has an INTERLOCK (sp?) product that supports a similar function. I see this functionality as very similar to what ATM/SMDS/FR has to offer. We NOW have multiple logical internets that have specific access points between logical levels. PIP fits elegantly into this model. I had conversation with Yakov yesterday and agree that with products like INTERLOCK, no new technology is necessary to support this but there may be a difference between embedding the technology into the internet layer or having special boxes to accomplish this (only time will tell...). Thanks, ---rob > I may be off base with this ... but I would say that the IPv4 and CLNP > models are one source of your views that there is broken-ness in the > problem with building catenets of ATM networks. > >I'm not positive I understand what exactly your point is, but don't think that >I'm saying that IPv4 or CLNP has the solution to using ATM. I think we need a >whole new internetwork layer, one which is neither pure VC nor pure packet, >(for many reasons, not just to incorporate ATM). I think the optimal design of >data networks is somewhere in the middle. To the extent that this describes >the basic concept of ATM, it says that ATM will be a good match to what the >future internetwork architecture will be. However, I'm positive we will still >need an internetwork layer *above* ATM (for reasons I gave in my long rant to >VC-routing). > > One artifact of this model is a big address vs a multi-tier address such > as PIP uses. PIP would nicely support ATM as one (or more) level of the > hierarchy. I think that viewing the Internet as one big address space is > flawed as opposed to multiple levels. > >Again, I'm not sure exactly what your point is; if you're saying that a large, >flat address space is bad, I absolutely agree with that. If you're saying that >a flexible, hierarchical address space is what's needed I agree with that too. >Howver, I would think that just makes my point; such an address space is for >use by a system-wide routing architecture, not local stuff. > > Noel From owner-big-internet@munnari.oz.au Wed Aug 4 11:58:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05558; Wed, 4 Aug 1993 11:59:08 +1000 (from owner-big-internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26475; Wed, 4 Aug 1993 07:57:11 +1000 (from dab@berserkly.cray.com) Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19) id AA04996; Tue, 3 Aug 93 16:56:46 CDT Received: by frenzy.cray.com id AA08879; 4.1/CRI-5.6; Tue, 3 Aug 93 16:57:41 CDT Date: Tue, 3 Aug 93 16:57:41 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9308032157.AA08879@frenzy.cray.com> To: big-internet@munnari.oz.au, VOLZ@PROCESS.COM Subject: Re: How about RFC1475 ? > Other nice things TP/IX has ... it "fixes" the TCP layer by making > use of 64-bit sequence numbers and 32-bit window sizes (as well as > 32-bit port numbers). UDP is also changed to make use of 32-bit port > numbers. First, one has to operate on the assumption that there are good reasons for doing TCPng. I've actually been thinking a lot about the changes to TCP that are included in TP/IX, and I'm not convinced they are the right set of changes. For example, with the Timestamps option and PAWS, you don't need to expand the sequence number to 64 bits. After swaying back and forth, I'm currently inclined to leave the sequence space at 32 bits, but make the timestamp/timestamp-reply part of the fixed header, and expand the window to 32 bits. This avoids forcing everyone to have to do 64-bit sequence arithmetic, though it's not an issue for me personally, and the timestamps are a good thing to have for RTT measurements, and if you do that, PAWS comes almost for free. I'm also not sure that the TCP port numbers need to be expaned to 32 bits. A connection is defined by source/destination port/address, so the 16 bit port number only limits you to 64K connections to a single service between one pair of hosts. If you have a dozen hosts, you can have 64K connections to each of those hosts. Now, TCP *implementations* might limit your selection of port numbers to ones that are not in use in any existing connection, thus limiting you to 64K connections in total, but that is an *implementation* restriction, not a TCP restriction... There is also the question of do you really want to change the transport layer at the same time that you changing the network layer? Assuming that a TCPng is desired, I'd rather have a transition plan for TCPng whereby TCPng could be tested and deployed over IPv4, and then the transition to IPng could choose to support only TCPng, if that was felt to be the best tactic to take... My current arguments for doing a TCPng would be: 1) Increase the amount of space for options (to make the SACK option easier...) 2) Increase the window to 32 bits, so that you don't have to know at connection time how much buffer space you might want to have. 3) Align things on 64 bit boundaries > - Bernie Volz > Process Software Corporation -David Borman, dab@cray.com From owner-big-internet@munnari.oz.au Thu Aug 5 04:18:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24145; Thu, 5 Aug 1993 04:19:16 +1000 (from owner-big-internet) Return-Path: Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08894; Wed, 4 Aug 1993 22:30:32 +1000 (from peter@cyklop.volvo.se) Received: by mail.swip.net (5.65c8-/1.2) id AA15442; Wed, 4 Aug 1993 14:30:04 +0200 Message-Id: <199308041230.AA15442@mail.swip.net> Received: from cyklop.volvo.se by volvo.volvo.se with SMTP (15.11/15.6) id AA20206; Wed, 4 Aug 93 14:28:50 met Received: by cyklop.volvo.se (16.8/16.2) id AA01970; Wed, 4 Aug 93 14:28:49 +0200 From: Peter Hakanson Subject: rfc1475, slight changes needed ? To: big-internet@munnari.oz.au Date: Wed, 4 Aug 93 14:28:48 METDST Mailer: Elm [revision: 70.30] While there is interest to discuss rfc1475 i will take the chance to re-post an article i wrote for usenet a while ago. I am very concerned about internet community continues to lead and does so with the best available technology. -------------------------------------------------------------- rfc1475 looks good. It should work ok. But there is drawbacks. The biggest one is the large header sizes. This is a big problem for all those non-FDDI connections. To convince you i will remind about all efforts that's been put into tcp header compression, slip and PPP optimization etc. Another drawback is a tendency to swift focus from the 'KISS' strategy that has been very successful. This strategy has positioned TCP/IP as THE LEADER OF NETWORKING, leaving alternatives behind. In my opinion, the concept of 'autonomus datagrams' with or without sequencing upper layers is the very key to TCP/IP success. This is the strength of ip, this is what should be focused on. What is there to do then ? well a comparisment of ip V4 and rfc1475 looks like this: ip v4 rfc1475 ip header: 20 bytes header : 32 (or 36, see note about options) tcp header: 20 bytes header : 36 (or 40, see note about options) Whats can be done in rfc1475 to reduce this ? Well amazingly a lot. If we keep ip to be simple and RISC-like we could remove lots of fields. This is my suggestion: IP header * remove ' forward route identifier' This has nothing to do with datagrams, it is routing information. But as such it is at best doubtful and obsolete. = - 8 bytes * protocol. 8 bits has been filled to maybe 50% during > 10 years of use. There seems to be no point in increasing this. = -1byte * Total datagram length. I admit that 64K is small, but 4294967295 is a bit of overkill. If we are to save something why don't we use a reasonable number like '1/10 second on a sonet fibre' which is 620/8 bytes/10 = 7.75 Mbyte. Think of this as one second of error-free transfer on an ethernet. This would give 24 bits as length and spare 8 bits for use as 'options present', TOS, or maybe security (i wonder if some organizations would ever consider using rfc1475 without some security mechanism ?) It rounds up to 8 bytes less, leaving some bits in protocol for future use. Keeping ip header to be word aligned is probebly worth it. TCP header, the broadening of sequence and acknowledgement number is motivated by reducing the likehood of having duplicate packets floating around. But if we consider that 2^32 bytes represents a substantial storage capacity i really doubt that we will ever be even close to beeing able to store them in a network. Much less 2^64 bits. I therefore suggest that we add a 'connection identifier' with the purpose to discriminate between parallell sessions between two machines and reduce sequence/acknowledgement numbers to 4 bytes. = - 4 bytes * source/ destination port, here i'm more uncertain if there is a real limitation with 64K ports. The prospects of saving 4 bytes on the TCP header seems more attractive to mee then being able to squeeze more active processes into a single box. Are we really moving towards huge multi-servers again ?? If we are not, then the total number of active connection will in my opinion be well below 64.000. This would reduce tcp header to 28 bytes, an increase with 8 from ip v4. A further reduction could be done if we used 2 bytes from the window field and coded windows in a non contigous way ( power of 2 ?)This is an area o fdiscussion that YOU could help with. But i'll keep this open for now. In total we should then have a protocol suite that for the most common protocol combination (does there exists statistics on what is the most common tcp/ip usage ??). This is in line with RISC - strategy to optimize for the most common operations and do the unfrequent ones with combination of methods. Summary: with the above cuts from rfc1475 we would have a tcp/ip header of 24 + 28 bytes (as 20+20 in ip-v4). This is the price to pay for increasing the address space to a comfortable 10-20 year period. Of course this is a trade-off between functionality and speed. Most things are in the computer world. But we make a better job if we are aware of this and don't search for the free lunch. The increase of headers would be Notes: options in ip (and tcp) headers, i'm not shure how the absence of options in rfc1475 is expressed, at worst a full 4 byte word with option=0 is pushed on every frame. A useful way of dealing with this is to have an 'option present bit' in the header and each option. Absence of this bit then indicated end-of-options. -- Peter Hakanson VolvoData Dep 2230 phone +46 31 66 74 27 From owner-big-internet@munnari.oz.au Thu Aug 5 06:57:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29966; Thu, 5 Aug 1993 06:57:33 +1000 (from owner-big-internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25380; Thu, 5 Aug 1993 04:57:55 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA11794 (5.65/1.23); Wed, 4 Aug 93 14:57:07 -0400 Date: Wed, 4 Aug 93 14:57:07 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9308041857.AA11794@sadye.emba.uvm.edu> To: dab@berserkly.cray.com (David A. Borman) Cc: big-internet@munnari.oz.au Subject: Re: How about RFC1475 ? In-Reply-To: <9308032157.AA08879@frenzy.cray.com> References: <9308032157.AA08879@frenzy.cray.com> < There is also the question of do you really want to change the > transport layer at the same time that you changing the network layer? Except that, thanks to the pseudo-header's role in the TCP checksum, you MUST change the transport layer at the same time that you change the network layer. There's no way around it! So the most you could do is create a TCP:ng that assumes a particular IPng variant which is capable of embedding IPv4 addresses in its address or ID space (depending on the proposal). For example, it shouldn't be too hard to implement a TCP:ng for Pip which, when presented with an IPv4 address a.b.c.d, translated it into the appropriate Pip ID 40.00.00.00.a.b.c.d, and then stuck /that/ into the pseudo-header. However, this would not be interoperable with the TCP:ng's that use TP/IX or SIP or NSAP addresses their pseudo-headers. In other words, I agree with your concern, but I don't see any way around it. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-big-internet@munnari.oz.au Thu Aug 5 14:08:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17275; Thu, 5 Aug 1993 14:08:24 +1000 (from owner-big-internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07140; Thu, 5 Aug 1993 10:12:40 +1000 (from dab@berserkly.cray.com) Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19) id AA09774; Wed, 4 Aug 93 19:12:24 CDT Received: by frenzy.cray.com id AA00447; 4.1/CRI-5.6; Wed, 4 Aug 93 19:13:20 CDT Date: Wed, 4 Aug 93 19:13:20 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9308050013.AA00447@frenzy.cray.com> To: wollman@uvm-gen.EMBA.UVM.EDU Subject: Re: How about RFC1475 ? Cc: big-internet@munnari.oz.au > Date: Wed, 4 Aug 93 14:57:07 -0400 > From: wollman@uvm-gen.EMBA.UVM.EDU ... > < > > There is also the question of do you really want to change the > > transport layer at the same time that you changing the network layer? > > Except that, thanks to the pseudo-header's role in the TCP checksum, > you MUST change the transport layer at the same time that you change > the network layer. There's no way around it! So the most you could ... Wrong argument. Changing the TCP pseudo-header is a very different problem than changing the TCP header. The pseudo-header is used mainly for doing connection lookup, and checksums. Changing a TCP implementation to use a different pseudo-header format is a technically trivial problem, it does not change the actual transport protocol processing. On the other hand, doing things like going to 64 bit sequence numbers, making the port number 32 bits, moving the Urgent pointer into an option, etc, can require extensive changes to upgrade a TCP implementation. If these changes are needed, I'd rather see them decoupled from the IPng transition. Let the TCP/UDP over IPng deal with just the issues of a different pseudo-header, due to different addresses, and do TCPng/UDPng separately. Another argument for decoupling TCPng/UDPng from IPng is that the set of people working on IPng is not necessarily the set of people who should be working on TCPng and UDPng (though there is probably a fair amount of overlap between the two). -David Borman, dab@cray.com From owner-Big-Internet@munnari.oz.au Fri Aug 6 18:55:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08116; Fri, 6 Aug 1993 18:56:43 +1000 (from owner-Big-Internet) Return-Path: Received: from nttta.NTT.JP by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08105; Fri, 6 Aug 1993 18:55:29 +1000 (from sebayasi@tnlab.ntt.jp) Received: by ntt-sh.ntt.jp (5.59/ntt-sh-04h) with TCP; Fri, 6 Aug 93 17:55:14 JST Received: by mecl-sh.ntt.jp (4.1/MECLSH01) with TCP; Fri, 6 Aug 93 17:55:13 JST Received: by tnlab.ntt.jp (4.2/NTTcs02b) with TCP; Fri, 6 Aug 93 17:53:29 JST Message-Id: <9308060853.AA17493@tnlab.ntt.jp> To: big-internet@munnari.oz.au Cc: sebayasi@tnlab.ntt.jp Reply-To: sebayasi@tnlab.ntt.jp Subject: request Date: Fri, 06 Aug 93 17:53:28 +0900 From: Katuhiro SEBAYASI Dear Sir. I'd like to join the discussion of IPng. Please, add me this mailing list. Thanks. - ------------------ Katsuhiro Sebayashi NTT Telecommunication Networks Laboratory, Tokyo, Japan. E-mail: sebayasi@tnlab.ntt.jp TEL +81 422 59 2284 FAX +81 422 59 3203 From owner-big-internet@munnari.oz.au Sat Aug 7 15:41:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04926; Sat, 7 Aug 1993 15:41:49 +1000 (from owner-big-internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15135; Sat, 7 Aug 1993 08:38:12 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA17209 (5.65/1.23); Fri, 6 Aug 93 18:36:31 -0400 Date: Fri, 6 Aug 93 18:36:31 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9308062236.AA17209@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: Variable length addresses In-Reply-To: <9308020133.AA10400@ginger.lcs.mit.edu> References: <9308020133.AA10400@ginger.lcs.mit.edu> I've been keeping this message in my mailbox for a while, waiting for enough time to think about an appropriate answer. < I'm afraid I'm missing something. My host, with DNS name H, used to > be on subnet X, and an internetwork address on that subnet is in the > DNS for H. I now move H to subnet Y. Whoa there! Who told you that you could move host H to subnet Y?! In the context of Pip, which was how I was thinking of my original message, there are two answers: 1) Somebody writes an ESIS-for-Pip document and we use areas. 2) If the host is too mobile for areas to help, then the Pip mobile host server is used. If you are moving the host from one area to another, then you are presumed to have gotten the permission of the administrators of each area, who will have updated their DNS zone files appropriately; when other hosts attempt to contact the host which has moved, they receive a PCMP PND[No such ID at this address] packet back, causing them to flush their caches and retrieve the new information from an authoritative server. > Sure, I can use a temporary address to find out what's in the DNS > for H, but how do incoming connections attempts figure out that H is > now on Y, and not X, unless you update the address in the DNS? Aha, you must have missed part of this discussion (that's OK, by now I can hardly remember it either). In the standard ID-tailed setup, the host does NOT use the /address/ information from the DNS; it learns its address from neighboring routers. What it gets from the DNS is its EID(s). The area model takes care of local mobility, and the mobile host server takes care of more global mobility. I would write document (1) myself, if I had the time and a Pip implementation to pound it into. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-big-internet@munnari.oz.au Wed Aug 11 07:06:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15979; Wed, 11 Aug 1993 07:09:32 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06838; Wed, 11 Aug 1993 02:38:35 +1000 (from stev@ftp.com) Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA25802; Tue, 10 Aug 93 12:38:27 -0400 Date: Tue, 10 Aug 93 12:38:27 -0400 Message-Id: <9308101638.AA25802@ftp.com> To: bsimpson@morningstar.com Subject: Re: Routing versus Internet From: stev@ftp.com (stev knowles) Cc: Big-Internet@munnari.oz.au, iesg@CNRI.Reston.VA.US Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com >Some of us don't pay much attention to which Area a WG is under. if you were in charge of them, you would:) >Perhaps you could enlighten us as to the difference between the Routing >and Internet areas. Why would IPng efforts be classed as "internet" >rather than "routing", when the fundamental problem to be solved is a >routing problem? If we don't have a routing problem, why do we need IPng? the internet area concerns itself with the IP over Foo problem. when there are discussions about something new at the IP level (such as ST) they have fallen here also. the reason IPng is in the Internet area is that most of the work being done is at the IP level (they are twiddling bits in the header). there are a number of people who believe that the problems IPng intends to solve can be solved in the routing layer, basically leaving the format of the IP layer alone, just redefining how some of the fields are used. if this approach is begun by anyone, i woudl suggest that they work in the routing area. sooo, the reason it is here is that the people interested in fixing the problem are interested in changing the IP layer alot. >Are you advocating that each IPng effort have more than one WG, split >among the Areas? i am suggesting that routing work be done in the routing area,just like i woudl suggest that fundimental changes to SNMP to support IPng shoudl be done in the NM area. i would not suggest they have more than one WG if they dont intend to play with anything else. if a IPng group decided that current routing technology worked fine, then there is no reason to form a WG in the routing area. >Now, I will recognize that this is all your informed opinion. informed is not necessary, it is just my opinion. being one of the people who has to deal with the groups, this view my help explain why some things happen and some dont. From owner-big-internet@munnari.oz.au Thu Aug 12 06:29:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17443; Thu, 12 Aug 1993 06:30:10 +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 AA07746; Thu, 12 Aug 1993 02:48:13 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12196>; Wed, 11 Aug 1993 09:36:39 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 11 Aug 1993 09:36:28 -0700 To: rcallon@wellfleet.com (Ross Callon) Cc: big-internet@munnari.oz.au Subject: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of "Fri, 09 Jul 93 07:25:43 PDT." <9307091425.AA16132@cabernet.wellfleet> Date: Wed, 11 Aug 1993 09:36:19 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug11.093628pdt.12171@skylark.parc.xerox.com> Ross, Catching up on last month's mail, I came across the following comment from you: > ...If you don't have the > capability to embed addresses in those situations in which this > is useful, then you are likely to be stuck with an extra level of > address mapping, which will add both considerable complexity to the > solution, plus considerable delay (which is very bad for high speed > routers). I just wanted to point out that the need for an extra level of address mapping does not *necessarily* mean "considerable delay", as you implied. Paul Francis's Shortcut Routing scheme, for example, accomplishes IP -> link-layer address mapping for large link-layer clouds without making packets wait in a queue for an answer from some other system, and without requiring every system on the cloud to be pre-configured with the mapping for every other system. (ES-IS on a LAN also avoids delaying packets for address resolution, though it is not applicable to the multicast-challenged link layers that you were concerned with in your message.) Steve From owner-big-internet@munnari.oz.au Thu Aug 12 16:47:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB15073; Thu, 12 Aug 1993 16:47:37 +1000 (from owner-big-internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24870; Thu, 12 Aug 1993 09:40:28 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18983; Wed, 11 Aug 93 19:40:18 EDT Date: Wed, 11 Aug 93 19:40:18 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9308112340.AA18983@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: partly baked thought on address reclamation Putting IPng aside for now (:-) [ warning: partly baked thinking follows :-] Has there been thought about taking one of the Class A networks and migrating a set of related Class B networks into a single Class A and using that to reclaim some Class B address space ?? I'm thinking in particular that the DoD has a bunch of Class B networks in the metro DC area (NRL has _3_ Class B networks itself, for reasons I don't grasp; the 134.207.* network is especially sparsely used). All of the DoD networks in the DC area are tied back to MILnet and most (if not all) are tied back into SURAnet and FIXeast. Might it be (technically, I don't grasp politics :-) feasible to lump a bunch of DoD Class Bs that are already connected at SURA/FIXeast together inside a single Class A ? If this would work at all, maybe some other large connected networks (e.g. NASA Science Internet :-) could do the same sort of thing ? IMHO, we wouldn't be as pressed for IPng if we had been more thoughtful about giving out Class B network blocks from the get go (why the NIC permitted anyone to have 3 Class B networks for one campus is beyond my comprehension). BTW, I like Craig's analogy of IP numbers with telephone numbers. And isn't 64 bits of address a lot more than double the number of addresses ? Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Thu Aug 12 18:02:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18289; Thu, 12 Aug 1993 18:02:30 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18282; Thu, 12 Aug 1993 18:02:20 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA04865 (5.67a/IDA-1.5 for big-Internet@munnari.oz.au); Thu, 12 Aug 1993 01:02:11 -0700 Date: Thu, 12 Aug 1993 01:02:11 -0700 From: Tony Li Message-Id: <199308120802.AA04865@lager.cisco.com> To: big-Internet@munnari.oz.au Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson) Subject: partly baked thought on address reclamation [ warning: partly baked thinking follows :-] Is this like one of those play ovens where it gets more baked if I apply light? ;-) How about if I don't apply heat? ;-) Has there been thought about taking one of the Class A networks and migrating a set of related Class B networks into a single Class A and using that to reclaim some Class B address space ?? Yes, sort of. If you take a look at the latest and greatest CIDR document, it details how we can just take all unallocated class A space and spread it around in a classless way. So carving a class A up is trivial. You just have to use classless IGPs everywhere. I'm thinking in particular that the DoD has a bunch of Class B networks in the metro DC area (NRL has _3_ Class B networks itself, for reasons I don't grasp; the 134.207.* network is especially sparsely used). All of the DoD networks in the DC area are tied back to MILnet and most (if not all) are tied back into SURAnet and FIXeast. Might it be (technically, I don't grasp politics :-) feasible to lump a bunch of DoD Class Bs that are already connected at SURA/FIXeast together inside a single Class A ? Possible, but it actually wastes more address space to do this than what you're currently using now. So this is not a win. Tony From owner-big-internet@munnari.oz.au Fri Aug 13 03:56:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17819; Fri, 13 Aug 1993 04:00:46 +1000 (from owner-big-internet) Return-Path: Message-Id: <9308121800.17819@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28577; Thu, 12 Aug 1993 23:17:11 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1221; Thu, 12 Aug 93 09:17:00 EDT Date: Thu, 12 Aug 93 09:15:29 EDT From: yakov@watson.ibm.com To: atkinson@itd.nrl.navy.mil, big-Internet@munnari.oz.au Subject: partly baked thought on address reclamation Ref: Your note of Wed, 11 Aug 93 19:40:18 EDT >I'm thinking in particular that the DoD has a bunch of Class B >networks in the metro DC area (NRL has _3_ Class B networks itself, >for reasons I don't grasp; the 134.207.* network is especially sparsely >used). ... Might it be (technically, I don't grasp politics :-) >feasible to lump a bunch of DoD Class Bs that are already connected >at SURA/FIXeast together inside a single Class A ? Ran, A single Class A can accommodate a *fairly large* number of hosts (~1,6 millions). Unless the DoD has a *fairly large* number of hosts in the metro DC area, it would be waistful to use a Class A network. May I suggest that a better way to reclaim Class B address space would be to use a block(s) of Class C, and use it in such a way, as to reflect the actual number of hosts the DoD has in the metro DC area (so that you wouldn't have sparsely used network numbers). Yakov. From owner-big-internet@munnari.oz.au Fri Aug 13 05:41:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22833; Fri, 13 Aug 1993 05:42:10 +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 AA05967; Fri, 13 Aug 1993 02:13:43 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA01935; Thu, 12 Aug 93 11:57:20 -0400 Date: Thu, 12 Aug 93 11:57:20 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9308121557.AA01935@er.doe.gov> To: big-internet@munnari.oz.au Subject: The Trouble with Transition: Given uncertainties about the # of addresses, etc that we have there are two possible approaches to planning for the future. First one can spend whatever time it takes to make "accurate" predicitions to design and build to. Second, one can try to localize and isolate the places where the uncertainty has the most impact on the system so that changing it later has the least impact. There are clearly efficiency trade offs here but I suspect that some thought about how to isolate at least the applications from these issues would facilitate the current... and future transitions Dan From owner-big-internet@munnari.oz.au Fri Aug 13 08:42:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29493; Fri, 13 Aug 1993 08:42:50 +1000 (from owner-big-internet) Return-Path: Received: from [140.185.30.10] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05861; Fri, 13 Aug 1993 02:09:46 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA27727; Thu, 12 Aug 93 11:05:25 CDT From: Matt Jonson Message-Id: <9308121605.AA27727@server.af.mil> Subject: Re: partly baked thought on address reclamation To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Date: Thu, 12 Aug 1993 11:05:15 -0500 (CDT) Cc: big-Internet@munnari.oz.au In-Reply-To: <9308112340.AA18983@itd.nrl.navy.mil> from "Ran Atkinson" at Aug 11, 93 07:40:18 pm X-Mailer: ELM [version 2.4 PL3] Content-Type: text Content-Length: 2276 > Subject: partly baked thought on address reclamation > > Putting IPng aside for now (:-) > > [ warning: partly baked thinking follows :-] > > Has there been thought about taking one of the Class A networks and > migrating a set of related Class B networks into a single Class A and > using that to reclaim some Class B address space ?? > > I'm thinking in particular that the DoD has a bunch of Class B > networks in the metro DC area (NRL has _3_ Class B networks itself, > for reasons I don't grasp; the 134.207.* network is especially > sparsely used). All of the DoD networks in the DC area are tied back > to MILnet and most (if not all) are tied back into SURAnet and > FIXeast. Might it be (technically, I don't grasp politics :-) > feasible to lump a bunch of DoD Class Bs that are already connected at > SURA/FIXeast together inside a single Class A ? I think the most efficient thing DOD can do is to go out and reclaim all the entirely unused networks it has. DISA by itself must own 200 class B nets and several class As. I know the AF has a bunch of entirely unused nets. When we run across them, we try to transfer ownership to us and then reassign them later. (and when I say unused, I mean networks that were gotten and forgotten) Maybe it is time that the Internet community challenged network owners to prove their usage of allocated networks. Maybe this should be saved as a last-ditch option, but we shouldn't forget about it. ... /matt > If this would work at all, maybe some other large connected networks > (e.g. NASA Science Internet :-) could do the same sort of thing ? > > IMHO, we wouldn't be as pressed for IPng if we had been more > thoughtful about giving out Class B network blocks from the get go > (why the NIC permitted anyone to have 3 Class B networks for one > campus is beyond my comprehension). > > BTW, I like Craig's analogy of IP numbers with telephone numbers. > And isn't 64 bits of address a lot more than double the number of > addresses ? > > Ran > atkinson@itd.nrl.navy.mil > -- Capt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 From owner-big-internet@munnari.oz.au Fri Aug 13 09:50:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03093; Fri, 13 Aug 1993 09:51:29 +1000 (from owner-big-internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05406; Fri, 13 Aug 1993 01:52:56 +1000 (from rcallon@wellfleet.com) Received: from lobster.wellfleet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10994 Fri, 13 Aug 1993 01:52:42 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20902; Thu, 12 Aug 93 11:44:44 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA25598; Thu, 12 Aug 93 11:52:31 EDT Date: Thu, 12 Aug 93 11:52:31 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308121552.AA25598@cabernet.wellfleet> To: big-Internet@munnari.oz.au, tli@cisco.com Subject: Re: partly baked thought on address reclamation Cc: atkinson@itd.nrl.navy.mil Has there been thought about taking one of the Class A networks and migrating a set of related Class B networks into a single Class A and using that to reclaim some Class B address space ?? Yes, sort of. If you take a look at the latest and greatest CIDR document, it details how we can just take all unallocated class A space and spread it around in a classless way. So carving a class A up is trivial. You just have to use classless IGPs everywhere. Well, not quite everywhere. If domains A, B, ... through K use class- sensitive IGPs (old version of RIP), and Domains L, M, ... through Z use classless IGPs (OSPF and/or I.IS-IS), then you could use a class A sub-divided further for domains L through Z. Thus, the amount that you gain from doing this is proportional to how many of the domains in the Internet are using classless IGPs (in addition to classless External routing, of course) (and also proportional to how much of the Internet is willing to re-assign their network numbers). I'm thinking in particular that the DoD has a bunch of Class B networks in the metro DC area (NRL has _3_ Class B networks itself, for reasons I don't grasp; the 134.207.* network is especially sparsely used). All of the DoD networks in the DC area are tied back to MILnet and most (if not all) are tied back into SURAnet and FIXeast. Might it be (technically, I don't grasp politics :-) feasible to lump a bunch of DoD Class Bs that are already connected at SURA/FIXeast together inside a single Class A ? Possible, but it actually wastes more address space to do this than what you're currently using now. So this is not a win. But, if the class B's are very sparsely used, why not replace them with a set of class C's (or a class C sized chunk out of a class A or B space)? I would assume that these nets have class B's because there are other systems in the nets which are not visible from outside, but these could use the current address allocation on a "local" basis. I am convinced that there are a lot of things that we can do along these lines to extend the life of IP (things that I would claim are in addition to CIDR, although you could call them enhancements to CIDR). My understanding is that Yakov, Peter Ford, and Hans-Werner may have a paper coming out at INET next week that discuss some of the options available (beyond straightforward CIDR) for extending the life of IP (I was thinking of writing up some of these ideas, but Yakov, Peter and Hans-Werner did it first, and it is mostly their ideas anyway :-). Ross From owner-big-internet@munnari.oz.au Fri Aug 13 09:49:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02929; Fri, 13 Aug 1993 09:49:19 +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 AA26178; Fri, 13 Aug 1993 07:15:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06369; Thu, 12 Aug 93 17:14:58 -0400 Date: Thu, 12 Aug 93 17:14:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308122114.AA06369@ginger.lcs.mit.edu> To: deering@parc.xerox.com, rcallon@wellfleet.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I just wanted to point out that the need for an extra level of address mapping does not *necessarily* mean "considerable delay", as you implied. Paul Francis's Shortcut Routing scheme, for example, accomplishes IP -> link-layer address mapping for large link-layer clouds without making packets wait in a queue for an answer from some other system, True, but the way it does this is it makes the first data packet be the "query". So, during the time period in which the link-layer address is getting resolved, further data packets may be taking a circuitous path. Not the end of the world, true, and better in many way than making them wait, true, but still not as good as having the link-layer address from the start. and without requiring every system on the cloud to be pre-configured with the mapping for every other system. True, you don't have to have everyone knowing everything, but when a data packet gets to the router which has to send it to the host, that router has to get the mapping to the link-layer address from somewhere, be it a configured table in the router (painful), a multi-cast to the group that router servers (potentially expensive), a server (resolution delay), or whatever... Again, none of them as convenient as having the link layer address from the start. Occam's design razor: the wise designer does not multiply mechanism without a darn good reason! Noel From owner-Big-Internet@munnari.oz.au Fri Aug 13 23:57:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07289; Fri, 13 Aug 1993 23:57:31 +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 AA07241; Fri, 13 Aug 1993 23:57:08 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA04782; Fri, 13 Aug 93 09:54:52 -0400 Date: Fri, 13 Aug 93 09:54:52 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9308131354.AA04782@er.doe.gov> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, rcallon@wellfleet.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au Using Noel's argument one could argue that the "address" of the host should have the entire path through the cloud imbedded in it so that no router would have to resolve anything along the way. Of course this is a lot like a virtual circuit and has all the problems of lots of state stored in the net. Also, I suspect that in a world of nets with large bandwidth delay products having the first packet be a query...just before you start dumping 1Gb/s into someone's PC, might actually be a good thing. On a related matter, we have been trying to design for "minimal needed changes" on end systems for backward compatibility. This is a sensible goal; however, perhaps there are some "recommended" end system changes which would be attractive enough that we should include them in our planning. The basic criterion for this I think is changes that people running IPv4 would find useful in terms of making their systems more manageable,... (VJCC is perhaps one prior example). DH From owner-Big-Internet@munnari.oz.au Sat Aug 14 01:58:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13274; Sat, 14 Aug 1993 01:58:52 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA13266; Sat, 14 Aug 1993 01:58:34 +1000 (from huitema@mitsou.inria.fr) Received: from mitsou.inria.fr by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06852; Fri, 13 Aug 93 05:15:20 -0400 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA04792; Fri, 13 Aug 1993 11:09:00 +0200 Message-Id: <199308130909.AA04792@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: deering@parc.xerox.com, rcallon@wellfleet.com, big-internet@munnari.oz.au Subject: Re: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of "Thu, 12 Aug 93 17:14:58 EDT." <9308122114.AA06369@ginger.lcs.mit.edu> Date: Fri, 13 Aug 93 11:09:00 +0200 From: Christian Huitema => True, you don't have to have everyone knowing everything, but when a data => packet gets to the router which has to send it to the host, that router has to => get the mapping to the link-layer address from somewhere, be it a configured => table in the router (painful), a multi-cast to the group that router servers => (potentially expensive), a server (resolution delay), or whatever... Again, => none of them as convenient as having the link layer address from the start. => Noel, The one reason this is not pushed further in current IP is that you don't want to "overspecify" the route of the packet. In most cases, the IP address in the header is the final destination, which is probably sitting on some local net, several hops away. If one would want a "unique mechanism" and find the subnet addresses in the headers, then one would have to do so for all hops, which mean that the header will carry a source route expressed as a sequence of subnet-id + subnet addresses. This goes against simplicity, and also against adaptability. Remember UUCP routing, and the infamous path rewriters? Now, Ross has a real requirement: that packets could be routed "immediately" without having to maintain an "ARP queue" or its equivalent. This is solved in broadcast capable networks by ES-IS or similar "discovery" protocols. This is harder in non broadcast networks, though not undoable -- e.g. building upon the "designated" and "back-up" router concept of OSPF, using redirects, etc. I guess that the first step here -- even for current IP -- is to allow more efficient "redirects" over WANs. Shortcut routing is one approach. Yes, initial packets take two hops instead of one; but this is also the case using ES-IS, and nobody seems to see that as a "fatal flaw". Christian Huitema From owner-Big-Internet@munnari.oz.au Sat Aug 14 04:09:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17824; Sat, 14 Aug 1993 04:10:10 +1000 (from owner-Big-Internet) Return-Path: Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17817; Sat, 14 Aug 1993 04:09:56 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26074; Fri, 13 Aug 93 14:03:05 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA26401; Fri, 13 Aug 93 14:10:56 EDT Date: Fri, 13 Aug 93 14:10:56 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308131810.AA26401@cabernet.wellfleet> To: hitchcoc@oerv01.er.doe.gov Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, rcallon@wellfleet.com Using Noel's argument one could argue that the "address" of the host should have the entire path through the cloud imbedded in it so that no router would have to resolve anything along the way. Of course this is a lot like a virtual circuit and has all the problems of lots of state stored in the net. I don't think that this is fair. There are real world problems which can be solved very simply by embedding one (and only one) "large cloud subnet address" in the internet address. Some people (including me) are claiming that these practical real world problems need to have *some* reasonable solution. I don't see anyone proposing to put a complete list of multiple intermediate subnet addresses in every packet (and if anyone did propose this, I would probably join you in dumping on them :-). Also, I suspect that in a world of nets with large bandwidth delay products having the first packet be a query...just before you start dumping 1Gb/s into someone's PC, might actually be a good thing. On a related matter, we have been trying to design for "minimal needed changes" on end systems for backward compatibility. This is a sensible goal; however, perhaps there are some "recommended" end system changes which would be attractive enough that we should include them in our planning. The basic criterion for this I think is changes that people running IPv4 would find useful in terms of making their systems more manageable,... (VJCC is perhaps one prior example). Now, I can agree with the rest of this (not that this is necessarily the answer, but it is a reasonable thing to consider). By the way, there seems to be a notion that we can never *require* any changes in hosts. I agree that this does not preclude proposing optional changes in hosts which would make the network work more efficiently. However, I don't necessarity feel that we have to be backward compatible with all systems for all time. When I started looking at Internet protocols IP did not look anything like what it does today. IP addresses consisted of an 8 bit network number plus a 24 bit host address (which was of course the same as the 24 bit Arpanet subnet address). Back then there was no notion of class A, B, C, subnetting, or ARP. Hosts did 1822 as their subnet protocol. Thus a host from back then would not work in today`s IP Internet. Over the years we have made a lot of changes which were "temporarily compatible", in the sense that we coexisted with recent hosts, but not for all time. In the same sense, I think that any change which we make today has to be compatible with any host which has been deployed in the last 5 years, but we don't have to be constrained that any host deployed in the year 2020 has to be compatible with any host that was deployed in 1985. Ross From owner-Big-Internet@munnari.oz.au Sun Aug 15 04:15:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11833; Sun, 15 Aug 1993 04:16:14 +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 AA11821; Sun, 15 Aug 1993 04:15:53 +1000 (from kre@munnari.OZ.AU) To: rcallon@wellfleet.com (Ross Callon) Cc: hitchcoc@oerv01.er.doe.gov, big-internet@munnari.oz.au Subject: Re: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of "Fri, 13 Aug 1993 14:10:56 EDT." <9308131810.AA26401@cabernet.wellfleet> Date: Sun, 15 Aug 1993 04:15:39 +1000 Message-Id: <15865.745352139@munnari.OZ.AU> From: Robert Elz Date: Fri, 13 Aug 93 14:10:56 EDT From: rcallon@wellfleet.com (Ross Callon) Message-ID: <9308131810.AA26401@cabernet.wellfleet> There are real world problems which can be solved very simply by embedding one (and only one) "large cloud subnet address" in the internet address. This is certainly true. However there are other real world problems that cannot be solved this simple way without embedding 2, or 3, large cloud subnet address in the internet address. And probably others that would require even more. Consider a company with a large intra organisation X.25, or Frame relay, or ATM, or this week's magic net, connecting at several places to several public data nets, which then connect to another large organisations frame relay (or whatever). If embedding the large cloud address is the right way to handle one of those clouds, then surely it must be the right way way to handle each of them. Of course, which particular large cloud addresses to embed is going to depend on where the sending system is located, which means that this "address" is really turning into a route. Add to that the expectation that other people have that the internet address will contain the end-point MAC address, as a method to avoid ARP (or similar), and you're getting to something that is likely to be very long indeed. This doesn't seem rational to me - we need to find a method to do this kind of address resolution, which isn't dependant on embedding other addresses in internet addresses (which could become recursive embedding in any case, as that large cloud may just be an internet large cloud). Just because that method hasn't been found yet is not an excuse for doing something sub-standard. kre From owner-Big-Internet@munnari.oz.au Sun Aug 15 15:55:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01778; Sun, 15 Aug 1993 15:55:40 +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 AA01765; Sun, 15 Aug 1993 15:55:29 +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; Sun, 15 Aug 93 01:55:21 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for rcallon@wellfleet.com; Sun, 15 Aug 93 01:55:20 EDT Date: Sun, 15 Aug 93 01:55:20 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9308150555.AA06972@tsuchiya.bellcore.com> To: kre@munnari.OZ.AU, rcallon@wellfleet.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov > > If embedding the large cloud address is the right way to handle > one of those clouds, then surely it must be the right way > way to handle each of them. Of course, which particular > large cloud addresses to embed is going to depend on where > the sending system is located, which means that this "address" > is really turning into a route. This shouldn't have to be true. If each cloud is "down the hierarchy" from the previous, then it doesn't matter who the sending system is, the series of subnet addresses is the same for all. If one cloud is not below the previous, then they are peers, and there isn't a big fanout so the routers can keep track of each other without requiring the address in the packet header. > > Add to that the expectation that other people have that the > internet address will contain the end-point MAC address, as > a method to avoid ARP (or similar), and you're getting to > something that is likely to be very long indeed. I don't know of anyone who is proposing this. Actually, I'm not so fond of embedding subnet addresses in internet addresses ever, but I think putting them in the header *somewhere* (an option?) has merit..... PF From owner-Big-Internet@munnari.oz.au Sun Aug 15 23:30:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13919; Sun, 15 Aug 1993 23:30:43 +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 AA13916; Sun, 15 Aug 1993 23:30:37 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA20272; Sun, 15 Aug 1993 09:30:08 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199308151330.AA20272@world.std.com> Subject: Re: embedding link-layer addresses in IPng addresses To: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Date: Sun, 15 Aug 1993 09:30:08 -0400 (EDT) Cc: kre@munnari.OZ.AU, rcallon@wellfleet.com, big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov In-Reply-To: <9308150555.AA06972@tsuchiya.bellcore.com> from "Paul Francis--formerly Tsuchiya" at Aug 15, 93 01:55:20 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1319 > > > > > If embedding the large cloud address is the right way to handle > > one of those clouds, then surely it must be the right way > > way to handle each of them. Of course, which particular > > large cloud addresses to embed is going to depend on where > > the sending system is located, which means that this "address" > > is really turning into a route. > This shouldn't have to be true. If each cloud is "down the > hierarchy" from the previous, then it doesn't matter who the > sending system is, the series of subnet addresses is the same > for all. If one cloud is not below the previous, then they > are peers, and there isn't a big fanout so the routers can > keep track of each other without requiring the address in the > packet header. > Actually, I'm not so fond of embedding subnet addresses in > internet addresses ever, but I think putting them in the > header *somewhere* (an option?) has merit..... > Separate subnet and general network layer addresses in the header might help with some other problems, given that a [privileged] relay could substitute a "more appropriate" subnet address. Examples of real-world problems where changing subnets makes sense include redirection to multi-homed hosts, or using a different subnet for reasons of security or other policy. > PF > From owner-Big-Internet@munnari.oz.au Mon Aug 16 06:01:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25046; Mon, 16 Aug 1993 06:02:15 +1000 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25035; Mon, 16 Aug 1993 06:01:45 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA16342 (5.65/1.23); Sun, 15 Aug 93 16:01:09 -0400 Date: Sun, 15 Aug 93 16:01:09 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9308152001.AA16342@sadye.emba.uvm.edu> To: Craig Partridge Cc: Valdis Kletnieks , ietf@CNRI.Reston.VA.US, Big-Internet mailing list Subject: Re: address sizes Reply-To: Big-Internet mailing list In-Reply-To: <9308120033.AA09964@aland.bbn.com> References: <9308120033.AA09964@aland.bbn.com> Note cross-posting! I have redirected replies to B-I... < said: > One of my concerns is that folks are talking about *big* and *variable* > length addresses as the solution. A discussion earlier this month suggested > that while variable was OK, mixing variable sizes with potentially large > sizes is has disturbing performance implications. Only if you must remain wedded to the mask-and-match model. Certainly I don't think Pip suffers from this problem; ``ordinary'' forwarding operations will involve grabbing a single 16-bit number out of the header, salting away the two least-significant bits, and using the rest as a table index. I would expect that, for this ``usual'' case, a Pip router which was optimized to the same degree as an IP router would perform better than for IP (because mask-and-match is completely eliminated). (Pip as other problems right now, most notably ARP.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-big-internet@munnari.oz.au Mon Aug 16 06:24:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25525; Mon, 16 Aug 1993 06:24:22 +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 AA19263; Mon, 16 Aug 1993 02:34:33 +1000 (from kre@munnari.OZ.AU) To: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Cc: rcallon@wellfleet.com, big-internet@munnari.oz.au Subject: Re: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of "Sun, 15 Aug 1993 01:55:20 EDT." <9308150555.AA06972@tsuchiya.bellcore.com> Date: Mon, 16 Aug 1993 02:34:22 +1000 Message-Id: <16159.745432462@munnari.OZ.AU> From: Robert Elz Date: Sun, 15 Aug 93 01:55:20 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-ID: <9308150555.AA06972@tsuchiya.bellcore.com> This shouldn't have to be true. If each cloud is "down the hierarchy" from the previous, then it doesn't matter who the sending system is, the series of subnet addresses is the same for all. This very much depends on the purpose of embedding addresses. If you look at what I said again, I deliberately indicated multiple points of contact between the various large clouds, so if the point of embedding the address is to assist the routers with packet forwarding, then the address would have to vary depending on which of those points of contact is to be used, which is making it a route. This is true regardless of the relationship between the clouds. I think I've also seen a suggestion somewhere that the embedded address is not there for routing, but just as an address assignment strategy - that is, making use of someone else's work in assigning addresses to make our work easier. I don't actually see that as an ambedded address at all, its simply an address assigned by someone else, perhaps with some extra bytes tacked on - as an address assignment stragety it certainly has advantages (less work), and disadvantages, but none of that is relevant here. If one cloud is not below the previous, then they are peers, and there isn't a big fanout Ah, but there is - again consider a large public cloud, that will have many other clouds of various sizes connected. This is the case where I see the argument for embedding addresses being must argued, to enable easy routing through large public nets. The fanout here is high, the whole point is to avoid the routers having to somehow keep track of the cloud-addresses of the next hops to everywhere. Now assume that one of the connected clouds is another big one (large international private corporate cloud), that may even be bigger than the public cloud in terms of numbers of attachment points. That one needs an embedded address just as much as the public cloud to find the correct endpoint, surely? If there is to be no more than one embedded address, which is it to be, and how does the other cloud do its routing? Why can't the answer to that be used instead of the embedded address for the other cloud? Actually, I'm not so fond of embedding subnet addresses in internet addresses ever, but I think putting them in the header *somewhere* (an option?) has merit..... I have no problems with putting routes in headers, or parts of routes in headers, anything to make the router's job easier. I'm not much in favour of calling routes addresses though. I'm also strongly opposed to small arbitrary limits (like one) imposed for little reason other than pandering to phobias related to address lengths. kre From owner-big-internet@munnari.oz.au Mon Aug 16 10:41:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04715; Mon, 16 Aug 1993 10:42:02 +1000 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01651; Mon, 16 Aug 1993 09:18:14 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA26490 for big-internet@munnari.oz.au; Sun, 15 Aug 93 19:17:57 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA00430; Sun, 15 Aug 93 16:16:05 PDT Message-Id: <9308152316.AA00430@aland.bbn.com> To: wollman@uvm-gen.EMBA.UVM.EDU Cc: Valdis Kletnieks , Big-Internet mailing list Subject: re: address sizes From: Craig Partridge Date: Sun, 15 Aug 93 16:16:05 -0700 Sender: craig@aland.bbn.com [Note: replying only to Big-I] Garrett: I think you misunderstood the reason I care about big and variable addresses. To first order, I don't care about masking and parsing costs. In a router done well, I believe they are in the noise. What I care about is memory loads -- there's a big penalty for discovering that you don't have all of the header that you need loaded into cache, there's an even bigger penalty for memory traps (from overestimating and loading non-existent memory), and if you avoid the memory trap, you still pay some cost for loading substantially more data than you need because it eats memory load cycles (and we're fast getting to the point where routers are memory speed limited, not processor speed limited). So my nightmare is that either: (1) at the key point in the forwarding loop, the router stalls for tens of cycles to go get the last bytes of a variable length address; OR (2) router performance suffers because everyone is loading 80 bytes of header, even though the average variable length header is only 40 bytes, because they are trying to avoid the stalls of (1). Keep in mind that our addressing scheme has to scale in both speed (say to 100 Gb/s) and number of addresses. Craig From owner-Big-Internet@munnari.oz.au Mon Aug 16 16:12:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17013; Mon, 16 Aug 1993 16:12:22 +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 AA17008; Mon, 16 Aug 1993 16:12:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25870; Mon, 16 Aug 93 01:21:37 -0400 Date: Mon, 16 Aug 93 01:21:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308160521.AA25870@ginger.lcs.mit.edu> To: kre@munnari.oz.au, rcallon@wellfleet.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu However there are other real world problems that cannot be solved this simple way without embedding 2, or 3, large cloud subnet address in the internet address. It's late, and my brain is not working well, but in all the cases I can come up with, the extra WAN addresses which are needed are those of routers. If routers' internet addresses contained their WAN addresses, wouldn't the excahneg of router internet addresses give you all the WAN addresses you need? The only WAN address which the routers will not already have is the one for the destination interface, and that's the one which is being used in the destination internetwork address. Consider a company with a large intra organisation ... connecting at several places to several public data nets, which then connect to another large organisations ... If embedding the large cloud address is the right way to handle one of those clouds, then surely it must be the right way way to handle each of them. I'm not following this. Unless you are trying to do some sort of Multi-Media Bridge kludge (in which case you will lose in so many ways it's not true :-), you'll have internetwork routers at these connection points. Why would be the addresses needed not be in the data passed around by the routing protocol? Of course, which particular large cloud addresses to embed is going to depend on where the sending system is located Is this need to specify particular connection points caused by the desire to have some specific source policy, as to which path you take, honored by the routers? If so, you need to have the source specify the route; for datagram transactions,a source route will suffice; for longer ones, you really need a flow-setup architecture to make long transactions reasonably efficient. Perhaps I am missing your point? which means that this "address" is really turning into a route. I will assume that what you are thinking of when you use the term "address" here is actually more of a source route, and yes, a source route is a route. I am in favor of putting WAN (and other physical network addresses) into internetwork addresses, but when I use the 'address' here I refer *specifically* to a thing which is *only* the name of an interface. (I assume everyone has read RFC-1498, the Saltzer paper, by now, yes?) This very much depends on the purpose of embedding addresses. ... I deliberately indicated multiple points of contact between the various large clouds, so if the point of embedding the address is to assist the routers with packet forwarding, then the address would have to vary depending on which of those points of contact is to be used, which is making it a route. You're talking about source routing here, and depending on just how it is done, it might or might not require physical addresses of the interfaces of intermediate routers. Consider a routing architecture which specifies source routes in terms of virtual links.... The physical address of the destination interface is embedded in its internetwork address for a number of reasons, *one* of which is that this physical address, unlike the physical addresses of other routers, is not reasonably already available to the last hop router. I think I've also seen a suggestion somewhere that the embedded address is not there for routing, but just as an address assignment strategy - that is, making use of someone else's work in assigning addresses to make our work easier. This is another reason. Given how hard it is to assign identifiers which are local to the physical network, unique within that scope, and mapped into physical addresses (e.g. IP host numbers on an Ethernet), plus all the work to manage the mapping (a lot harder on a WAN with no ARP), etc, it's not an inconsequential point. I don't actually see that as an [embedded] address at all, its simply an address assigned by someone else You must have a very different definition for the term "embedded address", since I would absolutely apply it to the case above (we are embedding a network level address, e.g. 802 or E.164, directly into an internetwork level address). Can you explain what yours is, to help disperse the confusion? The fanout here is high, the whole point is to avoid the routers having to somehow keep track of the cloud-addresses of the next hops to everywhere. They *have* to keep track of all the places they can *get to* through router X; keeping track of X's physical network address as well isn't much more work, and makes life a lot easier. I'm not much in favour of calling routes addresses though. I'm not sure how you concluded that using the network level address in the interface's internetwork address, instead of some other locally-unique (hopefully :-) number you just *map into* a network level address (via ARP, tables, or whatever), changed that address into a route. Can you explain? Noel From owner-Big-Internet@munnari.oz.au Mon Aug 16 21:08:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27778; Mon, 16 Aug 1993 21:08:31 +1000 (from owner-Big-Internet) Return-Path: Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27775; Mon, 16 Aug 1993 21:08:21 +1000 (from peter@cyklop.volvo.se) Received: by mail.swip.net (5.65c8-/1.2) id AA10849; Mon, 16 Aug 1993 13:08:13 +0200 Message-Id: <199308161108.AA10849@mail.swip.net> Received: from cyklop.volvo.se by volvo.volvo.se with SMTP (15.11/15.6) id AA17637; Mon, 16 Aug 93 13:01:06 met Received: by cyklop.volvo.se (16.8/16.2) id AA07453; Mon, 16 Aug 93 13:01:04 +0200 From: Peter Hakanson Subject: Re: embedding link-layer addresses in IPng addresses (fwd) To: big-internet@munnari.oz.au Date: Mon, 16 Aug 93 13:01:03 METDST Mailer: Elm [revision: 70.30] > > However there are other real world problems that cannot be solved this > simple way without embedding 2, or 3, large cloud subnet address in the > internet address. > > It's late, and my brain is not working well, but in all the cases I can come > up with, the extra WAN addresses which are needed are those of routers. If > routers' internet addresses contained their WAN addresses, wouldn't the > excahneg of router internet addresses give you all the WAN addresses you need? > The only WAN address which the routers will not already have is the one for > the destination interface, and that's the one which is being used in the > destination internetwork address. Stuff Deleted to save bandwidth From owner-Big-Internet@munnari.oz.au Mon Aug 16 23:42:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03341; Mon, 16 Aug 1993 23:42:58 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03330; Mon, 16 Aug 1993 23:42:42 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA03291; Mon, 16 Aug 93 09:42:37 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA02877; Mon, 16 Aug 93 09:44:52 EDT Message-Id: <9308161344.AA02877@tipper> X-Really-To: gibbs.oit.unc.edu To: big-internet@munnari.oz.au Subject: Long addresses Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Aug 93 09:44:52 -0400 From: Simon E Spero Warning: The idea in this message is half-baked. The USDA recommends that all ideas be thoroughly cooked until no trace of redness remains- much the same as Macarthy. Thinking about the problems of dealing with potentially very long addresses, and the fact that traffic patterns mean that a lot of routers will be seeing traffic to and from the same hosts during a given time frame: what would happen if we put a CRC or MD5 checksum of the address before the address; this checksum would only need to be generated once per address, and could be used as the lookup token for routing. In fact, if one were to calculate the checksum over the source & destination addresses, together with some flow number, it could even be used as the flow indentifier Thoughts? Simon From owner-Big-Internet@munnari.oz.au Tue Aug 17 00:26:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05574; Tue, 17 Aug 1993 00:26:46 +1000 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05570; Tue, 17 Aug 1993 00:26:39 +1000 (from kasten@ftp.com) Received: by ftp.com id AA05385; Mon, 16 Aug 93 10:26:40 -0400 Date: Mon, 16 Aug 93 10:26:40 -0400 Message-Id: <9308161426.AA05385@ftp.com> To: ses@tipper.oit.unc.edu Subject: Re: Long addresses From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au > Thinking about the problems of dealing with potentially very long addresses, > and the fact that traffic patterns mean that a lot of routers will be seeing > traffic to and from the same hosts during a given time frame: > what would happen if we put a CRC or MD5 checksum of the address before the > address; this checksum would only need to be generated once per address, and > could be used as the lookup token for routing. In fact, if one were to calculate > the checksum over the source & destination addresses, together with some flow > number, it could even be used as the flow indentifier This number would be a hash key, and need to be treated as such. In other words, once you get the right hash bucket you still need to do a full compare on the addresses. The win is that you would have to do the compare over fewer addresses in the router's forwarding table. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Tue Aug 17 00:33:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05879; Tue, 17 Aug 1993 00:33:25 +1000 (from owner-Big-Internet) Return-Path: Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05875; Tue, 17 Aug 1993 00:33:16 +1000 (from peter@cyklop.volvo.se) Received: by mail.swip.net (5.65c8-/1.2) id AA21127; Mon, 16 Aug 1993 16:33:09 +0200 Message-Id: <199308161433.AA21127@mail.swip.net> Received: from cyklop.volvo.se by volvo.volvo.se with SMTP (15.11/15.6) id AA18615; Mon, 16 Aug 93 16:31:46 met Received: by cyklop.volvo.se (16.8/16.2) id AA09508; Mon, 16 Aug 93 16:31:41 +0200 From: Peter Hakanson Subject: Re: embedding link-layer addresses in IPng addresses (fwd,again) To: big-internet@munnari.oz.au Date: Mon, 16 Aug 93 16:31:40 METDST Mailer: Elm [revision: 70.30] > > > > > However there are other real world problems that cannot be solved this > > simple way without embedding 2, or 3, large cloud subnet address in the > > internet address. > > > > It's late, and my brain is not working well, but in all the cases I can come > > up with, the extra WAN addresses which are needed are those of routers. If > > routers' internet addresses contained their WAN addresses, wouldn't the > > excahneg of router internet addresses give you all the WAN addresses you need? > > The only WAN address which the routers will not already have is the one for > > the destination interface, and that's the one which is being used in the > > destination internetwork address. > > Stuff Deleted to save bandwidth > > Ahhh, technology really srikes back, in my posting i had a couple of lines with a single dot to show portion of deleted text. Guess what sendmail did ? Anyway i'll send my 5 c again (with the dots replaced by '*' * * All this rounds up to : if we put hardware dependencies (i.e. MAC X.121 or whatever) into internetaddresses, we certanly freeze our possibilitys to develop and use other types of hardware addresses (i still remember when 6 bytes a.la. 802. seemed appropiate to cover all possible computers) If we on the other hand uses internet addresses as an 'endpoint identity' totally independent of 'how to get there' we can continue to mix freely between older WAN/LAN and newer (not yet developed) ones. We can also switch between media witout telling the world so. I think that we must identify that this is basically two different addresses, used for different things. As a remote host it bears no relevance what MAC-address it has, as a (very) local, there is no need to know the internetaddress if the MAC address is known. Each has its usage, but to blur the distinction will ending up 'pissing in the soup'. Besides that, there is the importent issue of MINIMIZING address size to reduce bandwidt requirements. It's no goot with 100Mbit if 80 is used for transferring headers .... -- Peter Hakanson VolvoData Dep 2230 phone +46 31 66 74 27 From owner-Big-Internet@munnari.oz.au Tue Aug 17 01:37:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08643; Tue, 17 Aug 1993 01:37:25 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08639; Tue, 17 Aug 1993 01:37:18 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA13596; Mon, 16 Aug 93 11:37:11 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA03065; Mon, 16 Aug 93 11:39:36 EDT Message-Id: <9308161539.AA03065@tipper> X-Really-To: gibbs.oit.unc.edu To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: Long addresses In-Reply-To: Your message of "Mon, 16 Aug 93 10:26:40 EDT." <9308161426.AA05385@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Aug 93 11:39:35 -0400 From: Simon E Spero One thing I was wondering about would be not doing a full compare of the address apart from in excpetional circumstances; the source EID should disambiguate things completely. Another alternative might be to ignore the possibilty of collisions until something goes wrong. If there is a collision, then this will be detected in a finite amount of time, and a ?CMP message could be returned indicating this fact. A flag could then be attached to that entry telling the route to perform an extra disambiguation step for that hash value. This extra check would only need to be done on those routers having different connections with the same hash value flowing through them. Simon From owner-Big-Internet@munnari.oz.au Tue Aug 17 05:58:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18389; Tue, 17 Aug 1993 05:58:53 +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 AA18385; Tue, 17 Aug 1993 05:58:39 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: rcallon@wellfleet.com, big-internet@munnari.oz.au Subject: Re: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of "Mon, 16 Aug 1993 01:21:37 -0400." <9308160521.AA25870@ginger.lcs.mit.edu> Date: Tue, 17 Aug 1993 05:58:26 +1000 Message-Id: <16694.745531106@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 Aug 93 01:21:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9308160521.AA25870@ginger.lcs.mit.edu> The only WAN address which the routers will not already have is the one for the destination interface, and that's the one which is being used in the destination internetwork address. That's certainly one way of doing it, in which case the embedded "large cloud" address is probably going to be rarely, if ever, useful, as what's usually connected to the large cloud is a router, with a LAN on the other side of it, and the end point address is the LAN address, which is just what Paul Francis said he hadn't heard of anyone suggesting. The "only embed the endpoint" isn't what most people seem to want, there is apparently a desire to embed some other address along the way. Part of the problem with all of this is that there seem to be several people who have an idea of a method to solve a problem using embedded addresses, but the actual problem that is being solved, and the way in which the embedded address will do that isn't ever (or perhaps, isn't often) made very clear. Instead we hear some vague claims that embedded addresses are useful, but I think the various people who claim this are each looking at a different use, and most of them would reject the intended uses of the others. We need some very precise proposals of exactly for what these embedded addresses would be useful, what the limitations would be, etc - only then can this be seriously considered. you'll have internetwork routers at these connection points. Why would be the addresses needed not be in the data passed around by the routing protocol? No idea, though the theory seems to be that on some of these clouds, any kind of routing protocol is too expensive, so the embedded addresses are used instead - or perhaps I've just misunderstood the intentions, that is certainly possible. that is, making use of someone else's work in assigning addresses to make our work easier. This is another reason. Given how hard it is to assign identifiers which are local to the physical network, unique within that scope, and mapped into physical addresses (e.g. IP host numbers on an Ethernet), plus all the work to manage the mapping (a lot harder on a WAN with no ARP), etc, it's not an inconsequential point. Ah, but that's not the intention, as I see it - its not the final host part that seems to be being obtained here, but the more significant parts of the address - to over simplify, something like "you already have a phone number, so your internet address is your phone number, with an extra 16 bits appended that you can use to number your hosts" (or another 48 bits if you want). That way the phone companies do address assignment for us, and the NIC can take a holiday... You must have a very different definition for the term "embedded address", since I would absolutely apply it to the case above (we are embedding a network level address, e.g. 802 or E.164, directly into an internetwork level address). Can you explain what yours is, to help disperse the confusion? For the purpose of this debate, I consider an embedded address to be a part of an address that can be extracted, and used in its own right as some other kind of address - as a MAC address in an internet address could be used when a datagram reached the final lan to avoid ARP, or ES-IS, by simply sending to the embedded MAC address, or an embedded large-cloud address could be used at the relevant point en route to determine the address of the next hop across the large cloud, and used as the cloud level address of the next router, or anything like that. The case where a MAC address forms part of an internet address simply as a way of generating unique internet addresses, or the same of cloud-addresses, or similar, but then ARP, or ES-IS, routing protocols, and whatever, are still used to actually route datagrams, pieces aren't dug out of the destination address to use as is, is quite different, and though those are clearly embedded addresses in the obvious sense of "embedded" I don't think that's what's actually being discussed here. Or is it? That is, does everyone agree that pieces of addresses should never be used for routing (or forwarding), that is distinguished from using the whole address? If not, does everyone agree that the only time a piece of an address should be used for routing/forwarding (as opposed to using the whole address) is for delivery to the final destination, as a method to avoid ARP and ES-IS? (Doth of those use the whole address as the key). If not, does everyone (anyone?) agree that what we have left is not an address, but a route? I'm not sure how you concluded that using the network level address in the interface's internetwork address, instead of some other locally-unique (hopefully :-) number you just *map into* a network level address (via ARP, tables, or whatever), changed that address into a route. Can you explain? If that's all you're doing (not that I personally consider that the right way to do anything), you're right, its not a route. However, the impression I have is that an address may consist of a sequence of sub-addresses that are applied in turn. You want the final MAC address (for whatever technology applies), others want cloud-addresses - no-one wants to admit that there ever needs to be more than one of these things, in their view of the world, but everyone seems to want a different one. kre From owner-big-internet@munnari.oz.au Tue Aug 17 06:04:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18596; Tue, 17 Aug 1993 06:05:17 +1000 (from owner-big-internet) Return-Path: Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13837; Tue, 17 Aug 1993 03:53:18 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA02123; Mon, 16 Aug 93 13:46:20 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA26969; Mon, 16 Aug 93 13:54:24 EDT Date: Mon, 16 Aug 93 13:54:24 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308161754.AA26969@cabernet.wellfleet> To: kre@munnari.OZ.AU Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov There are real world problems which can be solved very simply by embedding one (and only one) "large cloud subnet address" in the internet address. This is certainly true. However there are other real world problems that cannot be solved this simple way without embedding 2, or 3, large cloud subnet address in the internet address. And probably others that would require even more. Consider a company with a large intra organisation X.25, or Frame relay, or ATM, or this week's magic net, connecting at several places to several public data nets, which then connect to another large organisations frame relay (or whatever). If embedding the large cloud address is the right way to handle one of those clouds, then surely it must be the right way way to handle each of them. Of course, which particular large cloud addresses to embed is going to depend on where the sending system is located, which means that this "address" is really turning into a route. An address says *where* a system is, not *how to get there*. If you want to make routing efficient, then *where* a system is means "where the system is attached into the overall Internet Topology". Thus, if you have a small stub routing domain (which we are likely to see many millions of in the future), which is attached to a very large public service provider, then if you choose to embed the subnet address of the stub domain on the service provider in the address, then you are in effect saying "please consider *where* this system is in the overall Internet topology to be "hung off of this large service provider". I would expect that you would only use this method when you have very large public service providers, with at least hundreds of thousands, or more likely millions of stub domains hung off of it. Now, if there is a public service provider with this many domains attached to it, then that service provider will be large enough and important enough that other major Internet backbones will maintain a (relatively optimal) route specifically to that service provider in their routing tables. That means that it will be possible to route efficiently to that public service provider efficiently even if you have to cross several other public service providers, and have to use other methods for looking up the subnet addresses on those other service providers. The largest estimates that I have seen is that there could be on the order of billions (ie, hundreds of millions) of stub routing domains (at worst, perhaps one per house worldwide -- this is clearly a rather large estimate, but not completely absurd). Thus there could easily be a thousand or even ten thousand public service providers with something like a million customers each. However, if there are only ten thousand such large public service providers, then it is perfectly reasonable to expect that each one will maintain (via dynamic routing protocols) routes to every one of the 10,000 other public service providers, where the definition of the route includes the subnet address mappings. Thus the problem of routing across an enormous network to any one of ten million attached sites only occurs at the last hop before reaching the destination stub routing domain. Now, what if the stub domain is itself *really big*. I think that there are two possibilities here: - The *really big* stub domain is actually attached over the public service providers (ie, the presumeably very big company which owns the really big stub domain couldn't afford to run links all over the world themselves, so they attached different much smaller parts of themselves to different public service providers all over the world). In this case, I think that each part of the supposed stub domain gets declared to be its own smaller stub domain, and it takes its addressing based on where it is attached in the worldside topology. Thus the really large company does not actually look like one stub domain, but rather is a bunch of smaller stubs (which talk to each other using inter-domain routing). - The *really big* stub domain was able to run various private links all over the place, and set up a self-contained private network. It is possible that this might be based on something like ATM. Thus here we have a truely enormous private ATM network, with IP running over ATM, with this very large domain attached via IP routers to enormous public networks in multiple places around the world. Hmm, this is not an easy issue. My current feeling is that if this network is really all that large, then it will need to be declared as an private peer of the large public service providers, thus will have its own top-level address, and you route to it the same way that you route to the public service providers (I am thinking of this as flat, but if we ended up with hundreds of thousands of public service providers then we would probably need to constrain the topology of the service providers). I would like to think about this some more (I am not totally happy with any solution that I am aware of in this case). I would be inclined to suggest a rule that a large private network of this sort cannot be declared an effective peer of the public service providers unless it has at least 20,000 IP routers (on the basis that no one smaller than this need to use the embedded address solution internally). This would seem sufficient to keep the number of such sites down to a dull roar. How to enforce this is another issue, although I suppose you could do this either by refusing to give them a top level address, or by having the public service providers refuse to maintain a separate route to them in their routing tables (or charge enough to keep them from doing it -- how do commercial airports keep two-seater planes from filling up their runways, do they charge for it, or prohit it?). In other words, there will be few enough things this big that you don't mind having special mechanisms to route to them. Thus I am claiming that you don't use embedded subnet addresses for things that there are only a few tens of thousands of. You use them for things like very small businesses and individual homes that are likely to occur in the millions or billions, and which therefore are likely to be small. Add to that the expectation that other people have that the internet address will contain the end-point MAC address, as a method to avoid ARP (or similar), and you're getting to something that is likely to be very long indeed. There are proposals which suggest that an end system ID be contained in the address. This is not the same as the MAC address (although, the two might happen to have the same 48-bit value, solely for purposes of ease of configuration). The proposals that I have seen for running over Ethernets (and similar broadcast LANs) all require some sort of ARP- like resolution (although they could do this in an ES-IS "get the mapping before you see the packet" or an ARP-like "buffer the packet and ask for the mapping on demand" style -- probably which of the two to use is a worthwhile point of discussion, but is separate from what we are discussing here). Well, if you have one End System ID, plus one embedded subnet address (assuming that the embedded subnet address is something like a telephone number or an E.164 address used in public ATM networks), plus the other stuff that you might need, you end up with addresses on the order of 20 bytes long. There is some overhead here (and a good compression scheme is needed for slow links), but this is feasible. This doesn't seem rational to me - we need to find a method to do this kind of address resolution, which isn't dependant on embedding other addresses in internet addresses (which could become recursive embedding in any case, as that large cloud may just be an internet large cloud). Just because that method hasn't been found yet is not an excuse for doing something sub-standard. kre Well, "sub-standard" is a qualitative evaluation. I would not want to assume that we will come up with a better approach until we actually do (and yes I am following the ROLC work -- although I am not quite finished with the considerable reading that is required to keep up with it). I must confess that I am beginning to feel that either the ROLC work will need to come to conclusion before we choose an IPng, or we need an IPng which has addressing flexible enough to adopt to any solution (including being able to have smaller addresses if it turns out that some truely great small-address rolc solution is developed). However, if the vague rumors that I am hearing turn out to be true, then it is likely that all of the IPng proposals except TP/IX will soon have sufficiently flexible addresses. Ross From owner-Big-Internet@munnari.oz.au Tue Aug 17 13:11:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04188; Tue, 17 Aug 1993 13:11:25 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04175; Tue, 17 Aug 1993 13:11:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08315 Tue, 17 Aug 1993 13:10:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07638; Mon, 16 Aug 93 23:09:05 -0400 Date: Mon, 16 Aug 93 23:09:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308170309.AA07638@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Terminology problems Cc: jnc@ginger.lcs.mit.edu This mailing list is having severe terminology conflicts over the term "address". One person uses it in a message, assuming *their* personal definition, and someone else reads the message using a *different* personal definition, and hey presto, instant miscommunication (on the world's most powerful communication network, sigh :-). I suggest we either a) agree on one meaning to solve this, or b) stop using the term altogether. Lets not argue interminably over terminology: if, at the end of 48 hours, we don't achieve a), I will adopt b), and basically ignore all message with the term "address" in them. Here are a list of suggested terms and definitions: "address" - The structured name of an attachment point to the network. The structure is used by the routing to make its (difficult :-) job a little easier. I believe it is an inescapable truth, (and have so argued at length :-) that things which have related addresses must be topologically related, or else the routing will break down, but let's leave that for a bit. The address might or might not appear in all packets (see "f-selector"). "interface name", "i-name" - Alternative name for the above, if we don't agree to call it an "address". "forwarding selector", "f-selector" - The field in the packets which the routers look at to decide where to send the packet next. In X.25, the f-selector si the VC-ID, in IPv4, the 'destination IP address'. "host identifier", "h-id" - A name (*not* an ASCII string), probably globally unique, for a host; the current IPv4 'address' has this as one of its current functions. (Much the same as an EID, for those who understand that term.) Will the normally quiet "listeners" out there *please* speak up, if this set of terms is to your liking? If I have missed any possible meaning which is currently attached to the term 'address' by anyone, or anyone sees a use for some other term, send it in. I also suggest everyone read RFC-1498, but Saltzer, *without delay*, if you have not already done so. It provide a very clear, and *essential*, framework for all discussions of object naming in networks. Noel From owner-Big-Internet@munnari.oz.au Tue Aug 17 14:08:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06839; Tue, 17 Aug 1993 14:10:29 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06780; Tue, 17 Aug 1993 14:08:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07780; Tue, 17 Aug 93 00:08:25 -0400 Date: Tue, 17 Aug 93 00:08:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308170408.AA07780@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.oz.au Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, rcallon@wellfleet.com in which case the embedded "large cloud" address is probably going to be rarely, if ever, useful, as what's usually connected to the large cloud is a router, with a LAN on the other side of it, and the end point address is the LAN address, which is just what Paul Francis said he hadn't heard of anyone suggesting First, that's what I am suggesting; if the thing which is named is on a LAN, the low-order part of its internetwork address should be its LAN address. Second, in this scheme, the addresses of the interfaces of routers attached to an LC will have their LC address as the low order part of their internetwork addresses, thereby automagically providing this necessary info; it won't even be *possible* to talk about router X's interface to the LC without providing X's LC address. Third, I think we are gonna see more hosts attached directly to LC's in the future (reasons for so thinking supplied on request). The "only embed the endpoint" isn't what most people seem to want You are using "endpoint" to mean "the network address of the destination interface", right? ("endpoint" means somthing else to me! :-) there is apparently a desire to embed some other address along the way. Not from me. In that case, it's a (perhaps partial) source route, with the components being network (as opposed to internetwork) addresses. the actual problem that is being solved, and the way in which the embedded address will do that isn't ever (or perhaps, isn't often) made very clear. ... I think the various people who claim this are each looking at a different use, and most of them would reject the intended uses of the others. Yup. Muddy terminology only makes this worse... We need some very precise proposals of exactly for what these embedded addresses would be useful ... only then can this be seriously considered. Well, I think mine is pretty simple and clear. The low-order part of internetwork addresses would, in all but exceptional cases, be the local network physical addresses. Among the advantages are i) makes auto-configuration easier, and b) gets rid of nasty resolution problems in some cases (e.q. WAN's). the theory seems to be that on some of these clouds, any kind of routing protocol is too expensive If anyone really said this to you, they need to sit and think a bit. If there are N routers (Ri) attached to a WAN (R1.. Rn), each with some section of the internetwork topology (S1.. Sn) attached behind them, when router Rx gets a packet for something in some Sy, it has to know which Ri to send the packet to. Somebody (or somebodies) has to know which Si is behind which Ri, and get this to the things which need to know it (Rx). You can't sweep this under the rug, it will just pop up somewhere else looking just as hard, and maybe harder. Saying "oh, its in the address" doesn't work; how did it get into the address? Essentially the same information had to be passed around, and somebody had to do the same calculation, and there's just no way around it. Ah, but that's not the intention, as I see it - its not the final host part that seems to be being obtained here, but the more significant parts of the address Again, I can't speak for other schemes; certainly not in mine. I reckon it doesn't make *any* sense to obtain the *more significant* parts of the address that way; the more significant parts of the adress contain structure which is *useful to the internetwork routing*, and how can a network level address contain info which is useful to the internetwork level? It's a contradiction in terms. I consider an embedded address to be a part of an address that can be extracted, and used in its own right as some other kind of address Good definition; I'll start using it. I guess I need a new name for my "network address embedded as the low order part of the internetwork address". Hmm, nothing comes to mind - any suggestion? That is, does everyone agree that pieces of addresses should never be used for routing (or forwarding), that is distinguished from using the whole address? Rrrrr, if you have said "embedded addresses or pieces thereof", instead of "pieces of addresses", I wouldn't reject this out of hand. The problem with this concept is that it goes agains the grain of heirarchical routing, in which the routing at level K looks at the K-level field it the address to see which entity at its layer to route the traffic to. (This happens in Internet routing today, where wer first route to the IP network, then the IP subnet, etc.) I assume you didn't mean to preclude this? If not, does everyone agree that the only time a piece of an address should be used for routing/forwarding (as opposed to using the whole address) is for delivery to the final destination, as a method to avoid ARP and ES-IS? Again, same caveat as above; if so, I'd be happy to agree. If not, does everyone (anyone?) agree that what we have left is not an address, but a route? You need to be careful not to fall into the semantic argument that a hierarchical address *is* a route, since from a given source it effectively specifies a route. (I reckon this is balderdash, since the address by itself does no such thing; it only does so along with the routing tables, assuming a hop-by-hop forwarding model. In a source routing model, you don't even need that caveat.) However, leaving that pitfall to one side, a thing which contains multiple embedded addresses, other than a terminal one, especially where those addresses are intended to be extracted and used individually, is clearly a source route. However, the impression I have is that an address may consist of a sequence of sub-addresses that are applied in turn. Not for me, at least not in this form. In my perception, the topology has an abstraction naming hierarchy attached to it; things are labelled with names, things may be grouped together, and the groups named, and the process recurses. I.e., a bunch of level 0 things (i.e. physical links and switches) are grouped into a level 1 object, and a bunch of level 1 objects (and perhaps some level 0 ones as well, open question) are grouped into a level 2 object, etc, etc. Each K level object is given a name which is unique (perhaps globally, but more likely over some lesser scope, such as the enclosing K-1 level object). You can name any object, within any scope (from global on down), with an ordered list of the names of the sequence of objects, one at each level, which contain the object to be named. An "globally significant interface address" would thus contain a complete list of containing objects, one for each level, from the top level all the way down to 0. If this sounds like gobbledygook, just think of it as a good old heirarchical address, like the old net.subnet.host trio, but more general. Among other things, it allows an "globally significant object address", (I know, I know, misusing the term "address" :-) for an object at any layer K of abstraction, by listing the containing objects, one for each level, from the top down to level K. Right now, with CIDR, IPv4 addresses *by themselves* no longer have this property; only the address/mask pair together can do this. Noel From owner-Big-Internet@munnari.oz.au Tue Aug 17 17:22:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14750; Tue, 17 Aug 1993 17:22:56 +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 AA14743; Tue, 17 Aug 1993 17:22:29 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11595>; Tue, 17 Aug 1993 00:22:17 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 17 Aug 1993 00:22:09 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of "Mon, 16 Aug 93 21:08:25 PDT." <9308170408.AA07780@ginger.lcs.mit.edu> Date: Tue, 17 Aug 1993 00:21:57 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug17.002209pdt.12171@skylark.parc.xerox.com> Let me get this straight. Noel wants the capability to embed subnetwork- level addresses of devices attached to Large Clouds within the internet addresses of those devices. The benefit is that it eliminates the need for a separate address-resolution mechanism for the last hop of a delivery to any of those LC-attached devices. This seems to me to be significant only if there are a large number of LC-attached hosts (as opposed to routers). The LC-attached routers will have to run a routing protocol among themselves (to learn what destinations are reachable beyond them), and they could simply extract the subnetwork-level addresses of their peers from the routing-protocol messages they receive, i.e., it is not necessary to embed routers' subnetwork-level addresses inside their internet addresses in order to avoid a separate address-resolution step. Ross, on the other hand, is arguing that embedded addresses are useful when there are huge numbers of *routers* attached to an LC (too many to run a routing protocol among), each serving a stub domain of hosts that are *not* on the LC. He wants to embed a router's LC subnetwork address in the internet addresses of the hosts served by that router, even though the hosts themselves are not directly attached to the LC. Robert is right -- different people are arguing for different types of address embedding, for different purposes. Furthermore, Noel seems adamantly opposed to the type of embedding that Ross favors. Have I got that right? Steve From owner-big-internet@munnari.oz.au Tue Aug 17 19:06:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18864; Tue, 17 Aug 1993 19:10:39 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03151; Tue, 17 Aug 1993 12:41:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07585; Mon, 16 Aug 93 22:41:39 -0400 Date: Mon, 16 Aug 93 22:41:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308170241.AA07585@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, peter@cyklop.volvo.se Subject: Re: embedding link-layer addresses in IPng addresses (fwd,again) Cc: jnc@ginger.lcs.mit.edu if we put hardware dependencies (i.e. MAC X.121 or whatever) into internetaddresses, we certanly freeze our possibilitys to develop and use other types of hardware addresses I can't speak for others, but in my model "internetwork addresses" are variable length (for a number of reasons I won't go into here), with a flexible format, and as such it is easy to include any kind of local network address, present or future (like NSAP's do, not to say that I think NSAP's are the Right Thing :-). Standard disclaimer: I use "internetwork addresses" to mean the names of interfaces, with structure which is used by the routing, but *not* as the field which the routers look at in every packet to forward it, or even one which has to be in every packet. If we on the other hand uses internet addresses as an 'endpoint identity' totally independent of 'how to get there' Your use of the term "address" (see preceding disclaimer for my definition of this term) here appears to be more along the lines of something I will call the "fowarding selector", i.e. the data in the packet which tells intermediate routers what to do with this packet. In an X.25 network, it's the VC-ID; in IPv4, it's the destination IP address; in a flow network, it would be the flow id. If I understand you correctly, you are suggesting that we use EID's as the forwarding selector, yes? I think that we must identify that this is basically two different addresses, used for different things. As a remote host it bears no relevance what MAC-address it has, as a (very) local, there is no need to know the internetaddress if the MAC address is known. I am not at all suggesting that we use MAC addresses synonomously as EID's, or anything else. (There may be some use to being able to generate an EID from a globally unique MAC address, but this is different.) The lowest-order part of the internetwork address would be a MAC address *simply because that is the network level address* on many networks. The internetwork architecture would not (and *cannot*) make use of the fact that that MAC address is there because on other network technologies, the network address *would not* be a globally unique thing. Besides that, there is the importent issue of MINIMIZING address size to reduce bandwidt requirements. You mean, reducing the forwarding selector size to reduce bandwidth, yes? It's only necessary to reduce the internetwork address size *if* we use internetwork addresses as the fowarding selector, right? I know most people assume that is what we will use, but that assumption is not universally shared. Noel From owner-big-internet@munnari.oz.au Tue Aug 17 19:34:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19950; Tue, 17 Aug 1993 19:42:47 +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 AA12166; Tue, 17 Aug 1993 16:21:34 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13376>; Mon, 16 Aug 1993 23:21:23 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 16 Aug 1993 23:21:20 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Terminology problems In-Reply-To: Your message of "Mon, 16 Aug 93 20:09:05 PDT." <9308170309.AA07638@ginger.lcs.mit.edu> Date: Mon, 16 Aug 1993 23:21:13 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug16.232120pdt.12171@skylark.parc.xerox.com> > "address" - The structured name of an attachment point to the network. Noel, I have trouble with the "attachment point" part of your definition. Ethernet "addresses" do not identify attachment points, because if you change the point at which a computer attaches to an Ethernet cable, its address doesn't change. NSAP "addresses" also (formally) do not name attachment points. Common usage of the term "address" in networking is somwhat looser than your definition (loose enough even to allow for "multicast addresses" which certainly don't name "an attachment point"). I posted my own definition for "address" to the b-i list almost a year ago, and I'll repeat it here, even though you said you didn't like it. I think it captures the salient properties of "address" as that term is used in the computer networking field (or the postal delivery field, for that matter): An "address" is a unique label for a node or (in the case of multicast) set of nodes in an network. (This definition intentionally does not say whether or not a "node" is a box or a box's interface to a network or a "pseudo-node" representing a subnetwork; it may be any or all of those.) A "hierarchical address" is an address of the form L1, L2, ..., Ln, where: - L1 is a label for a connected region of the network. - L2 is a label for a connected region of L1. - ... - Ln is a label for a node or set of nodes in region Ln-1. A label Li is required to be unique only with region Li-1. Reminder: a region is called "connected" if there is a intra-region path from any node to every other node within the region. Note that the definition of "address" does not prevent a node from keeping its address when it "moves" in the topology (thus, for example, an Ethernet device can keep its address when it is plugged into a different point on the same cable.) With "hierarchical addresses", a node or a group of nodes may keep their addresses when they move in the topology, as long as the "connectedness" requirement is not violated. Steve From owner-Big-Internet@munnari.oz.au Tue Aug 17 21:53:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24324; Tue, 17 Aug 1993 21:57:42 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24138; Tue, 17 Aug 1993 21:53:54 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA05263; Tue, 17 Aug 93 07:53:23 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA04762; Tue, 17 Aug 93 07:55:48 EDT Message-Id: <9308171155.AA04762@tipper> X-Really-To: gibbs.oit.unc.edu To: rcallon@wellfleet.com (Ross Callon) Cc: kre@munnari.OZ.AU, big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov Subject: Re: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of "Mon, 16 Aug 93 13:54:24 EDT." <9308161754.AA26969@cabernet.wellfleet> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Aug 93 07:55:48 -0400 From: Simon E Spero The assumption that is being made here is that there will only be a few , large, service provider. I suggested one possible scenario in which this would not be the case (small entrepreneurs running links between a few cities). This is concievable for the industrialised, but might be the scenario of choice for the industrialising and post-communist world. The days of the big ANS and the death-start may be passing. Simon // The company that will bring it to you - THIS From owner-big-internet@munnari.oz.au Tue Aug 17 21:59:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24474; Tue, 17 Aug 1993 21:59:45 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10328; Tue, 17 Aug 1993 15:36:23 +1000 (from hal@mel.dit.csiro.au) Received: by shark.mel.dit.csiro.au id AA04812 (5.65c/IDA-1.4.4/DIT-1.3 for big-internet@munnari.oz.au); Tue, 17 Aug 1993 15:36:18 +1000 From: "Harold A. Miller" Message-Id: <199308170536.AA04812@shark.mel.dit.csiro.au> Subject: Re: Terminology problems To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 17 Aug 93 15:36:18 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9308170309.AA07638@ginger.lcs.mit.edu>; from "Noel Chiappa" at Aug 16, 93 11:09 pm X-Mailer: ELM [version 2.3 PL11] Noel Chiappa writes: > Message-Id: <9308170309.AA07638@ginger.lcs.mit.edu> > Subject: Terminology problems > > This mailing list is having severe terminology conflicts over the > term "address". One person uses it in a message, assuming *their* personal > definition, and someone else reads the message using a *different* personal > definition, and hey presto, instant miscommunication (on the world's most > powerful communication network, sigh :-). > I suggest we either a) agree on one meaning to solve this, or b) > stop using the term altogether. Lets not argue interminably over > terminology: if, at the end of 48 hours, we don't achieve a), I will adopt > b), and basically ignore all message with the term "address" in them. > > Here are a list of suggested terms and definitions: > > "address" - The structured name of an attachment point to the network. The > structure is used by the routing to make its (difficult :-) job a > little easier. I believe it is an inescapable truth, (and have so > argued at length :-) that things which have related addresses must > be topologically related, or else the routing will break down, but > let's leave that for a bit. The address might or might not appear > in all packets (see "f-selector"). > > "interface name", "i-name" - Alternative name for the above, if we don't agree > to call it an "address". > > "forwarding selector", "f-selector" - The field in the packets which the > routers look at to decide where to send the packet next. In X.25, > the f-selector si the VC-ID, in IPv4, the 'destination IP address'. > > "host identifier", "h-id" - A name (*not* an ASCII string), probably > globally unique, for a host; the current IPv4 'address' has this as > one of its current functions. (Much the same as an EID, for those > who understand that term.) > > Will the normally quiet "listeners" out there *please* speak up, if > this set of terms is to your liking? If I have missed any possible meaning > which is currently attached to the term 'address' by anyone, or anyone sees a > use for some other term, send it in. Here's an "almost-always-quiet-but-active listener" saying "I agree". This problem has often confused me. Overall, I like your suggestions. Within the context of IPng and Big-Internet. My personal view comes from above IP and my definition of "attachment point to the network" tends to be more cloudy (no pun intended), but within the context of this group, I like the above. A question regarding your H-ID. My first inclination is to use "EID", but I suspect that this would just reopen a whole bunch of questions from some months ago, in other words re-start the debate. However, will we end up seeing the same debate over this term? Or is this just to be a "place-holder" term for the classification of issues regarding EIDs? PS - Thanks for the continual flow of info. I find it very relevant to what I'm playing around with in my spare time (highly dynamic networks). -- |Hal.Miller@mel.dit.CSIRO.AU (HAM10) | Facilities and Network Manager | |CSIRO Division of Information Technology | Facilities Management Project | |723 Swanston Street | (TEL) +61 3 282 2628 | |Carlton, VIC 3053, Australia | (FAX) +61 3 282 2600 | From owner-big-internet@munnari.oz.au Tue Aug 17 22:30:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25215; Tue, 17 Aug 1993 22:30:37 +1000 (from owner-big-internet) Return-Path: Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12622; Tue, 17 Aug 1993 16:31:49 +1000 (from peter@cyklop.volvo.se) Received: by mail.swip.net (5.65c8-/1.2) id AA19483; Tue, 17 Aug 1993 08:31:40 +0200 Message-Id: <199308170631.AA19483@mail.swip.net> Received: from cyklop.volvo.se by volvo.volvo.se with SMTP (15.11/15.6) id AA22117; Tue, 17 Aug 93 08:14:40 met Received: by cyklop.volvo.se (16.8/16.2) id AA15363; Tue, 17 Aug 93 08:14:39 +0200 From: Peter Hakanson Subject: Re: embedding link-layer addresses in IPng addresses To: big-internet@munnari.oz.au Date: Tue, 17 Aug 93 8:14:38 METDST Mailer: Elm [revision: 70.30] > > if we put hardware dependencies (i.e. MAC X.121 or whatever) into > internetaddresses, we certanly freeze our possibilitys to develop > and use other types of hardware addresses > > I can't speak for others, but in my model "internetwork addresses" are > variable length (for a number of reasons I won't go into here), with a > flexible format, and as such it is easy to include any kind of local network > address, present or future (like NSAP's do, not to say that I think NSAP's > are the Right Thing :-). Well, since the MACaddress are local i see no point in exposing them to the outer network (much less waist bandwidth on transfering) I do belive in 'information hiding' even in networking. The opposit, to export all kind of information (and rely on it when received) forces administrative burdons, and , if mistakes are done, can propagate and poison a large portion of the network. I also belive in a limited bandwidth. And that a great proportion of the traffic is small packet where headers inc addresses is a large percentage. To conserve bandwidth i would prefer as small headers as possible. The reason i put my 5 c is that this point of view was NOT discussed. Of cource we should design a good successor to IP, but we do not have to make it stand 50 years, if it can function the following 10-20 years AND after that, be extended in a transparant way would be enough. If someone wizer then me could come up with a addressing schenario where addresses could grow larger the more distant the peer is, we may reach this, for example use 1 byte address for a peer on the same lan, but use proportionaly longer the more distant (more hops) a peer resides. But i we are looking at the same set of problems noel, i very much hope we reach a good solution BEFORE market forces switches to - XNS ? Reagards -- Peter Hakanson VolvoData Dep 2230 phone +46 31 66 74 27 From owner-Big-Internet@munnari.oz.au Wed Aug 18 01:42:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02203; Wed, 18 Aug 1993 01:44:38 +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 AA02026; Wed, 18 Aug 1993 01:42:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15245; Tue, 17 Aug 93 11:38:39 -0400 Date: Tue, 17 Aug 93 11:38:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308171538.AA15245@ginger.lcs.mit.edu> To: Hal.Miller@mel.dit.csiro.au, jnc@ginger.lcs.mit.edu Subject: Re: Terminology problems Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu my definition of "attachment point to the network" tends to be more cloudy Just think of it as "the place the last-hop router has to send the packets". A question regarding your H-ID. My first inclination is to use "EID", but I suspect that this would just reopen a whole bunch of questions from some months ago ... Or is this just to be a "place-holder" term for the classification of issues regarding EIDs? The "host identifier" is there as a practical recognition of the fact that we do need names (in the sense of indentifiers, not 'string-names', which we already have, although not at the internetwork layer) for hosts, as well as interfaces. However, it's just a technical term I am defining, not a recommendation for a particular actual mechanism; I also make no statement about what these host identifiers look like. In practise, yes, I would go for "endpoint identifiers" (EID's), which I have precisely defined in both form and function (only question left is 48 or 64 bits :-), but the difference between an "endpoint" and a "host" is pretty deep theology, so I've backed off to using the simpler term for now, since everyone has a good handle on what a "host" is. Noel From owner-Big-Internet@munnari.oz.au Wed Aug 18 02:33:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03800; Wed, 18 Aug 1993 02:35:15 +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 AA03771; Wed, 18 Aug 1993 02:33:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15558; Tue, 17 Aug 93 12:33:44 -0400 Date: Tue, 17 Aug 93 12:33:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308171633.AA15558@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: jnc@ginger.lcs.mit.edu Noel wants the capability to embed subnetwork-level addresses of devices attached to Large Clouds within the internet addresses of those devices. Not just LC interfaces; the physical subnetwork-level address of any interface, be it LAN, WAN, whatever. The benefit is that it eliminates the need for a separate address-resolution mechanism for the last hop of a delivery This is not the only benfit. This seems to me to be significant only if there are a large number of LC-attached hosts (as opposed to routers.) Nobody can say for sure if the future will look like this or not. Noel seems adamantly opposed to the type of embedding that Ross favors. Noel has been cogitating on Ross' idea. I understand what Ross is trying to do, and why; I don't think I agree with it, but it's not totally loony. It has something of the flavor of Dave Clark's "route fragments". I will reply to Ross shortly. Noel From owner-Big-Internet@munnari.oz.au Wed Aug 18 03:33:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05617; Wed, 18 Aug 1993 03:34: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 AA05555; Wed, 18 Aug 1993 03:33:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15918; Tue, 17 Aug 93 13:33:15 -0400 Date: Tue, 17 Aug 93 13:33:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308171733.AA15918@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, peter@cyklop.volvo.se Subject: Re: embedding link-layer addresses in IPng addresses Cc: jnc@ginger.lcs.mit.edu Well, since the MACaddress are local i see no point in exposing them to the outer network (much less waist bandwidth on transfering) First, to refer to host X outside the area Y to which it is local, you need some name longer than "Y". Whether that extension is a smallish number, which is locally unique only inside Y, or X's MAC (e.g.) address is a minor matter; in either case *some* local information has to be exported. Second, as far as bandwidth goes, if you carefully examine the message you were replying to here, you will see that I do agree it is reasonable to want to minimize the size of the "forwarding selector"; however, to me, it does not at all follow from this that internetwork addresses (using the definition I have in the message) cannot contain MAC addresses! I also belive in a limited bandwidth. I see. Don't you think this is a bit like micro-processor designers doing a processor architecture with a 24-bit address space, since "memory is limited"? And that a great proportion of the traffic is small packet where headers inc addresses is a large percentage. To conserve bandwidth i would prefer as small headers as possible. See my comment above about "forwarding selectors". The reason i put my 5 c is that this point of view was NOT discussed. Well, I can't speak for others, but I didn't discuss it since I didn't see anything to disagree with; headers should be, on average, as small and easy to process as possible. we should design a good successor to IP ... if it can function the following 10-20 years AND after that, be extended in a transparant way would be enough. What you blithely speak of as "extended in a transparent way" can be unbelievably hard in practise. IPng is supposed to be a "transparent extension" to IPv4, but if it's so easy, where's the trivial transition plan? Tuba plans on dual-stacking all hosts, and SIP has this really hairy packet munging, etc, etc. If someone wizer then me could come up with a addressing schenario where addresses could grow larger the more distant the peer is, we may reach this, for example use 1 byte address for a peer on the same lan, but use proportionaly longer the more distant (more hops) a peer resides. Funny you should mention this. I don't mean to blow my own horn, but the "bottom up" addresses in Nimrod have *exactly* this property (only they aren't quite so short for local peers). Noel From owner-big-internet@munnari.oz.au Wed Aug 18 09:24:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15199; Wed, 18 Aug 1993 09:27:36 +1000 (from owner-big-internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00839; Wed, 18 Aug 1993 01:06:41 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA07193; Tue, 17 Aug 93 10:59:27 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA27287; Tue, 17 Aug 93 11:07:34 EDT Date: Tue, 17 Aug 93 11:07:34 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308171507.AA27287@cabernet.wellfleet> To: ses@tipper.oit.unc.edu Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, rcallon@wellfleet.com The assumption that is being made here is that there will only be a few , large, service provider. I suggested one possible scenario in which this would not be the case (small entrepreneurs running links between a few cities). This is concievable for the industrialised, but might be the scenario of choice for the industrialising and post-communist world. The days of the big ANS and the death-start may be passing. Simon; My guess is that we will end up with both: A small number of extremely large providers, and a larger number of smaller providers (I doubt that the big guys are about to fade away). There are (at least) two issues tied in here: - For smaller service providers, how do you route and do address resolution over the small provider (to customers of the provider). This is the question that I am proposing *very large* providers might choose to solve by a solution which embeds a subnet address in an IP-level address (at least I think that this is one solution that should be considered seriously along with other solutions). For smaller providers, I think that this problem just got a lot easier. Thus the other possible solutions might become more attractive in the *little provider* case than in the case of very large providers. - Small providers imply the possibility of a very large number of providers. If there are a very large number of small providers, how do you route between them (ie, how do you get the packet to the correct provider in the first place). I think that this is somewhat separate from the problem of address resolution over very large providers. If there are more than 10,000 or perhaps 100,000 public service providers worldwide (which I agree is not completely unreasonable) then I think that the providers, or some subset of the providers, are going to have to get together and come up with some sort of hierarchical arrangement of the providers. We could imagine a solution in which there are many thousands of providers in South America. Of these a small number of large and/or "backbone" providers may be known outside of the continent (ie, the other providers in other parts of the world maintain specific routes for this small number of large and backbone South American providers). The smaller providers would then use an address prefix from one of the South American backbone providers, or would use a prefix based on some group of South American backbones. Ross From owner-big-internet@munnari.oz.au Wed Aug 18 14:02:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24709; Wed, 18 Aug 1993 14:05:30 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03311; Wed, 18 Aug 1993 02:26:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15490; Tue, 17 Aug 93 12:23:17 -0400 Date: Tue, 17 Aug 93 12:23:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308171623.AA15490@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Terminology problems Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I have trouble with the "attachment point" part of your definition. Errr, I'm just using Saltzer's phrase. If you can come up with a crisp term for "the place the last-hop router has to send the packets", I'd happily use it instead! Ethernet "addresses" do not identify attachment points, because if you change the point at which a computer attaches to an Ethernet cable, its address doesn't change. Yes, terminology again! I certainly don't mean the place you are plugged into the wire. :-) If you think of hosts as "attached" to the "(inter)network" through "interfaces", then the interface becomes the "(inter)network attachment point" for the host. NSAP "addresses" also (formally) do not name attachment points. True. Formally, they name a somewhat mobile service interface point; i.e. the interface between the internet layer (CLNP) and the clients above it. (It took me forever to understand this because of ISO-speak! :-) However, I consider the fact that they don't name interfaces a bug... Common usage of the term "address" in networking is somwhat looser than your definition Yes, it is used to refer to many different things, and it's precisely this *set* of meanings/functions which is causing confusion as various people attempt to talk about designs in which those meanings/functions are sometimes *separated* into different mechanisms.... hence the need for a crisper definition! If we can't come up with one, we will have to effectively stop using the term. The meaning I prefer is rooted in the original meaning of the term in the real world, where "708 East Woodland" refers to this place in the (physical) topology, no matter whether I or someone else lives here, and no matter whether this house or another is on the lot. An address names a *place*. loose enough even to allow for "multicast addresses" which certainly don't name "an attachment point" Yup. Then again, I prefer the name "multicast group id" for this idea, for precisely that reason. Just because the internetwork layer allows you to specify a multicast group as the destination of a packet, it doesn't mean that group has what I think of as an "address"; it clearly doesn't, since it's in many different places. An "address" is a unique label for a node or (in the case of multicast) set of nodes in an network. (This definition intentionally does not say whether or not a "node" is a box or a box's interface to a network or a "pseudo-node" representing a subnetwork; it may be any or all of those.) This is a consistent definition, but I wonder how useful it is. It seems to me this definition is little different from a "unique name" (as Saltzer uses the latter term). Under this definition, a DNS name is an "address". Does this match your mental model of an "address"? This is just a guess, but perhaps what you meant was "An "address" is a unique label for a node or set of nodes in an network, where that label can be used as the destination specifier in an internetwork datagram"? Even so, suppose we wish to create a system where, for good reason, we have separate namespaces for "boxes" and "interfaces", where the two namespace names have completely different properties. You explicitly don't differentiate between these above. Which one is the "address"? Are they both "addresses"? A "hierarchical address" is an address of the form L1, L2, ..., Ln, where: - L1 is a label for a connected region of the network. ... a region is called "connected" if there is a intra-region path from any node to every other node within the region. I basically use this definition, but I have a minor question about the connectedness requirement. This seems to require that if area L1 becomes disjoint, one half has to pick a new value for L1, and everyone in that half has to change? I agree that addresses *have* to be related to toplogy, but I'm not sure it has to be *this* strict. Partitioned areas are a real problem, but perhaps a less draconian engineering solution is in order, such as allowing extra-regional paths for temporary partitions, or something? I don't think decreeing that there shall be enough internal connectivity that a region will never partition in practise is a reasonable alternative... Noel From owner-big-internet@munnari.oz.au Wed Aug 18 14:35:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26100; Wed, 18 Aug 1993 14:35:32 +1000 (from owner-big-internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09440; Wed, 18 Aug 1993 06:02:53 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA16784; Tue, 17 Aug 93 16:02:16 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA08973; Tue, 17 Aug 93 16:04:41 EDT Message-Id: <9308172004.AA08973@tipper> X-Really-To: gibbs.oit.unc.edu To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, peter@cyklop.volvo.se Subject: Re: embedding link-layer addresses in IPng addresses (fwd,again) In-Reply-To: Your message of "Mon, 16 Aug 93 22:41:39 EDT." <9308170241.AA07585@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Aug 93 16:04:40 -0400 From: Simon E Spero Can I just try out another definition of the a-word? An A*dress is that part of the packet header which is used by intermediate nodes to determine how to handle that packet. This is similar to Noel's definition of a forwarding selector, but can subsume things like flow-identifiers, endpoint IDs, or anything else which the route might find helpful What I'm trying to imply is that an a*ddress is not a thing, but a role played one of several different things. In fact, I'm starting to agree with Noel's suggestion that we ban the a-word from polite coversation, and use some other term - "routing information" or somesuch. Quite frankly my dear, I don't give an address Simon From owner-big-internet@munnari.oz.au Wed Aug 18 15:47:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29342; Wed, 18 Aug 1993 15:47:41 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05055; Wed, 18 Aug 1993 03:16:17 +1000 (from kasten@ftp.com) Received: by ftp.com id AA15397; Tue, 17 Aug 93 13:15:48 -0400 Date: Tue, 17 Aug 93 13:15:48 -0400 Message-Id: <9308171715.AA15397@ftp.com> To: deering@parc.xerox.com Subject: Re: Terminology problems From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au > > "address" - The structured name of an attachment point to the network. > > Noel, > > I have trouble with the "attachment point" part of your definition. > Ethernet "addresses" do not identify attachment points, because if you > change the point at which a computer attaches to an Ethernet cable, its > address doesn't change. NSAP "addresses" also (formally) do not name > attachment points. Common usage of the term "address" in networking is > somwhat looser than your definition (loose enough even to allow for > "multicast addresses" which certainly don't name "an attachment point"). Steve An Ethernet Address is not actually an address in this sense. There is no topological significance in the 48 bits assigned by the IEEE, as you point out. Perhaps we should call the things that have topological significance, structured names, etc "frotz's" so as to avoid any possible confusion with things that are today called addresses but do not fit into the model. > An "address" is a unique label for a node or (in the case of > multicast) set of nodes in an network. (This definition > intentionally does not say whether or not a "node" is a box or > a box's interface to a network or a "pseudo-node" representing > a subnetwork; it may be any or all of those.) > > A "hierarchical address" is an address of the form L1, L2, ..., Ln, > where: > > - L1 is a label for a connected region of the network. > > - L2 is a label for a connected region of L1. > > - ... > > - Ln is a label for a node or set of nodes in region Ln-1. > > A label Li is required to be unique only with region Li-1. > > Reminder: a region is called "connected" if there is a intra-region path from > any node to every other node within the region. > > Note that the definition of "address" does not prevent a node from keeping > its address when it "moves" in the topology (thus, for example, an Ethernet > device can keep its address when it is plugged into a different point on the > same cable.) With "hierarchical addresses", a node or a group of nodes may > keep their addresses when they move in the topology, as long as the > "connectedness" requirement is not violated. I agree with the basic concepts of your definition. However, I am not sure that I agree with the final paragraph -- at least as you have stated it. I would certainly say that if something moves within the region then it can keep its complete, hierarchical address. However, if something moves outside of its region, then I would contend that all bets are off. If the last label of the hierarchical address is an 802 Address then, yes, that label can be kept since, for all intents and purposes, the 802 Address is globally unique. However, if the last label of the address is just some "small" assigned number (like the host-id portion of the current IP Address) then that number may well have to change. Also, you seem to contradict yourself. In the first paragraph you state that: An "address" is a unique label for a node or (in the case of multicast) set of nodes in a network. Then later on, you state that: A label Li is required to be unique only with region Li-1. Presumably, "label Li" is the same thing as "address". Also, presumably again, the first paragraph implies global uniqueness (which would make the final paragraph -- nodes can keep addresses if they move -- work). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Wed Aug 18 16:21:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01058; Wed, 18 Aug 1993 16:21:51 +1000 (from owner-big-internet) Return-Path: Received: from [129.192.64.71] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05648; Wed, 18 Aug 1993 03:35:33 +1000 (from art@opal.acc.com) Received: by opal.acc.com (4.1/SMI-4.0) id AA03930; Tue, 17 Aug 93 10:34:04 PDT Date: Tue, 17 Aug 93 10:34:04 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9308171734.AA03930@opal.acc.com> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: embedding link-layer addresses in IPng addresses I'll probably regret taking the time to step into one of these seemingly endless threads, but nonetheless... >Let me get this straight. Noel wants the capability to embed subnetwork- >level addresses of devices attached to Large Clouds within the internet >addresses of those devices. The benefit is that it eliminates the need for > a separate address-resolution mechanism for the last hop of a delivery to >any of those LC-attached devices. This seems to me to be significant only >if there are a large number of LC-attached hosts (as opposed to routers). >The LC-attached routers will have to run a routing protocol among themselves >(to learn what destinations are reachable beyond them), and they could >simply extract the subnetwork-level addresses of their peers from the >routing-protocol messages they receive, i.e., it is not necessary to embed >routers' subnetwork-level addresses inside their internet addresses in >order to avoid a separate address-resolution step. > >Ross, on the other hand, is arguing that embedded addresses are useful >when there are huge numbers of *routers* attached to an LC (too many >to run a routing protocol among), each serving a stub domain of hosts >that are *not* on the LC. He wants to embed a router's LC subnetwork >address in the internet addresses of the hosts served by that router, >even though the hosts themselves are not directly attached to the LC. I guess I don't see how this is centered around the "large cloud nets". It seems that the vast majority of devices are on multi-access networks (either broadcast or nonbroadcast) and most of these networks have a media specific, local addressing mechanism. The IP4 model defined a simple 2 level address (3 with subnets) which identified a particular subnet (link level media), but provided no explicit way to obtain the link level address which corresponded to the host part of the IP address on this subnet. For the ArpaNet, the mapping was trivial. For broadcast LANs, the invention of ARP was as workable solution, but not optimal. For NBMA nets, the solutions have been painful (mostly hand configured tables up to this point). Decnet IV went so far as changing the MAC address on Ethernets to allow for a trivial mapping. ES-IS is just a solution of the ARP Class and has problems with pay-by-packet NBMA nets. Now, in hop-by-hop datagram networks (carefully ignoring flows and connections ;>} ), two network level addresses are always important, the ultimate destination in the total network topology, and the next hop (again in terms of the network level topology). Unless source routed, the second address is always implied, and usually determined from a routing topolgy lookup. If at the last hop, the second address is the same as the destination, but still conceptually just another hop. At virtually every hop, a mapping from a next hop network level address to a link level address must be made. Luckily, this information is usually easily cacheable and the mapping may not have to be done often. Routers quickly learn of their adjacencies and can usually hold that link level address information indefinitely. But in some places, the mapping process is a major pain (large cloud nets), and in many, many places it's a minor inconvenience (ARP LANs). What appeals to me, is if by definition, that the link level address (SNPA -SubNetwork Point of Attachment in ISOese) is embedded in the network level addressess (both destination and every hop), then the mapping to the link level addresses becomes trivial (at any hop). The down side of this is that if the link level address changes, the network level address also changes. If one subscribes to Noel's concept of address (as I understand them), I'd argue that this is natural and can't be avoided (the connection point did change). Thus the desire for EID's and topics I really don't want to open. Just my $0.02, Art From owner-big-internet@munnari.oz.au Wed Aug 18 16:39:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01814; Wed, 18 Aug 1993 16:39:56 +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 AA18330; Wed, 18 Aug 1993 11:07:41 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA28772; Tue, 17 Aug 1993 21:06:11 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199308180106.AA28772@world.std.com> Subject: Re: Terminology problems To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 17 Aug 1993 21:06:11 -0400 (EDT) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9308170309.AA07638@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 16, 93 11:09:05 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2230 > > This mailing list is having severe terminology conflicts over the > term "address". One person uses it in a message, assuming *their* personal > definition, and someone else reads the message using a *different* personal > definition, and hey presto, instant miscommunication (on the world's most > powerful communication network, sigh :-). > "address" - The structured name of an attachment point to the network. The > structure is used by the routing to make its (difficult :-) job a > little easier. I believe it is an inescapable truth, (and have so > argued at length :-) that things which have related addresses must > be topologically related, or else the routing will break down, but > let's leave that for a bit. The address might or might not appear > in all packets (see "f-selector"). > This seems OK. I would like to see some terminology for (1) a piece of information in the header that is NOT embedded in the address, but helps put it in a context (e.g., an X.121 address for the local transit network) (2) some generic term for a hierarchical part of an "address" An IPv4 address, for example, has network, subnet, and host "parts." Does "address part" convey this? > > "interface name", "i-name" - Alternative name for the above, if we don't agree > to call it an "address". I have a problem with "interface name," as it is sometimes very necessary to speak of the actual hardware interface on a router, as opposed to the logical address assigned to it. "Ethernet 0" or "T1 interface 3" are useful terms when talking about real router implementations. > "forwarding selector", "f-selector" - The field in the packets which the > routers look at to decide where to send the packet next. In X.25, > the f-selector si the VC-ID, in IPv4, the 'destination IP address'. > > "host identifier", "h-id" - A name (*not* an ASCII string), probably > globally unique, for a host; the current IPv4 'address' has this as > one of its current functions. (Much the same as an EID, for those > who understand that term.) > Where would a subnetwork identifier such as an ATM cell ID, SONET channel, etc., fit? ---- Howard (fighting the editor from a hotel room) From owner-big-internet@munnari.oz.au Wed Aug 18 17:11:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02910; Wed, 18 Aug 1993 17:11:38 +1000 (from owner-big-internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08619; Wed, 18 Aug 1993 05:32:28 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09168; Tue, 17 Aug 93 15:25:22 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA27375; Tue, 17 Aug 93 15:33:30 EDT Date: Tue, 17 Aug 93 15:33:30 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308171933.AA27375@cabernet.wellfleet> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: rcallon@wellfleet.com Let me get this straight. Noel wants the capability to embed subnetwork- level addresses of devices attached to Large Clouds within the internet addresses of those devices. The benefit is that it eliminates the need for a separate address-resolution mechanism for the last hop of a delivery to any of those LC-attached devices. This seems to me to be significant only if there are a large number of LC-attached hosts (as opposed to routers). The LC-attached routers will have to run a routing protocol among themselves (to learn what destinations are reachable beyond them), and they could simply extract the subnetwork-level addresses of their peers from the routing-protocol messages they receive, i.e., it is not necessary to embed routers' subnetwork-level addresses inside their internet addresses in order to avoid a separate address-resolution step. I don't want to speak for Noel, but this is my impression also. Ross, on the other hand, is arguing that embedded addresses are useful when there are huge numbers of *routers* attached to an LC (too many to run a routing protocol among), each serving a stub domain of hosts that are *not* on the LC. He wants to embed a router's LC subnetwork address in the internet addresses of the hosts served by that router, even though the hosts themselves are not directly attached to the LC. Yes, this is correct (I think that this is a decent summary of my much longer message). However, I still need to write down in detail just what to do when one stub domain is connected to a public service provider via several routers (there are a couple of different options). Also, in the case of hosts attached directly to the public service provider, I think that I am in agreement with Noel. This could become a very important case. Robert is right -- different people are arguing for different types of address embedding, for different purposes. Furthermore, Noel seems adamantly opposed to the type of embedding that Ross favors. Have I got that right? I don't want to speak for Noel (and particularly don't want to claim that Noel is opposed to my proposal :-). Basically I think that I agree with Noel's use, but think that this will *also* be useful in the case of very many small domains attached to the public service provider via a router (or possibly even via a small number of routers). Finally, while I claim that the subnet address could usefully be embedded in the IP-level address (for example, in a CLNP address), it doesn't *have* to be embedded in the address, but could instead be somewhere else in the packet. In particular, although I find it hard to fully understand the PIP address parts (and how they are used), my gut feeling is that if I did understand PIP fully, then it should be possible to do the same thing with PIP. Ross From owner-Big-Internet@munnari.oz.au Wed Aug 18 18:39:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06451; Wed, 18 Aug 1993 18:39:59 +1000 (from owner-Big-Internet) Return-Path: Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06445; Wed, 18 Aug 1993 18:39:41 +1000 (from peter@cyklop.volvo.se) Received: by mail.swip.net (5.65c8-/1.2) id AA10546; Wed, 18 Aug 1993 10:39:36 +0200 Message-Id: <199308180839.AA10546@mail.swip.net> Received: from cyklop.volvo.se by volvo.volvo.se with SMTP (15.11/15.6) id AA28634; Wed, 18 Aug 93 10:38:23 met Received: by cyklop.volvo.se (16.8/16.2) id AA12672; Wed, 18 Aug 93 10:38:22 +0200 From: Peter Hakanson Subject: Using MAC-addresses is A loser! To: big-internet@munnari.oz.au Date: Wed, 18 Aug 93 10:38:22 METDST Mailer: Elm [revision: 70.30] I do feel a few real world exampel is needed to show additional effect of trying to embed MAC-addresses into network addresses (besides other more theoretical resons ) case 1: DECnet. Suppose You register your brand new hp/SUN/etc workstation at your local sitemanager. Your machine gets an address and a name. If the address portion includes MAC-address, the (last?) part of the address is , let's say , 080009127425 and name to cyklop.volvo.se We spread this address information (by nameservers or hostfiles or whatever your network provides). The you decide to purchase DECnet to this machine. Then your address will change !! The reason is that DEC decided to give all decnet machines (in phase 4) addresses as AA000400xxyy where xxyy is a permutation of decnet area and node address. Your address will change as a result. case 2: Hyperchannel and TCP/IP in MVS When using 7272 and MVS the topology implies that MVS has no MAC-address, and that all traffic is routed through 7272's ethernet/tr/fddi Several MVS system can be connected to the same 7272 and use one or several LANs to reach outer world. How can you distingwidge the different MVS systems connected through i 7272 if MAC-address was required in the 'logical' address ???? case 3 : Exchange of a lan board. All LAN boards of ethernet/tr/fddi has a unique 'burned in' MAC-address. If this is used as part of internet address, what happens if i replace LAN-board ? Should i have to inform a remote partner (that lacks DNS) that i have changed address ? Conclution Current technology enables us to reliefe the hard connection between an 'internet address' and the details of a particular LAN-interface. It seems to be of high value to keep this extra layer of isolation. -- Peter Hakanson VolvoData Dep 2230 phone +46 31 66 74 27 From owner-big-internet@munnari.oz.au Wed Aug 18 18:56:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07367; Wed, 18 Aug 1993 18:56:50 +1000 (from owner-big-internet) Return-Path: Received: from lynx.csis.dit.csiro.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17900; Wed, 18 Aug 1993 10:55:14 +1000 (from hughf@csis.dit.csiro.au) Received: from cetis.csis.dit.csiro.au by lynx.csis.dit.csiro.au (4.1/1.4S) id AA25936; Wed, 18 Aug 93 10:54:46 EST Received: by cetis.csis.dit.csiro.au (4.1/1.3C) id AA06452; Wed, 18 Aug 93 10:54:45 EST From: hughf@csis.dit.csiro.au Message-Id: <9308180054.AA06452@cetis.csis.dit.csiro.au> Subject: Re: emedding link-layer addresses To: big-internet@munnari.oz.au Date: Wed, 18 Aug 93 10:54:43 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] OK, one silent listener will open his mouth to reply to three messages from Noel Chiappa. Firstly, on terminology: fine with me. I liked the definitions. On this business of adding MAC addresses to internetwork addressses, on Monday 16 Aug Noel wrote: > I am not at all suggesting that we use MAC addresses synonomously as EID's, or > anything else. (There may be some use to being able to generate an EID from a > globally unique MAC address, but this is different.) The lowest-order part of > the internetwork address would be a MAC address *simply because that is the > network level address* on many networks. The internetwork architecture would > not (and *cannot*) make use of the fact that that MAC address is there because > on other network technologies, the network address *would not* be a globally > unique thing. Let me see if I've got this straight. The lowest part of an internetwork address has nothing to do with the internetwork architecture, and is to be ignored by the internetworking routers. It is being carried around in DNS tables, datagrams, flow setup packets, etc just to make the final hop easier? On Tuesday Noel wrote: > First, that's what I am suggesting; if the thing which is named is on a LAN, > the low-order part of its internetwork address should be its LAN address. > Second, in this scheme, the addresses of the interfaces of routers attached to > an LC will have their LC address as the low order part of their internetwork > addresses, thereby automagically providing this necessary info; it won't even > be *possible* to talk about router X's interface to the LC without providing > X's LC address. Third, I think we are gonna see more hosts attached directly ... > Well, I think mine is pretty simple and clear. The low-order part of > internetwork addresses would, in all but exceptional cases, be the local > network physical addresses. Among the advantages are i) makes > auto-configuration easier, and b) gets rid of nasty resolution problems in > some cases (e.q. WAN's). 1) What happens if the LAN address changes? (I remember this from the EID discussions) Under your scheme, if I want to send mail to host ginger.lcs.mit.edu, the DNS would return to me something equivalent to 18.26.0.82/xx:xx:xx:xx:xx:xx. If the packets arrive at lcs.mit.edu but you've just changed the Ethernet card in your machine, they're going to bounce until the MAC change trickles through DNS. Since most people would be annoyed at such an occurrence, I suspect that real world routers would in fact verify the MAC address before forwarding to it...say by using ARP to build a table of IP:Ethernet mappings? :-) 2) I don't believe "all but exceptional cases" will hold in the future. How many Macs with dynamically assigned AppleTalk addresses connect to the Internet? And when people start hooking up their Newtons... (Honesty does compel me to admit that while there are more Macs than Internet hosts, there are even more IPX machines, for which this would work pretty well.) I really can't see that having an embedded MAC address is more than a "might be nice to have" feature, at least for reaching hosts. Routing through ATM or whatever is something I know zip about, so I'll go back to lurking now. Hugh Fisher (Opinions are my own and don't reflect CSIS, DIT, or CSIRO policy) From owner-big-internet@munnari.oz.au Wed Aug 18 22:06:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14400; Wed, 18 Aug 1993 22:06:33 +1000 (from owner-big-internet) Return-Path: Received: from bgate.lut.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06078; Wed, 18 Aug 1993 18:31:06 +1000 (from J.P.Knight@lut.ac.uk) Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA27333; Wed, 18 Aug 93 09:25:58 BST Message-Id: <9308180825.AA27333@suna.lut.ac.uk> From: Jon Knight Subject: Novell's eye on IPng To: big-internet@munnari.oz.au Date: Wed, 18 Aug 93 9:25:58 BST X-Mailer: ELM [version 2.3 PL0 (LUT)] [I sent a message similar to this a few days ago but as I haven't seen it bounce back, I'll assume our News system (within which I read big-internet, has hosed the message. Appologies in advance if you've seen something like this before.] A friend of mine was in conversation with some guys from Novell who let slip that they intend a version of IPX to form the basis of the Internet in the future. Now, my initial reaction to this was hysterical laughter and pointed out to my friend that current IPX is not too different from IPv4 and that big-internetters have been arguing over a number of replacements, none of which look like the current IPX or come from Novell. However, I'm intrigued. Are any of the proposals supported by Novell as their next generation of IPX? If not, has anyone else heard that Novell is readying an assault on the future of the Internet? I tried to push my friend for more details but unfortunately he's a PC chap and WAN protocols (and indeed much of the Internet!) are closed books to him. I wonder if their protocol has the hooks required for per-packet charging that is so beloved of some people in some of the NREN discussion lists? :-( Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * Its not how big your share is, its how much you share that's important. * From owner-Big-Internet@munnari.oz.au Thu Aug 19 01:04:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22398; Thu, 19 Aug 1993 01:05:29 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22325; Thu, 19 Aug 1993 01:04:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22309; Wed, 18 Aug 93 10:59:44 -0400 Date: Wed, 18 Aug 93 10:59:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308181459.AA22309@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kzm@hls.com Subject: Re: Terminology problems Cc: big-internet@munnari.oz.au, deering@parc.xerox.com The original meaning is also imprecise. "708 East Woodland" has to name, not the place, but the entrance to the place, since the lot can have two entrances, the second of which might be "1225 Charleston Road". True, but if we are trying to adopt a meaning as close as possible to the original real-world one, your analogy seems to me a perfect match for having "addresses" be the "topologically structured names of interfaces"! It's a dual-homed host... err, lot! Also, if I tell you to "come visit me at 708 East Woodland", does that mean you have to enter through that particular entrance? Well, if the "1225 Charleston Road" entrance is blocked off, or guarded by a mean and surly German Shepard, it might! :-) This is the analogy to the case where we have a host with two different interfaces, one of which has a hardware limit (due to the interface) of 5 MBit/sec, and one of 50 Mbit/sec. Someone decides they need a 20MBit/sec flow to the host; without being able to individually name the interface you want the traffic to go through, you can't do this. Noel From owner-big-internet@munnari.oz.au Thu Aug 19 01:36:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23957; Thu, 19 Aug 1993 01:37:05 +1000 (from owner-big-internet) Return-Path: Received: from LANSLIDE.HLS.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02430; Wed, 18 Aug 1993 16:54:10 +1000 (from kzm@hls.com) Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA10387; Tue, 17 Aug 93 23:53:47 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA12306; Tue, 17 Aug 93 23:43:20 PDT From: kzm@hls.com (Keith McCloghrie) Message-Id: <9308180643.AA12306@nms.hls.com> Subject: Re: Terminology problems To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 17 Aug 93 23:43:19 PDT Cc: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: <9308171623.AA15490@ginger.lcs.mit.edu>; from "Noel Chiappa" at Aug 17, 93 12:23 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > The meaning I prefer is rooted in the original meaning of the term in the real > world, where "708 East Woodland" refers to this place in the (physical) >topology, no matter whether I or someone else lives here, and no matter whether > this house or another is on the lot. An address names a *place*. The original meaning is also imprecise. "708 East Woodland" has to name, not the place, but the entrance to the place, since the lot can have two entrances, the second of which might be "1225 Charleston Road". So, to say someone "lives here" implies the lot reached by either entrance. Also, if I tell you to "come visit me at 708 East Woodland", does that mean you have to enter through that particular entrance ? Keith. From owner-Big-Internet@munnari.oz.au Thu Aug 19 01:43:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24213; Thu, 19 Aug 1993 01:43:49 +1000 (from owner-Big-Internet) Return-Path: Received: from OPAL.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB24197; Thu, 19 Aug 1993 01:43:22 +1000 (from art@opal.acc.com) Received: by opal.acc.com (4.1/SMI-4.0) id AA06591; Wed, 18 Aug 93 08:43:09 PDT Date: Wed, 18 Aug 93 08:43:09 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9308181543.AA06591@opal.acc.com> To: big-internet@munnari.oz.au, hughf@csis.dit.csiro.au Subject: Re: emedding link-layer addresses > > Let me see if I've got this straight. The lowest part of an internetwork > address has nothing to do with the internetwork architecture, and is to > be ignored by the internetworking routers. It is being carried around > in DNS tables, datagrams, flow setup packets, etc just to make the final > hop easier? Other than size, how is this different that the host-part of an IP address which follows the net (and usually subnet) parts? It seems to me that in most cases today, the host part is effectively an arbitrary number assigned by some administrator, and has no topological information. In fact, in thinking back, in the DDN, the host part WAS a link level address (PSN address). Art From owner-Big-Internet@munnari.oz.au Thu Aug 19 02:57:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26291; Thu, 19 Aug 1993 02:57:55 +1000 (from owner-Big-Internet) Return-Path: Received: from FENNEL.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26288; Thu, 19 Aug 1993 02:57:40 +1000 (from fbaker@acc.com) Received: from [129.192.64.5] (COAL.ACC.COM) by fennel.acc.com (4.1/SMI-4.1) id AA29976; Wed, 18 Aug 93 09:25:05 PDT Message-Id: <9308181625.AA29976@fennel.acc.com> Date: Wed, 18 Aug 1993 09:24:52 -0800 To: big-internet@munnari.oz.au From: fbaker@acc.com (Fred Baker) X-Sender: fbaker@fennel.acc.com Subject: Re: Novell's eye on IPng >A friend of mine was in conversation with some guys from Novell who let >slip that they intend a version of IPX to form the basis of the Internet >in the future... > >However, I'm intrigued. Are any of the proposals supported by Novell as >their next generation of IPX? If not, has anyone else heard that Novell >is readying an assault on the future of the Internet? Novell is unpdating their SAP and Routing Protocols aloing the lines of IS-IS, but has made no public comments about a new IPX. From what I know of the members and inclinations of the group, I would expect that the TUBA proposal would be welcomed by them. As far as a "take over the world" perspective, I can think of a number of companys that have wanted their proprietary protocols adopted lock stock and barrel; IBM proposed SNA (several times as I recall) as an ISO standard, Xerox at one point spoke about publishing their entire networking suite, which at the time would have been a serious contender, etc. If a CLNS-based design is chosen, I think it is quite reasonable to expect Novell and others to figure out how to rehost their applications on CLNS in like manner. I don't think that would constitute taking over the world, but might constitute making the data highways accessible to them. ============================================================================= Don't blame ACC; they think I'm nuts too! ============================================================================= Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93111 From owner-big-internet@munnari.oz.au Thu Aug 19 03:03:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26515; Thu, 19 Aug 1993 03:03:57 +1000 (from owner-big-internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17010; Wed, 18 Aug 1993 23:16:27 +1000 (from kasten@ftp.com) Received: by ftp.com id AA13484; Wed, 18 Aug 93 09:16:37 -0400 Date: Wed, 18 Aug 93 09:16:37 -0400 Message-Id: <9308181316.AA13484@ftp.com> To: hcb@world.std.com, big-internet@munnari.oz.au Subject: Re: Terminology problems From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > > This seems OK. I would like to see some terminology for > (1) a piece of information in the header that is NOT > embedded in the address, but helps put it in a context > (e.g., an X.121 address for the local transit network) > (2) some generic term for a hierarchical part of an "address" > An IPv4 address, for example, has network, subnet, and > host "parts." Does "address part" convey this? I like the term that Steve Deering used in his definition of an address (which he posted yesterday). Label. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Thu Aug 19 03:43:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28065; Thu, 19 Aug 1993 03:43:57 +1000 (from owner-big-internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17012; Wed, 18 Aug 1993 23:16:38 +1000 (from kasten@ftp.com) Received: by ftp.com id AA13494; Wed, 18 Aug 93 09:16:45 -0400 Date: Wed, 18 Aug 93 09:16:45 -0400 Message-Id: <9308181316.AA13494@ftp.com> To: big-internet@munnari.oz.au Subject: Re: Terminology problems From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > A "hierarchical address" is an address of the form L1, L2, ..., Ln, > where: - L1 is a label for a connected region of the network. ... > a region is called "connected" if there is a intra-region path from > any node to every other node within the region. > > I basically use this definition, but I have a minor question about the > connectedness requirement. This seems to require that if area L1 becomes > disjoint, one half has to pick a new value for L1, and everyone in that half > has to change? I agree that addresses *have* to be related to toplogy, but I'm > not sure it has to be *this* strict. Partitioned areas are a real problem, but > perhaps a less draconian engineering solution is in order, such as allowing > extra-regional paths for temporary partitions, or something? I don't think > decreeing that there shall be enough internal connectivity that a region will > never partition in practise is a reasonable alternative... Connectedness would be the nominal state of affairs. Partitioning should be viewed as a rare condition. Therefore, the mechanisms for dealing with partitions could be relatively inefficient -- I believe that all that these mechanisms need is A) preserving the image of a connected region, B) automatic detection and "patching" of partitions (until a real repair can be effected). This implies that regions would need to be selected with some care and thought. Humans would be needed. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Thu Aug 19 04:11:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29161; Thu, 19 Aug 1993 04:11:29 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22487; Thu, 19 Aug 1993 01:07:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22385; Wed, 18 Aug 93 11:07:32 -0400 Date: Wed, 18 Aug 93 11:07:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308181507.AA22385@ginger.lcs.mit.edu> To: art@opal.acc.com, big-internet@munnari.oz.au Subject: Re: embedding link-layer addresses in IPng addresses Cc: jnc@ginger.lcs.mit.edu The down side of this is that if the link level address changes, the network level address also changes. True, but if you are on an NBMA type system you probably have to go update some databases *anyway*, it would just be a local internet->physical address translator, instead of your local DNS. Also, if you move to a different wire, the high-order part of your internet address is going to change, and there's *no way* to hide *that* change in a local translation layer. What percentage of host changes only involve changes in the MAC address? If it's a small percentage, we are trying to optimize an uncommon case, instead of building a single mechanism that will handle all cases uniformly. If the Internet had decent host auto-configuration, something is *has* to have in any case to become "more successful", wouldn't these be much easier to handle anyway? Noel From owner-big-internet@munnari.oz.au Thu Aug 19 04:21:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29501; Thu, 19 Aug 1993 04:21:13 +1000 (from owner-big-internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17732; Wed, 18 Aug 1993 23:39:16 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA03872; Wed, 18 Aug 93 09:39:12 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA10966; Wed, 18 Aug 93 09:41:37 EDT Message-Id: <9308181341.AA10966@tipper> X-Really-To: gibbs.oit.unc.edu To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: Addr* Addr*, What's an Addr*? (was Re: embedding link-layer addr... In-Reply-To: Your message of "Wed, 18 Aug 93 09:16:30 EDT." <9308181316.AA13471@ftp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Aug 93 09:41:37 -0400 From: Simon E Spero As a quick check here; how many people reading this group are also members of the URI working group? The URI group is working on defining a set of uniform resource identifiers. The first of these identifiers is the Uniform Resource Locator; this is an object which contains sufficient information to allow access to a specific instance of a resource. This document has already been completed, and is in widespread use as part of the World Wide Web. The next identifier is the Uniform Resource {Name, Number}. This is an object which can be used to compare to resources for equality, where equality is defined by the authority issuing the URN. If two URNs are not equal, then this cannot be used to infer that the resources are not equal. URNs are currently in a draft state. The final identifier under development is the Uniform Resource Citation, which encapsulates a URN, zero or more URLs, plus other, more descriptive information about the referenced resource (author, document format{s}. etc. The analogys with packet headers are fairly obvious. Simon From owner-big-internet@munnari.oz.au Thu Aug 19 04:45:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00317; Thu, 19 Aug 1993 04:45:41 +1000 (from owner-big-internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17008; Wed, 18 Aug 1993 23:16:23 +1000 (from kasten@ftp.com) Received: by ftp.com id AA13471; Wed, 18 Aug 93 09:16:30 -0400 Date: Wed, 18 Aug 93 09:16:30 -0400 Message-Id: <9308181316.AA13471@ftp.com> To: ses@tipper.oit.unc.edu, big-internet@munnari.oz.au Subject: Addr* Addr*, What's an Addr*? (was Re: embedding link-layer addr... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > An A*dress is that part of the packet header which is used by intermediate > nodes to determine how to handle that packet. By this definition, the TOS bits in the IPv4 header are an address. By this definition the Don't Fragment bit in IPv4 is an address. The thing which we are trying to name is a position on the network topology -- what I decided, yesterday, to call a Locator. A number of us feel that Locators must have a structure that enables: 1. Them to be aggregated. That is, two things which are close to each other on the network topology should have locators that have a lot in common. For example, all of the machines here at FTP Software are "close" to each other, they should have Locators that are identical save for the last one or two components ("labels" in the definition that Steve Deering posted yesterday). These last two labels would be roughly analogous to "internal subnetwork" and "host". Therefore, only the part that is common to all nodes at FTP would be advertised into the routing system. 2. The routing/forwarding processes must be able to use the Locator (or some subset of it) to get the packet going in the right direction. Noel's Forwarding Selector can be used as a shorthand description of the destination (though it would require that routers remember that F-Selector maps to destination ). Addresses, um er Locators, name places on the topology. Routes are how to get there from here. Policies allow you to select one of several routes to the same spot. For example: 2 High Street North Andover, Mass. USA 01845 is FTP's US Mail Address. The sets of roads/air-routes/trains that you use to get here from, say, New York City are the routes. Examples would be "Take the Air Shuttle to from Laguardia to Logan Airport, at Logan, get on I93 north, at thejunction with I495, get off I93 and get on I495 North. Get off at exit 42, turn right. Turn left at the first traffic light. Take the first right after the stop sign. At the end of that road, go right and immediately go left. Go through the next stop sign, we are the first building on the left." "Take Amtrak from Penn Station in NYC to South Station in Boston. Then get on I93 North and follow the same directions as from the airport." "Take the Henry Hudson/Merritt/Wilbur Cross parkway out of NYC. Get on I91 north in Ct. In Hartford, get off I91, get on I84. When I84 ends in Mass, get on the Mass Pike Eastbound. Get off the Mass Pike and get on I495 North..." Policies allow you to select one of these otherwise identical routes. A policy might be "I am afraid of flying" which lets you prune route #1 from your planned trip. It might be "I really really like trains" which means route #2 is the way to go. I want the cheapest out-of-pocket- expenses route -- which would probably select route #3. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Thu Aug 19 05:35:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01765; Thu, 19 Aug 1993 05:36:02 +1000 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26829; Thu, 19 Aug 1993 03:14:36 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA05611 (5.65c+/IDA-1.4.4); Wed, 18 Aug 1993 13:14:19 -0400 Date: Wed, 18 Aug 93 12:14:02 EDT From: "William Allen Simpson" Message-Id: <996.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: Terminology problems A note from the contrarian curmudgeon: I believe that the term "address" should be abolished (network layer and above), because it means too many things in too many different circumstances. I like many of Noel's other terms and concepts. This discussion is largely a waste of time. Those who are having it should incorporate it in their favorite IPng. We will simply grow accustomed to whatever language is used in the proposal selected. The IPng that provides the technology will provide the terminology. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Thu Aug 19 07:02:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03990; Thu, 19 Aug 1993 07:02:55 +1000 (from owner-big-internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17538; Wed, 18 Aug 1993 23:35:05 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA03540; Wed, 18 Aug 93 06:34:55 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3) id AA15861; Wed, 18 Aug 1993 09:34:52 -0400 To: Peter Hakanson Subject: Re: Using MAC-addresses is A loser! In-Reply-To: <199308180839.AA10546@mail.swip.net> References: <199308180839.AA10546@mail.swip.net> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.1 From: David Oran Date: Wed, 18 Aug 93 09:34:51 -0400 Message-Id: <930818093451.8303@sneezy.lkg.dec.com.-v> Encoding: 92 TEXT, 6 TEXT SIGNATURE > I do feel a few real world exampel is needed to > show additional effect of trying to embed MAC-addresses > into network addresses (besides other more theoretical > resons ) I feel compelled to reply to this, since I was one of the folks responsible for the address-embedding schemes used in OSI, DECnet Phase V, and others systems. I still think this is a good idea, for autoconfiguration, scalability, and many other positive benefits. > case 1: > DECnet. Suppose You register your brand new hp/SUN/etc workstation at > your local sitemanager. Your machine gets an address and a name. > If the address portion includes MAC-address, the (last?) part of the > address is , let's say , 080009127425 and name to cyklop.volvo.se > We spread this address information (by nameservers or hostfiles or whatever > your network provides). > The you decide to purchase DECnet to this machine. Then your address will > change !! The reason is that DEC decided to give all decnet machines > (in phase 4) addresses as AA000400xxyy where xxyy is a permutation > of decnet area and node address. Your address will change as a result. > As one of the designers of both DECnet Pahse IV and Phase V let me first apologize for the incredible stupidity we promulgated in Phase IV in forcing the host to change its MAC-layer station address. This was a serious design error, taken simply to avoid the routers having to implement an ARP-like LAN protocol. We have regretted it ever since and went to great lengths in Phase V (through ESIS and ISIS) to avoid a repetition of this mistake. > case 2: > Hyperchannel and TCP/IP in MVS > When using 7272 and MVS the topology implies that MVS has no > MAC-address, and that all traffic is routed through 7272's ethernet/tr/fddi > Several MVS system can be connected to the same 7272 and use one or several > LANs to reach outer world. How can you distingwidge the different MVS > systems connected through i 7272 if MAC-address was required in the > 'logical' address ???? > I'm not sure I follow this case completely, but it appears to me there are two separate problems here lurking as one, which you cannot simultaneously solve with any one scheme: 1. Multiple host systems sharing a single LAN adapter 2. One host system, *not acting as a router* attached to multiple LAN interfaces. Problem 2 is a standard "multi-homing" problem, which can only be solved in the general case by the host having multiple network layer addresses (I can go into all the failure cases when you attempt to use one network layer address for multiple attachment points and you don't participate in the routing algorithms...but I'll do so privately if needed rather than waste time on this list). Once you have multihoming, then each network layer address of the host embeds the appropriate "absolute host ID" (which is what Ethernet MAC addresses were really intended to be - see the seminal paper by Bob Printis of Xerox on the subject published in the proceedings of the 1983 Data Communications Symposium). Problem 1 is handled by either by having the LAN adapter recognize multiple MAC addresses (not difficult with today's MAC chips, which can do address filtering by CAM rather than special station address registers), or by distinguishing the host addresses at a higher level in the address. However, there are a number of tricky cases of how to make this work irrespective of the address embedding. For example, how do you know where to deliver multicasts? Does the adapter duplicate all multicasts and deliver them to both hosts? How do you make hardware-level multicast filtering work when the hosts are interested in different address sets? Who responds to XIDs? Boot requests? > case 3 : > Exchange of a lan board. > All LAN boards of ethernet/tr/fddi has a unique 'burned in' MAC-address. > If this is used as part of internet address, what happens if i replace > LAN-board ? Should i have to inform a remote partner (that lacks DNS) > that i have changed address ? Nearly all LAN boards put the address ROM on a socket. When you swap the board you move the address ROM to the new board. There are cleverer schemes as well, which involve remembering the last MAC address in the NVRAM of the host and unsing that wherever it is safe to do so (i.e. you can be sure no other machine has the ROM you got the address from plugged in.) > Conclution > Current technology enables us to reliefe the hard connection between > an 'internet address' and the details of a particular LAN-interface. > It seems to be of high value to keep this extra layer of isolation. > This misses the point. No one is suggesting using the embeddded LAN address for routing without positive protocol binding the network layer address to the data link address. The goal is not to get rid of ARP or ESIS, rather it is to allow autoconfiguration of hosts and the ability to gracefully migrate the addressing scheme of a network without having to go and touch all of the hosts by hand. Hope you find the above reflections and history useful to the discussion. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Thu Aug 19 07:42:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05098; Thu, 19 Aug 1993 07:42:55 +1000 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26838; Thu, 19 Aug 1993 03:14:52 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA05620 (5.65c+/IDA-1.4.4); Wed, 18 Aug 1993 13:14:28 -0400 Date: Wed, 18 Aug 93 12:20:47 EDT From: "William Allen Simpson" Message-Id: <997.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: embedding link-layer addresses I am convinced that embedding link-layer addresses into network-layer addresses which are maintained in any kind of persistant storage (greater than seconds) would be a disaster. This is especially true of large clouds (think phone numbers). The fact that the Internet can quickly (milliseconds) adjust to LAN hardware (IEEE) changes is a big win over other technologies (the phone company, the post office). Think of the last time you moved. As for WAN "large clouds", you have no idea which number you will get when dialing into or out of a modem pool or Primary Rate ISDN, until you make the call. For those that are proposing dial-on-demand (sometimes between telnet characters in Europe), the address in both directions will fluctuate wildly (seconds). Even at my home, you cannot depend on a particular phone number for access (I have two here, two at the lake). Recording this in a database which is persistent (DNS), over which I may have no change control, change of which requires that I am already on the network (by which time it's too late), which is not updated and referenced on the order of tens of milliseconds -- would be terrible. Forget it. Dynamic ARP/ES-IS/etc is the best way to go. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Thu Aug 19 08:24:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06244; Thu, 19 Aug 1993 08:25:11 +1000 (from owner-big-internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27380; Thu, 19 Aug 1993 03:29:20 +1000 (from 0003858921@mcimail.com) Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af19527; 18 Aug 93 17:18 GMT Date: Wed, 18 Aug 93 17:24 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Jon Knight To: big internet Subject: Re: Novell's eye on IPng Message-Id: <20930818172402/0003858921NA1EM@mcimail.com> >A friend of mine was in conversation with some guys from Novell who let >slip that they intend a version of IPX to form the basis of the Internet >in the future. NOVELL is putting the pieces together to make their own internet. They are creating their own equivalent to the IANA for registering IPX network names to the IPX routing. So there definitely will be an IPX "internet" in the future, even with the work for NETWARE IP... Bob Moskowitz From owner-big-internet@munnari.oz.au Thu Aug 19 10:39:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10923; Thu, 19 Aug 1993 10:39:33 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24870; Thu, 19 Aug 1993 02:01:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22714; Wed, 18 Aug 93 12:00:58 -0400 Date: Wed, 18 Aug 93 12:00:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308181600.AA22714@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, peter@cyklop.volvo.se Subject: Re: Using MAC-addresses is A loser! Cc: jnc@ginger.lcs.mit.edu Suppose You register your brand new hp/SUN/etc workstation ... The you decide to purchase DECnet to this machine. Then your address will change!! Your address will change as a result. Suppose you pick the machine up and move it to a different Ethernet. It's internet address will change; ARP can't help you here. This happens often enough that you have to have a mechanism to handle it. Why won't this mechanism work here too? See my comments to Art about autoconfiguration, etc. Several MVS system can be connected to the same 7272 and use one or several LANs to reach outer world. How can you distingwidge the different MVS systems connected through i 7272 if MAC-address was required in the 'logical' address ? If the internet layer had different namespsaces for hosts and interfaces, which are, after all, *very* different things, solving this cleanly would be a snap. (It's another example of a problem EID's can fix.) There are many, many, cases (multi-homed hosts, mobile hosts, etc) which would be much easier to handle if this distinction were made. See RFC-1498. All LAN boards of ethernet/tr/fddi has a unique 'burned in' MAC-address. If this is used as part of internet address, what happens if i replace LAN-board ? Should i have to inform a remote partner (that lacks DNS) that i have changed address ? This is the same case as your DECnet example. Also, I can't imagine being able to switch the cards without powering off the machine, breaking any live connections anyway. Finally, any remote partner which is trying to initiate connections, and lacks DNS, is going to be pretty useless anyway. Current technology enables us to reliefe the hard connection between an 'internet address' and the details of a particular LAN-interface. It seems to be of high value to keep this extra layer of isolation. In certain limited cases (802 LAN's), ARP allows this, at the cost of a whole extra layer of local number allocation and management. The gains in autoconfigurability alone of getting rid of this layer are worth it. In too many cases I see people trying to optimize one particular case (switching Ethernet cards) without considering i) the costs elsewhere (e.g. management configuration hassles in assigning local host-numbers) of their solution, ii) whether the solution is a local one, not globally applicable across the entire Internet, or ii) whether there's a better solution which solves not just this problem, but 7 others. Complexity has costs of its own, and sometimes it's better to have one mechanism to do 7 different fairly infrequent things, than one for each, each a little bit more efficient than the common mechanism. Look, when Dave Plummer and I designed ARP, it was simply to get around the fact that we couldn't stick a 48-bit Ethernet address into the 24 (or fewer) bits of an IP address "rest" field. Allowing you to use subnets with hosts that didn't know about subnets, swap Ethernet cards without changing any tables, etc, etc, was just a happy byproduct! ARP is not a complete, well-thought out solution to any number of tasks it is now being put to; the fact that it does some things is just an accident, and an illustration of the power of another layer of namebinding. ("All problems in computer science can be solved by another level of indirection." - Butler Lampson) That's one reason why I like EID's; it provides another naming and binding layer, but in *common way* across the *whole internet*; LAN's, WAN's, the lot. A clear look at the whole range of problems now facing us indicates, to me at least, that more generic solutions, which solve a whole range of problems in a coherent way across the entire range of internet technologies past, current, and yet to come, is far desireable to putting one more kludge onto poor old ARP. Noel From owner-big-internet@munnari.oz.au Thu Aug 19 11:02:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11976; Thu, 19 Aug 1993 11:02:20 +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 AA05922; Thu, 19 Aug 1993 08:09:43 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11561>; Wed, 18 Aug 1993 15:09:04 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 18 Aug 1993 15:08:51 -0700 To: David Oran Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Using MAC-addresses is A loser! In-Reply-To: Your message of "Wed, 18 Aug 93 06:34:51 PDT." <930818093451.8303@sneezy.lkg.dec.com.-v> Date: Wed, 18 Aug 1993 15:08:49 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug18.150851pdt.12171@skylark.parc.xerox.com> > This misses the point. No one is suggesting using the embeddded LAN address > for routing without positive protocol binding the network layer address to > the data link address. The goal is not to get rid of ARP or ESIS,... Dave, You're right, no one is suggesting that for LANs, but Ross Callon is suggesting using embedded *WAN* addresses in internet addresses precisely to get rid of the need for an address resolution protocol on the WAN. Steve From owner-Big-Internet@munnari.oz.au Thu Aug 19 21:30:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09545; Thu, 19 Aug 1993 21:30:39 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09540; Thu, 19 Aug 1993 21:30:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29486 Thu, 19 Aug 1993 14:46:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27238; Thu, 19 Aug 93 00:46:42 -0400 Date: Thu, 19 Aug 93 00:46:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308190446.AA27238@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, kasten@ftp.com, ses@tipper.oit.unc.edu Subject: Re: Addr* Addr*, What's an Addr*? (was Re: embedding link-layer addr... Cc: jnc@ginger.lcs.mit.edu The routing/forwarding processes must be able to use the Locator (or some subset of it) to get the packet going in the right direction. Noel's Forwarding Selector can be used as a shorthand description of the destination (though it would require that routers remember that F-Selector maps to destination ). Err, I would put this as: The route calculation process uses the Locator (or some subset of it) to calculate either i) the next hop, or ii) some portion of the route, depending on whether your traffic route calculation is i) hop-by-hop, or ii) more source-route oriented. For those internetworking system designs in which the destination Locator is carried in every packet, and is examined as part of the forwarding process to determine the next hop for the packet, the Locator would be part, or all, of the Forwarding Selector. What I'm after here is to break this mental congruence between "location of the thing you are delivering the packet to" and "the field in the packet which the router uses to figure out the next hop for this packet". "Address" has come to mean both, and it causes mental rigidity which is not good. I think history has caused this confusion. In 1822 HHP, and then in IPv4, the actual "address" of the destination was put into the packets as the "forwarding selector", and now the term "address" has taken on an additional meaning it didn't used to have. I'd like to undo that unfortunate (in my mind) association. Noel e same thing; map from one kind of name into another. If we really need highly dynamic ("tens of milliseconds") bindings, perhaps we should look at how to have that system provide this; it's not impossible. Noel From owner-Big-Internet@munnari.oz.au Thu Aug 19 21:36:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10116; Thu, 19 Aug 1993 21:36:19 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10113; Thu, 19 Aug 1993 21:36:14 +1000 (from atkinson@itd.nrl.navy.mil) Received: from itd.nrl.navy.mil by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20628 Thu, 19 Aug 1993 11:29:06 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05766; Wed, 18 Aug 93 21:28:58 EDT Date: Wed, 18 Aug 93 21:28:58 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9308190128.AA05766@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: Embedding MAC addresses in network addresses One case that is not common on the Internet as a whole, but is increasingly common within government sites (at least parts of NATO, probably Australia/Japan/etc as well) is where the host is using an MLS operating system (e.g. compartmented mode workstation) or has a secure network front end. In these systems it is quite possible and arguably desirable for a single _machine_ with a single _link/subnet interface_ to have multiple independent network addresses (one per sensitivity level on the machine, where "unclassified" and "secret" are examples of possible sensitivity levels). This might be done in part to limit vulnerability to traffic analysis, so embedding the MAC address into the network address would be highly undesirable for these systems. I'm not sure why this issue hasn't arisen with ISO protocols, perhaps it is because I don't know of _any_ Compartmented Mode Workstations or Multi-Level Secure computing systems that support ISO networking. I've never seen a DoD-operated computer actually using the ISO networking protocols, though clearly some must exist someplace; I've seen a whole lot of DOD computers that run IPv4. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Thu Aug 19 21:30:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09576; Thu, 19 Aug 1993 21:30:49 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09573; Thu, 19 Aug 1993 21:30:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28074 Thu, 19 Aug 1993 14:20:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27181; Thu, 19 Aug 93 00:19:32 -0400 Date: Thu, 19 Aug 93 00:19:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308190419.AA27181@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hcb@world.std.com, kasten@ftp.com Subject: Re: Terminology problems Cc: jnc@ginger.lcs.mit.edu > I would like to see some terminology for ... a hierarchical part of an > "address". Does "address part" convey this? I like the term that Steve .. used in his definition of an address.. Label. "Label" doesn't have the right ring to me for what he wants. Note that Steve used it in a different way, as an alternative for what I call a "name". "Part" works OK, and has the right connotations. I have also heard (and prefer) "element", as in "the elements of a heirarchical address". I seem to recall "field" being used as well, but "element" has this nice connotation of "list of atomic things", which is the impression you want to convey. Noel From owner-Big-Internet@munnari.oz.au Thu Aug 19 21:45:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10654; Thu, 19 Aug 1993 21:45:37 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10643; Thu, 19 Aug 1993 21:45:22 +1000 (from hcb@world.std.com) Received: from world.std.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA13340 Thu, 19 Aug 1993 21:45:18 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA22888; Thu, 19 Aug 1993 07:39:47 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199308191139.AA22888@world.std.com> Subject: Re: Terminology problems To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 19 Aug 1993 07:39:46 -0400 (EDT) Cc: big-internet@munnari.oz.au, kasten@ftp.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9308190419.AA27181@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 19, 93 00:19:32 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1617 > > > I would like to see some terminology for ... a hierarchical part of an > > "address". Does "address part" convey this? > > I like the term that Steve .. used in his definition of an address.. Label. > > "Label" doesn't have the right ring to me for what he wants. Note that Steve > used it in a different way, as an alternative for what I call a "name". > > "Part" works OK, and has the right connotations. I have also heard (and > prefer) "element", as in "the elements of a heirarchical address". I seem to > recall "field" being used as well, but "element" has this nice connotation > of "list of atomic things", which is the impression you want to convey. > > Noel > > As a one-time chemist, I think we're on the track of something! By extension, we don't want to use the term address; someone will have a network "molecule" or "structural formula" (that last one may make too much sense for a largely facetious message). A collection of addresses/molecules from different administrative domains would be a "suspension." The ratio of class A/B/C (and CIDR) assignments could be an "empirical formula." We could polarize traffic so it does or does not pass an access control list, and start calling flame wars "exothermic reactions." There actually may be some merit in fractionating traffic from different sources, or [reversibly] hydrolyzing the list-of-atominc things. Just remember, even in the big internet, if you're not part of the solution, you're part of the precipitate. :-) Howard PS--I actually _do_ think "element" is a good term for a part of a hierarchical address. From owner-Big-Internet@munnari.oz.au Thu Aug 19 23:57:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15121; Thu, 19 Aug 1993 23:57:47 +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 AA15106; Thu, 19 Aug 1993 23:57:10 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA19996; Thu, 19 Aug 93 09:54:51 -0400 Date: Thu, 19 Aug 93 09:54:51 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9308191354.AA19996@er.doe.gov> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, peter@cyklop.volvo.se Subject: Re: Using MAC-addresses is A loser! It does seem to me that there is one disadvantage to using MAC layer addresses as part of the internet address. Currently aggregating ad- dresses and masking is a powerful tool for defining subnets. If you use MAC addresses as low order partr of internet address then this will no longer work and in fact the addresses will be sparse in the low order space probably. DH From owner-Big-Internet@munnari.oz.au Thu Aug 19 23:57:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15117; Thu, 19 Aug 1993 23:57:46 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15107; Thu, 19 Aug 1993 23:57:10 +1000 (from kasten@ftp.com) Received: by ftp.com id AA23742; Thu, 19 Aug 93 09:56:33 -0400 Date: Thu, 19 Aug 93 09:56:33 -0400 Message-Id: <9308191356.AA23742@ftp.com> To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: Using MAC-addresses is A loser! From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > All LAN boards of ethernet/tr/fddi has a unique 'burned in' MAC-address. > If this is used as part of internet address, what happens if i replace > LAN-board ? Should i have to inform a remote partner (that lacks DNS) > that i have changed address ? > > This is the same case as your DECnet example. Also, I can't imagine being able > to switch the cards without powering off the machine, breaking any live > connections anyway. Finally, any remote partner which is trying to initiate > connections, and lacks DNS, is going to be pretty useless anyway. Hot-swap. Multi-processor systems where you bring down one processor/bus/cabinet of a cluster, and the process keeps running on another processer perhaps quiescent since its network connection is gone, or perhaps over another network interface card. If you have a mechanism that allows processes to migrate to different processors (in the general case) then these issues all go away. Changing a MAC interface/address would look to the rest of the network like the process has moved to a different processor/host/box/system/frotz. The processor/host/box/system/frotz's Locator is made up of a MAC Address concatenated with a set of Internetwork Labels. If you change the MAC Address part of the Locator, it could be that the MAC Interface got changed, OR the process moved to a different processor... on the same subnetwork (i.e. the Internetwork Labels stay the same, the MAC Address changes). Ergo, if you solve the general problem of moving processes around the network, then you solve this little side problem. Solving the mobile process problem would ba "A Good Thing" > In too many cases I see people trying to optimize one particular case > (switching Ethernet cards) without considering i) the costs elsewhere (e.g. > management configuration hassles in assigning local host-numbers) of their > solution, ii) whether the solution is a local one, not globally applicable > across the entire Internet, or ii) whether there's a better solution which > solves not just this problem, but 7 others. Complexity has costs of its own, > and sometimes it's better to have one mechanism to do 7 different fairly > infrequent things, than one for each, each a little bit more efficient than > the common mechanism. > > > Look, when Dave Plummer and I designed ARP, it was simply to get > around the fact that we couldn't stick a 48-bit Ethernet address into the 24 > (or fewer) bits of an IP address "rest" field. Allowing you to use subnets > with hosts that didn't know about subnets, swap Ethernet cards without > changing any tables, etc, etc, was just a happy byproduct! > ARP is not a complete, well-thought out solution to any number of > tasks it is now being put to; the fact that it does some things is just an > accident, and an illustration of the power of another layer of namebinding. > ("All problems in computer science can be solved by another level of > indirection." - Butler Lampson) That's one reason why I like EID's; it > provides another naming and binding layer, but in *common way* across the > *whole internet*; LAN's, WAN's, the lot. > A clear look at the whole range of problems now facing us indicates, > to me at least, that more generic solutions, which solve a whole range of > problems in a coherent way across the entire range of internet technologies > past, current, and yet to come, is far desireable to putting one more kludge > onto poor old ARP. Ok, let's throw some homilies around: "Early binding is the root of all evil" Jerry Saltzer (I believe) "Optimality varies according to context" Mike Padlipsky It seems to me that we should be shooting for flexibility in the addressing and routing structure. That is, we should allow a local domain to structure their Locators (or the parts of their Locator that they "own") in a manner that best suits their needs. If embedding MAC Addresses is a good thing for you, then you should be able to do it in your own little corner of the world. However, if it is a bad thing for me to do in my corner of the world, then I should not be required to do it, and I should have an alternative mechanism available to bind Internet Locators to MAC Addresses. Now, for all you who are about to tell me how wrong I am, go back and re-read the last paragraph. I did NOT say "prohibit MAC Address embedding". I did NOT say "mandate MAC Address embedding". I said "make provision for it and allow local sites to chose what is best for them". -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Fri Aug 20 01:30:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18938; Fri, 20 Aug 1993 01:30:56 +1000 (from owner-Big-Internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18920; Fri, 20 Aug 1993 01:30:20 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA08298; Thu, 19 Aug 93 11:20:41 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA27935; Thu, 19 Aug 93 11:28:57 EDT Date: Thu, 19 Aug 93 11:28:57 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308191528.AA27935@cabernet.wellfleet> To: deering@parc.xerox.com Subject: Re: Using MAC-addresses is A loser! Cc: big-internet@munnari.oz.au > This misses the point. No one is suggesting using the embeddded LAN address > for routing without positive protocol binding the network layer address to > the data link address. The goal is not to get rid of ARP or ESIS,... (Dave) You're right, no one is suggesting that for LANs, but Ross Callon is suggesting using embedded *WAN* addresses in internet addresses precisely to get rid of the need for an address resolution protocol on the WAN. (Steve) Well, my concern is that *some* large pubic WANs are going to get very big indeed, so that you could easily have 1,000,000 or more customers on the same WAN. An explicit mechanism for address resolution on such a large network is going to be difficult to make work well (and is going to be quite different from the ARP and/or ES-IS that we already are familiar with). It is not clear that embedded addresses over the WAN needs to solve 100% of all situations. If we can solve 99.9% of the lookups (small stub domains, and/or individual hosts, directly attached to the WAN) by embedded addresses, then we might want to use an address resolution protocol for the remaining more complex cases (perhaps 1,000 or 10,000 more complex domains, and other large WANs which are reached over this WAN) Thus, a basic tenant of my proposal is that an explicit lookup protocol which needs to handle 1,000 or 10,000 entries is much easier to design and operate than one which needs to handle 1,000,000 or more entries. Ross From owner-big-internet@munnari.oz.au Fri Aug 20 01:38:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19204; Fri, 20 Aug 1993 01:38:19 +1000 (from owner-big-internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09493; Thu, 19 Aug 1993 21:29:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00959 Thu, 19 Aug 1993 15:14:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27270; Thu, 19 Aug 93 01:14:45 -0400 Date: Thu, 19 Aug 93 01:14:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308190514.AA27270@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, bsimpson@morningstar.com Subject: Re: Terminology problems Cc: jnc@ginger.lcs.mit.edu I believe that the term "address" should be abolished (network layer and above), because it means too many things in too many different circumstances. I'm almost ready to second that; it just seems such a shame to loose such a nice word! I like many of Noel's other terms and concepts. As a result of the back and forth, here is an updated (and hopefully final :-) list containing various suggestions and clarifications: "interface locator" - The structured name of an interface, i.e. a host's attachment point to the internetwork. The structure is used by the routing to make its job a little easier. Things which have related locators must usually be topologically related, or else the routing will break down. The destination locator might or might not appear in all packets (see "selector"). "locator" - Alternative, short, term for the above. "locator" used on its own *always* means an "interface locator". "host locator" - Some people believe that hosts, as well as interfaces, need names which indicate where they are. This is otherwise identical to an "interface locator", but names a host, not an interface. "forwarding selector", "selector" - The field(s) in the packets which the routers look at to decide where to send the packet next. The selector might or might not be, or include, a locator. For example, in X.25, the f-selector is the VC-ID, in IPv4, the 'destination IP address'; in a flow network, it would be the flow id. "host identifier" - A name (not *necessarily* an ASCII string; i.e. not a DNS name), probably globally unique, and not a locator, for a host. The current IPv4 'address' has this as one of its current functions (e.g. in the TCP pseudo-header). Much the same as an EID, for those who understand that term. "hostname" - A DNS name. This discussion is largely a waste of time. I don't think so, actually. There were a lot of disagreements that were just plain old confusion over whether the person meant "address" in the "locator" sense, the "selector" sense, or the "hostid" sense... Since it seems to have reasonably quickly settled on some good, crisp, suggestive terms, I think it was well worth it. We will simply grow accustomed to whatever language is used in the proposal selected. The IPng that provides the technology will provide the terminology. Yes, but in the meantime, while discussing the alternatives, it's nice to have a common language to desrcribe them, and their differences, in! An exchange about "addresses" almost inevitably included a certain amount of confusion. Noel From owner-big-internet@munnari.oz.au Fri Aug 20 02:18:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20797; Fri, 20 Aug 1993 02:18:41 +1000 (from owner-big-internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12201; Thu, 19 Aug 1993 22:16:54 +1000 (from 0003858921@mcimail.com) Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bt23054; 19 Aug 93 12:04 GMT Date: Thu, 19 Aug 93 12:07 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Simon E Spero Cc: big internet Subject: The Universal Addressing scheme Message-Id: <13930819120731/0003858921NA3EM@mcimail.com> Simon E Spero said: >As a quick check here; how many people reading this group are also members >of the URI working group? The URI group is working on defining a set of >uniform resource identifiers. Hello all. I have been directed here and have been listening and reviewing for a while. It is time for the network burdened support person to speak up or forever hold his piece of the cable... The INTERNET has indeed come a long way since IPv4 was invented. So far that DNS was added, the URLs were invented. Noel's points about street addresses needs to be taken seriously. I have a number of IBM MVS systems that have AT LEAST 3 interfaces. I have a sun superserver with 200Gb disk (BTW, the smallest MVS has 360Gb and the largest 1.5Tb) with 5 interfaces, one an FDDI. We want everyone to know all of the interfaces so they are given their best chance of access, but we what them to use some modicum of 'intellegence' in selecting which one. We don't want a TELNET session to the SUN to use the FDDI, that is for buld data transfers. We want LAN users to use the IP cloud all the way to the MVS system, even when into one MVS system and SNALINK to the destination is the simplest. Then we have those nasty IBM apps that BIND dynamically, so even VTAM does not know for sure at a given point on which system the app is. It only knows its last location. So where am I going? Users always need to 'know' about APPLICATIONS in a spoken format: "get me service Y". They REALLY don't want to know about systems, and us support people do not WANT them to know about them. Like "Give me an interactive session to the Jefferson North Assembly Plant Factory Information System", that will be a 3101 connection to a S/1 (yes a S/1 in that new plant, no one wanted to rework that app). But for "Give me an interactive session to the Toledo Assembly Plant FIS" (still a Jeep, but..) is a VT220 to a VAX. And finally for "Give me an interactive session to the Bramalea FIS" is a Windows app accessing a database on a Novell server. All of these requests could have been issued by one manufacturing control person at corporate. This person knows that he has to review some factory info on each of these plants. He knows the apps. He cares less about the glue. He HATES the incompatible presentations, but he knows that we are evolving and appling our money carefully, i.e. changing as we go instead of running back and keeping all versions on the same iteration. So too must it be for the lower levels. If we follow the 'food chain' we have users requesting an application. The 'application access server' responds with a system or systems name, which gets submitted to the 'system location server'. This in turns delivers info on the many enterances to the system(s). This then has to get submitted to a 'route determiner server' that supplies info on what is reachable for how much. Then and only then is an access actually attempted base on evaluating all of the info obtained and selecting the best way to get to the best provider of the service needed. This approach lends itself to providing dynamic alternate attachments for handling outages or route degridations. And you addressing people are FREED AT LAST to design a most efficient addressing scheme. As long as you say that you must prostitute addressing schemes to the vagaries of applications, you are shackled to cobbled solutions. This URI work looks very interesting. I have read a number of the drafts. So a series of questions an proposals: Can we require additional abstractions for BigIP. Where we handle the 'old' stuff via encapsulation or re-direction. Who just gave that famous Comp Sci definition? Boy did that bring back memories of one of my profs. As a large user of networks, I agree with Ross' ideas about stubs. Right now we have a MAJOR X.25 network for our 6,000 dealers. The preferred attachment is via our private VSAT network. Yes we have the world's largest VSAT network with over 6,000 down links. Then we offer connections via X.25 VANs and finally direct dial into an 800# base X.25 PAD direct to the application. The dealer chooses which ever is 'cheapest', where time is money and money is har currency. Most small transmissions go through the VSAT. The really big stuff goes through the 800 (and charged back to the dealer). So yes, there will be lots of stubs connected via multiple points over multiple carriers. We need to know about interfaces, but we need to know about ALL interfaces and their locally defined 'cost'. Oh one other thing. We have groups of users that function as a group but are scattered accross to corp, like Personnel. So we treat them as a group and let the addressing handle the rest. Personnel in our DNS is per.chrysler.com. No matter what plant they are in... Just some random thoughts as I get packed up for INTEROP. Look for me in the black Stetson! Bob Moskowitz From owner-Big-Internet@munnari.oz.au Fri Aug 20 02:47:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21943; Fri, 20 Aug 1993 02:48:21 +1000 (from owner-Big-Internet) Return-Path: Received: from OPAL.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21904; Fri, 20 Aug 1993 02:47:40 +1000 (from art@opal.acc.com) Received: by opal.acc.com (4.1/SMI-4.0) id AA10196; Thu, 19 Aug 93 09:47:33 PDT Date: Thu, 19 Aug 93 09:47:33 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9308191647.AA10196@opal.acc.com> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov Subject: Re: Using MAC-addresses is A loser! > >It does seem to me that there is one disadvantage to using MAC layer >addresses as part of the internet address. Currently aggregating ad- >dresses and masking is a powerful tool for defining subnets. If you >use MAC addresses as low order partr of internet address then this will >no longer work and in fact the addresses will be sparse in the low order >space probably. I don't follow that. The host part in IP4 addresses is an administatively assigned number that is often allocated in a somewhat random manner. But for routing purposes, masking usually does not involve this field (considering subnet fields as separate). If we allow the host part to contain something more meaningful for that media, how have we changed what is typically done now? The higher part of the frotz (aka "address") still has hierarchical network topology meaning and can be masked down for aggregation purposes. Art From owner-Big-Internet@munnari.oz.au Fri Aug 20 03:10:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22590; Fri, 20 Aug 1993 03:10:28 +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 AA22587; Fri, 20 Aug 1993 03:10:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01562; Thu, 19 Aug 93 13:10:09 -0400 Date: Thu, 19 Aug 93 13:10:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308191710.AA01562@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, kasten@ftp.com Subject: Re: Using MAC-addresses is A loser! Cc: jnc@ginger.lcs.mit.edu If you have a mechanism that allows processes to migrate to different processors (in the general case) then these issues all go away. Changing a MAC interface/address would look to the rest of the network like the process has moved to a different processor/host/box/system/frotz. ... Ergo, if you solve the general problem of moving processes around the network, then you solve this little side problem. Solving the mobile process problem would ba "A Good Thing" Well, not just processes, but mobile hosts in general. Mobile processes are a natural generalization of mobile hosts, which is why I talk about adding "endpoint ID's" to the architecture, not "host ID's". Ok, let's throw some homilies around: "Early binding is the root of all evil" Jerry Saltzer (I believe) Ouch! A touch, I do confess... :-) we should allow a local domain to structure their Locators (or the parts of their Locator that they "own") in a manner that best suits their needs. ... "make provision for [MAC Address embedding] and allow local sites to chose what is best for them". Hmmm, in general this is true. Certainly, a general addressing structure (of the kind proposed for, say, Nimrod) already allows people to do both, and, lacking Internet Police, "anything which is possible will be done somewhere". (The "Internet Principle of Kludgery"! :-) There's nothing *stopping* people from assigning small numbers, and building their own dyunamic registry, etc. However, as an architect, it's worth thinking about the following points. - It's far less painful on the users to build a capability (i.e. highly dynamic internetwork locator -> link address binding facility) into the basic system than have to roll their own; this goes against the desire to buy off the shelf products, both for ease of support, and minimizing engineering costs through amortizing them over a large installed base, etc. - On the other hand, providing this capability system wide is going to be expensive and complicating (and complexity is bad, a priori; "Occam's Law of Design"), so unless there's no other reasonably good way to do it, and a need for it whose benfits outweigh the costs, maybe it should be left out. So, the question is: "Is the capability that these people need unavailable in any other way, and widely enough needed that the basic architecture ought to support it?" Now, go back to the first point in your message.... Noel From owner-big-internet@munnari.oz.au Fri Aug 20 07:41:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02915; Fri, 20 Aug 1993 07:41:28 +1000 (from owner-big-internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00435; Fri, 20 Aug 1993 06:37:28 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA08878; Thu, 19 Aug 93 16:37:17 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA13634; Thu, 19 Aug 93 16:39:42 EDT Message-Id: <9308192039.AA13634@tipper> X-Really-To: gibbs.oit.unc.edu To: big-internet@munnari.oz.au Subject: Net-lag on big-internet? In-Reply-To: Your message of "Thu, 19 Aug 93 09:47:33 PDT." <9308191647.AA10196@opal.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Aug 93 16:39:42 -0400 From: Simon E Spero Is it just me, or there an eight hour delay between sending mail to big-internet and recieving the result in you mail box? Australia's not on that skinny a pipe, is it? Simon From owner-big-internet@munnari.oz.au Fri Aug 20 10:34:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08762; Fri, 20 Aug 1993 10:35:10 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23908; Fri, 20 Aug 1993 03:58:24 +1000 (from kasten@ftp.com) Received: by ftp.com id AA03111; Thu, 19 Aug 93 13:58:29 -0400 Date: Thu, 19 Aug 93 13:58:29 -0400 Message-Id: <9308191758.AA03111@ftp.com> To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: Using MAC-addresses is A loser! From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > If you have a mechanism that allows processes to migrate to different > processors (in the general case) then these issues all go away. Changing > a MAC interface/address would look to the rest of the network like the > process has moved to a different processor/host/box/system/frotz. ... > Ergo, if you solve the general problem of moving processes around the > network, then you solve this little side problem. Solving the mobile > process problem would ba "A Good Thing" > > Well, not just processes, but mobile hosts in general. Mobile processes are a > natural generalization of mobile hosts, which is why I talk about adding > "endpoint ID's" to the architecture, not "host ID's". That's it! Go generalize my Generalization :-) (You are right, though.) > > Ok, let's throw some homilies around: > "Early binding is the root of all evil" Jerry Saltzer (I believe) > > Ouch! A touch, I do confess... :-) High praise indeed. Thanks. > we should allow a local domain to structure their Locators (or the parts > of their Locator that they "own") in a manner that best suits their needs. > ... "make provision for [MAC Address embedding] and allow local sites to > chose what is best for them". > > Hmmm, in general this is true. Certainly, a general addressing structure (of > the kind proposed for, say, Nimrod) already allows people to do both, and, > lacking Internet Police, "anything which is possible will be done somewhere". > (The "Internet Principle of Kludgery"! :-) There's nothing *stopping* people > from assigning small numbers, and building their own dyunamic registry, etc. > > However, as an architect, it's worth thinking about the following points. > > - It's far less painful on the users to build a capability (i.e. highly > dynamic internetwork locator -> link address binding facility) into the > basic system than have to roll their own; this goes against the desire to > buy off the shelf products, both for ease of support, and minimizing > engineering costs through amortizing them over a large installed base, etc. > > - On the other hand, providing this capability system wide is going to be > expensive and complicating (and complexity is bad, a priori; "Occam's Law > of Design"), so unless there's no other reasonably good way to do it, and > a need for it whose benfits outweigh the costs, maybe it should be left out. > > So, the question is: "Is the capability that these people need unavailable in > any other way, and widely enough needed that the basic architecture ought to > support it?" Now, go back to the first point in your message.... If I understand what you are saying then I really do not see a problem. 1. While a packet is traversing the Internetwork, you are not dealing with the last, MAC-Address, Element of the destination Locator associated with the packet (either carried in the packet or extracted from some table in the routers using the packet's Forwarding Selector as the `key'). 2. When a packet reaches its last-hop router, said router would use either: a) A Locator-to-MAC-Address binding protocol (e.g. ARP, ESIS) or manually configured tables (generally some mechanism outside of embedding the MAC Address in the locator) to convert the destination Locator to a MAC Address. This mechanism would have to be standard and an integral component of the protocol suite, just as ARP is for IPv4. b) Use the last Element of the destination Locator associated with the packet as the MAC address of the final destination of the packet. The question is how does the last-hop router know which to do? I see two possible answers: a) Manual setting of a switch in the router. Though this has the disadvantage that ALL nodes on a subnetwork must either embed the MAC address or not -- no mix and match. b) Some bit in the address indicates that a MAC address is embedded. The last hop router looks at said bit and decides what to do. This lets one mix-and-match embedded and non-embedded Locators on the same subnetwork. Naturally, this mechanism can be applied recursively to the entire Internetwork. Each intermediate hop router has to resolve the destination Locator of a packet to the Locator of the next-hop router to continue to forward the packet. The nth-hop router then has the Locator of the n+1th-hop router. It applies the same algorithm to said router's Locator -- either obtain the MAC Address outside of the Locator, or extract it from the Locator. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Fri Aug 20 12:13:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12796; Fri, 20 Aug 1993 12:14: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 AA05243; Fri, 20 Aug 1993 08:53:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03931; Thu, 19 Aug 93 18:53:07 -0400 Date: Thu, 19 Aug 93 18:53:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308192253.AA03931@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ses@tipper.oit.unc.edu Subject: Re: Net-lag on big-internet? Cc: jnc@ginger.lcs.mit.edu Is it just me, or there an eight hour delay between sending mail to big-internet and recieving the result in you mail box? Not, it's not just you. As an aid to keeping things up-to-date, can everyone please only include the relevant bits of messages you reply to, and not "bulk include" the whole thing? It'll maximize the bandwidth usage... Noel From owner-Big-Internet@munnari.oz.au Fri Aug 20 15:17:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20445; Fri, 20 Aug 1993 15:17:52 +1000 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20438; Fri, 20 Aug 1993 15:17:35 +1000 (from medin@nsipo.nasa.gov) Received: Thu, 19 Aug 93 22:17:12 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9308200517.AA14426@dscs.arc.nasa.gov> To: Simon E Spero Cc: big-internet@munnari.oz.au Subject: Re: Net-lag on big-internet? In-Reply-To: Your message of "Thu, 19 Aug 93 16:39:42 EDT." <9308192039.AA13634@tipper> Date: Thu, 19 Aug 93 22:17:12 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) I think it's just the list is big. The Australian link was recently upgraded to full T1 and is now running on a terrestrial path over PAC-RIM-EAST. It's pretty busy, but shouldn't be the problem. It's probably all those silly microcomputer mail system relays that only can accept one connection at a time being timed out... :-) Thanks, Milo From owner-Big-Internet@munnari.oz.au Fri Aug 20 21:01:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03672; Fri, 20 Aug 1993 21:01:08 +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 AA03669; Fri, 20 Aug 1993 21:01:03 +1000 (from kre@munnari.OZ.AU) To: big-internet@munnari.oz.au Subject: Re: Using MAC-addresses is A loser! In-Reply-To: Your message of "Thu, 19 Aug 1993 11:28:57 EDT." <9308191528.AA27935@cabernet.wellfleet> Date: Fri, 20 Aug 1993 21:00:52 +1000 Message-Id: <18813.745844452@munnari.OZ.AU> From: Robert Elz I'm going to reply to several messages in one reply here, for reasons that will become apparent later down. If you don't care about the topic of this message you may still want to skip down about 50 lines or so, and read tha administrative stuff that follows. Date: Thu, 19 Aug 93 11:28:57 EDT From: rcallon@wellfleet.com (Ross Callon) Message-ID: <9308191528.AA27935@cabernet.wellfleet> Well, my concern is that *some* large pubic WANs are going to get very big indeed, so that you could easily have 1,000,000 or more customers on the same WAN. I think this is likely - but I think the problem is being approached the wrong way. At the minute we have cases of a few hundred, or perhaps thousands, of connectins to a WAN, being handled in ad-hoc manners, which obviously would never scale to a million or so. From that we conclude we need a different mechanism, which doesn't look easy - overlooking the obvious. That is, that if we have a million customers connected to a WAN wanting reasonable IP?g connectivity over it, the WAN operator is going to have a big incentive to offer some real IP service over the WAN - ie: its not going to be a simple upscaling of the situation as it exists now, the circumstances will change - at that scale, we can expect the WAN vendor to do the routing over the WAN for us, and at that level we have nothing different than the internet itself, which we expect to be able to handle using regular routing protocols. If we can handle routing over WANS with 1000 or 10000 connections using some other mechanism than embedded addresses, then I suspect that will be sufficient for anything that we ever need to do. Date: Thu, 19 Aug 93 09:47:33 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9308191647.AA10196@opal.acc.com> The host part in IP4 addresses is an administatively assigned number that is often allocated in a somewhat random manner. But for routing purposes, masking usually does not involve this field (considering subnet fields as separate). If we allow the host part to contain something more meaningful for that media, how have we changed what is typically done now? We haven't - however we have made the rest of the universe both learn, and all the packets carry around, a whole lot of extra bits that are in no way useful for them, but only for the final destination - for example, here we make do quite well with just 5 bits of local information that is "randomly assigned", 30 hosts on a subnet would be way too many in any case - making the rest of the world carry around 43 unnecessary bits, just to save the occasional (very very occasional) ARP packet at the final router doesn't seem to be a very wise use of resources to me. Nor is it useful in any way for any of the rest of the world to learn our MAC addresses. Date: Thu, 19 Aug 93 16:39:42 -0400 Message-Id: <9308192039.AA13634@tipper> From: Simon E Spero Subject: Net-lag on big-internet? Is it just me, or there an eight hour delay between sending mail to big-internet and recieving the result in you mail box? Australia's not on that skinny a pipe, is it? (reply after a couple of other related messages). Date: Thu, 19 Aug 93 18:53:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308192253.AA03931@ginger.lcs.mit.edu> Not, it's not just you. As an aid to keeping things up-to-date, can everyone please only include the relevant bits of messages you reply to, and not "bulk include" the whole thing? It'll maximize the bandwidth usage... (and again, one more) Date: Thu, 19 Aug 93 22:17:12 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Message-Id: <9308200517.AA14426@dscs.arc.nasa.gov> I think it's just the list is big. The Australian link was recently upgraded to full T1 and is now running on a terrestrial path over PAC-RIM-EAST. It's pretty busy, but shouldn't be the problem. Apologies for the delays, I know they're annoying. As Milo says, bandwidth isn't the problem, while the link bandwidth was just doubled (this month) to T1, and is already starting to at least approach running out of that capacity, the bandwidth that B-I consumes, or requires, is negligible. While the plea in Noel's message is a good idea on general principles, unecessary inclusion of text people have already seen generally just annoys people, its not really going to have any effect at all on B-I - the size of the messages makes very little difference to anything (which isn't intended to be an invitation to start sending uuencoded GIF files around...) On the other hand, the number of messages, and their frequency makes a big difference, again, as Milo said, the list is getting pretty big. So, if possible, it would help things a lot if when replying to a series of messages you could send one reply to several of them, at least those on one topic, rather than individual replies to every message on which you have a comment to make. Naturally that's what I'm doing here, I excuse myself from the "on the same topic" that would normally be sensible on the grounds that I don't see any reason that anyone really needs to reply to this second part of this message, so the loss of its Subject: from the headers of this message is no real disaster. Yesterday was a bad day for munnari, which is a much overloaded host, I simply turned off mail for a good part of the day to give it a chance to catch up on other things, which certainly wouldn't have helped getting yesterday's flurry of B-I messages through. I am intending to move most of the B-I processing to another host, which doesn't have anything else useful to do with its life (its older, and slower, but there's no competition for its resources) - you may eventually receive one or two test messages when I start verifying that its all working correctly. Apologies in advance for those - ane please don't attempt to reply to them when you see them (or not to the list address that will probably appear in them, replies to me personally would be OK) as I expect I will use a very temporary fake address, related to Big-Internet (say Bigger-Internet or something) so I can test without disturbing the current list's operation, however I don't expect that address to be valid for more than the few minutes it takes me to send the test message. The address "Big-Internet@munnari.oz.au", the administrative address, "Big-Internet-Rquest@munnari.oz.au" and the location of the archives, etc, will not be altering, unless you look closely at Received headers, there should be no noticeable difference to real list messages after things change. I hope this will improve the turnaround time, both by lowering the probability that arriving messages will simply sit in a queue for hours waiting to be processed, and if things go well, by allowing me to process the list in parallel, rather than serially as is done now - currently the last people added to the list typically receive it several hours after the first people on the list get their copies. kre From owner-big-internet@munnari.oz.au Fri Aug 20 23:35:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08570; Fri, 20 Aug 1993 23:35:53 +1000 (from owner-big-internet) Return-Path: Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23358; Fri, 20 Aug 1993 16:25:42 +1000 (from peter@cyklop.volvo.se) Received: by mail.swip.net (5.65c8-/1.2) id AA14869; Fri, 20 Aug 1993 08:25:31 +0200 Message-Id: <199308200625.AA14869@mail.swip.net> Received: from cyklop.volvo.se by volvo.volvo.se with SMTP (15.11/15.6) id AA09657; Fri, 20 Aug 93 07:44:25 met Received: by cyklop.volvo.se (16.8/16.2) id AA04873; Fri, 20 Aug 93 07:44:24 +0200 From: Peter Hakanson Subject: Re: Using MAC-addresses is A loser! (fwd) To: big-internet@munnari.oz.au Date: Fri, 20 Aug 93 7:44:23 METDST Mailer: Elm [revision: 70.30] > > > > >It does seem to me that there is one disadvantage to using MAC layer > >addresses as part of the internet address. Currently aggregating ad- > >dresses and masking is a powerful tool for defining subnets. If you > >use MAC addresses as low order partr of internet address then this will > >no longer work and in fact the addresses will be sparse in the low order > >space probably. > > I don't follow that. The host part in IP4 addresses is an administatively > assigned number that is often allocated in a somewhat random manner. > But for routing purposes, masking usually does not involve this field > (considering subnet fields as separate). If we allow the host part One nice thing with current subnetting is that the dividing line between host and net IS INVISIBLE and subject to change at will. Thus a site can make a tradeoff between how many hosts per network and the number of networks. > to contain something more meaningful for that media, how have we changed > what is typically done now? The higher part of the frotz (aka "address") > still has hierarchical network topology meaning and can be masked down > for aggregation purposes. > > Art > > > -- Peter Hakanson VolvoData Dep 2230 phone +46 31 66 74 27 From owner-Big-Internet@munnari.oz.au Sat Aug 21 05:12:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23189; Sat, 21 Aug 1993 05:12:43 +1000 (from owner-Big-Internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23184; Sat, 21 Aug 1993 05:12:29 +1000 (from 0003858921@mcimail.com) Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab24809; 20 Aug 93 18:58 GMT Date: Fri, 20 Aug 93 19:02 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Using MAC-addresses is A loser! (fwd) Message-Id: <35930820190253/0003858921NA3EM@mcimail.com> >One nice thing with current subnetting is that the dividing line >between host and net IS INVISIBLE and subject to change at will. >Thus a site can make a tradeoff between how many hosts per network >and the number of networks. This is an interesting point. Here at Chrysler we have 4 B nets and a lot of C nets. Each with different masks. One B is /27, another is /26, a third is /25, and the fourth is /23. The Cs are either unsubnetted (PC lans for the most part) or /27 (data center lans where we need lots of subnets). I've had some problems with a few vendors. I've been told point blank by some that within one RIP environment I can't do this. I say BULL. We've done it and most stuff works well with it. We are, for the most part OSPF (about 6 or so admin areas), but RIP is still used on the peripheries. We made our netting decisions (except for the /23 B net; saved one powerful group $100k and cost the co close to $1M already by some estimates) based on technical criteria. It would be nice if this 'goes away'. Bob From owner-big-internet@munnari.oz.au Sat Aug 21 10:18:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05113; Sat, 21 Aug 1993 10:18: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 AA15245; Sat, 21 Aug 1993 02:07:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08081; Fri, 20 Aug 93 12:07:19 -0400 Date: Fri, 20 Aug 93 12:07:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308201607.AA08081@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, kasten@ftp.com Subject: Re: Using MAC-addresses is A loser! Cc: jnc@ginger.lcs.mit.edu >> If you have a mechanism that allows processes to migrate to different >> processors (in the general case) then these issues all go away. Changing >> a MAC interface/address would look to the rest of the network like the >> process has moved to a different processor/host/box/system/frotz. ... >> Ergo, if you solve the general problem of moving processes around the >> network, then you solve this little side problem. > So, the question is: "Is the capability that these people need > unavailable in any other way, and widely enough needed that the basic > architecture ought to support it?" Now, go back to the first point in > your message.... If I understand what you are saying then I really do not see a problem. Errr, I think you missed the point I was trying to make. Yes, we can't *stop* people from using local address resolution. We could even put in that functionality, on a consistent, system-wide basis; that way people wouldn't have to roll their own. If we're going to use it, it makes sense to mandate it. However, Dave Clark has this aphorism that "the job of an architect is to make choices". You have to decide whether the extra complexity of something is worth what it gives you. You yourself pointed out that a good mobility facility, provided by flexibility at the binding layer between hosts and interfaces, would do *everything* ARP can currently do in terms of functionality. It would also do lots more besides, since it would be a system-wide facility, not local. Given this, what are the *extra* features that a *third* layer of binding, only one restricted to a local scope, gives you? I can't think of any. The *only* advantage claimed is efficiency, and I think the savings there are pretty illusory, when compared with the complexity. Noel From owner-big-internet@munnari.oz.au Sat Aug 21 11:50:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07316; Sat, 21 Aug 1993 11:50:54 +1000 (from owner-big-internet) Return-Path: Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16255; Sat, 21 Aug 1993 02:31:43 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA14543; Fri, 20 Aug 93 12:24:32 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA28363; Fri, 20 Aug 93 12:32:52 EDT Date: Fri, 20 Aug 93 12:32:52 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308201632.AA28363@cabernet.wellfleet> To: kre@munnari.OZ.AU Subject: Re: Using MAC-addresses is A loser! Cc: big-internet@munnari.oz.au, rcallon@wellfleet.com Date: Thu, 19 Aug 93 11:28:57 EDT From: rcallon@wellfleet.com (Ross Callon) Message-ID: <9308191528.AA27935@cabernet.wellfleet> Well, my concern is that *some* large pubic WANs are going to get very big indeed, so that you could easily have 1,000,000 or more customers on the same WAN. I think this is likely - but I think the problem is being approached the wrong way. At the minute we have cases of a few hundred, or perhaps thousands, of connections to a WAN, being handled in ad-hoc manners, which obviously would never scale to a million or so. Yes. ...From that we conclude we need a different mechanism, which doesn't look easy - overlooking the obvious. That is, that if we have a million customers connected to a WAN wanting reasonable IP?g connectivity over it, the WAN operator is going to have a big incentive to offer some real IP service over the WAN - ie: its not going to be a simple upscaling of the situation as it exists now, the circumstances will change - at that scale, we can expect the WAN vendor to do the routing over the WAN for us, and at that level we have nothing different than the internet itself, which we expect to be able to handle using regular routing protocols. Do you mean that a large public WAN based on ATM should use switches which understand IP addresses, or that the same organization which runs the ATM WAN should also run a mesh of IP/IPng routers which run IP and IPng service over top of the WAN? If we can handle routing over WANS with 1000 or 10000 connections using some other mechanism than embedded addresses, then I suspect that will be sufficient for anything that we ever need to do. I agree with you that it would be very desireable for very large WANs to support IP (and IPng) directly. I tend to think that this means that the internal switches in the WAN should essentially know how to route IP much as if they were IP routers. Thus, if we can build a large IP or IPng internet that handles 1,000,000 domains over a mesh (with routers arranged into areas, with each router having a "reasonable" number of neighbors -- much less than 1,000,000), then we can also build a public network which is internally aware of IP and/or IPng and routes efficiently to 1,000,000 stub domains. The notion of having the switches understand IP was proposed at the ATM forum (and also at the IETF) as a way to handle IP over ATM. However, this idea was not accepted. From my somewhat biased point of view (in favor of the proposal), I interpreted the discussion as many folks feeling that ATM switches should be separated from IP (and other similar protocols). Thus, it appears that folks who are thinking of building large ATM public networks are also thinking of building large ATM public networks in which the switches are not aware of IP addresses. I am not sure that this is a good thing, but I think that we need to figure out how to deal with this. There is also the possibility of wanting to route IPng to large numbers of sites over the plain old telephone service. Now, even if the IP service is a separate offering over top of the public ATM (or POTS) WAN, having the same organization offer both does make it seem more likely that the hierarchical logical topology of the IP service will be set up to be efficiently overlaid over the physical topology of the underlying service. (and this does seem to answer the question of who is going to set up this complex structure of IP servers anyway?). Ross From owner-big-internet@munnari.oz.au Sun Aug 22 06:46:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12820; Sun, 22 Aug 1993 06:46:42 +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 AA06997; Sun, 22 Aug 1993 03:22:36 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11923>; Sat, 21 Aug 1993 10:22:03 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sat, 21 Aug 1993 10:21:51 -0700 To: rcallon@wellfleet.com (Ross Callon) Cc: kre@munnari.oz.au, big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Using MAC-addresses is A loser! In-Reply-To: Your message of "Fri, 20 Aug 93 09:32:52 PDT." <9308201632.AA28363@cabernet.wellfleet> Date: Sat, 21 Aug 1993 10:21:39 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug21.102151pdt.12171@skylark.parc.xerox.com> > Do you mean that a large public WAN based on ATM should use switches > which understand IP addresses, or that the same organization which > runs the ATM WAN should also run a mesh of IP/IPng routers which run > IP and IPng service over top of the WAN? They should run a mesh of IP/IPng routers *instead* of ATM. Steve From owner-big-internet@munnari.oz.au Mon Aug 23 03:03:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19611; Mon, 23 Aug 1993 03:04:12 +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 AA17428; Mon, 23 Aug 1993 01:55:03 +1000 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AD07783; Sun, 22 Aug 93 08:48:16 PDT Date: Sun, 22 Aug 93 08:48:16 PDT Message-Id: <9308221548.AD07783@wc.novell.com> To: bsimpson@morningstar.com From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com (Unverified) Subject: Re: embedding link-layer addresses Cc: big-internet@munnari.oz.au Bill, For some reason, the idea of imbedding the link layer address of the attachment node of end systems in the end systems' internetwork address seems reasonable to me... I am, however, a little leery of the idea of imbedding link layer addresses of intermediate hops in an end systems' internetwork address. So, >The fact that the Internet can quickly (milliseconds) adjust to LAN >hardware (IEEE) changes is a big win over other technologies (the phone >company, the post office). Think of the last time you moved. The point is not the last time you moved. The last time you moved, you got a new IP address, as well as a new phone number, as well as a new postal address. The point is, think of the last time something internal to the internet, the phone company, or the post office, moved. Greg Minshall minshall@wc.novell.com Novell, Inc. +1 510 975-4507 From owner-big-internet@munnari.oz.au Mon Aug 23 06:03:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25043; Mon, 23 Aug 1993 06:03:51 +1000 (from owner-big-internet) Return-Path: Received: from [130.57.64.11] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17366; Mon, 23 Aug 1993 01:51:55 +1000 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB07783; Sun, 22 Aug 93 08:45:08 PDT Date: Sun, 22 Aug 93 08:45:08 PDT Message-Id: <9308221545.AB07783@wc.novell.com> To: rcallon@wellfleet.com (Ross Callon) From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com (Unverified) Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au Ross, At 1:54 PM 8/16/93 -0400, Ross Callon wrote: >An address says *where* a system is, not *how to get there*. If you >want to make routing efficient, then *where* a system is means "where >the system is attached into the overall Internet Topology". Thus, if >you have a small stub routing domain (which we are likely to see many >millions of in the future), which is attached to a very large public >service provider, then if you choose to embed the subnet address of >the stub domain on the service provider in the address, then you are >in effect saying "please consider *where* this system is in the overall >Internet topology to be "hung off of this large service provider". Let's say you have a small stub routing domain, which is attached to a very large public *IP* service provider (my crystal ball being just as murky as anyone else's). Within the service provider, there is a last hop router, which has an IP address within the service provider's domain. Would you then argue that the addresses in the stub routing domain should have embedded in them the (IP) address of this last hop router of the service provider? Greg From owner-big-internet@munnari.oz.au Mon Aug 23 06:28:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26228; Mon, 23 Aug 1993 06:28:20 +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 AA17405; Mon, 23 Aug 1993 01:53:30 +1000 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AC07783; Sun, 22 Aug 93 08:46:44 PDT Date: Sun, 22 Aug 93 08:46:44 PDT Message-Id: <9308221546.AC07783@wc.novell.com> To: art@opal.acc.com (Art Berggreen) From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com (Unverified) Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au >What appeals to me, is if by definition, that the link level address >(SNPA -SubNetwork Point of Attachment in ISOese) is embedded in the >network level addressess (both destination and every hop), then the >mapping to the link level addresses becomes trivial (at any hop). >The down side of this is that if the link level address changes, the >network level address also changes. If one subscribes to Noel's concept >of address (as I understand them), I'd argue that this is natural and >can't be avoided (the connection point did change). Thus the desire >for EID's and topics I really don't want to open. Isn't it the case that an "address" is something which relates to a possibly hypothetical global topology. "Global" being that context in which the address is interpreted. "Hypothetical" meaning that maybe there was (or maybe there wasn't) a topology in which all the addresses "made sense", but at any point links being down, etc., may make the *actual* topology much different. Superimposed on this hypothetical addressing topology is an actual topology (of what is actually up, etc.). Superimposed (hopefully) on the actual topology is a routing topology (how packets travel). The job of *routing protocols* is to keep up with changes in the actual topology. (This job is, presumably, made easier or harder by the addressing scheme.) One of my concerns about the (now infamous) "Ross scheme" (of imbedding link level addresses for things above "attachment point" in the network address of the "attachment point") is that, to me, the address suggests a route in the hypothetical topology, but what is actually wanted is a route in the actual topology. (Of course, maybe i'm just looking for job security...:) Greg From owner-big-internet@munnari.oz.au Mon Aug 23 08:09:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00310; Mon, 23 Aug 1993 08:09:45 +1000 (from owner-big-internet) Return-Path: Message-Id: <9308222209.310@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29860; Mon, 23 Aug 1993 08:01:22 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa28145; 22 Aug 93 18:01 EDT To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: embedding link-layer addresses in IPng addresses In-Reply-To: Your message of Tue, 17 Aug 1993 00:21:57 -0700. <93Aug17.002209pdt.12171@skylark.parc.xerox.com> Date: Sun, 22 Aug 1993 18:01:11 -0400 From: John Curran -------- ] From: Steve Deering ] Subject: Re: embedding link-layer addresses in IPng addresses ] Date: Tue, 17 Aug 1993 00:21:57 PDT ] ] Let me get this straight. Noel wants the capability to embed subnetwork- ] level addresses of devices attached to Large Clouds within the internet ] addresses of those devices. The benefit is that it eliminates the need for ] a separate address-resolution mechanism for the last hop of a delivery to ] any of those LC-attached devices. This seems to me to be significant only ] if there are a large number of LC-attached hosts (as opposed to routers). I also see this as a desirable capability, as there is an an order of magnitude more single systems than LANs seeking Internet service. In the absence of subnetwork broadcast/multicast, being able to embed subnetwork-level addresses into the network address will save significant configuration (i.e. labor, a.k.a. $). ] Ross, on the other hand, is arguing that embedded addresses are useful ] when there are huge numbers of *routers* attached to an LC (too many ] to run a routing protocol among), each serving a stub domain of hosts ] that are *not* on the LC. He wants to embed a router's LC subnetwork ] address in the internet addresses of the hosts served by that router, ] even though the hosts themselves are not directly attached to the LC. Gurgle. This is the natural extension of the former case, and one has balance the tight coupling against the benefits. If the stub domains were truly isolated (including no mobility server, redundant links, etc.) and destined to stay that way, it might be worth the risk. One application where this might work is individual household service. The problem with even documenting this mode of configuration is that someone will attempt to serve a stub domain which then becomes transit or multiply connected. If the stub domain consists of many systems, even switching to another provider or subnetwork could be traumatic. /John From owner-Big-Internet@munnari.oz.au Mon Aug 23 23:57:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11403; Mon, 23 Aug 1993 23:57:46 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11399; Mon, 23 Aug 1993 23:57:36 +1000 (from kasten@ftp.com) Received: from babyoil.ftp.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12054 Mon, 23 Aug 1993 23:49:55 +1000 (from kasten@ftp.com) Received: by ftp.com id AA10088; Mon, 23 Aug 93 09:48:56 -0400 Date: Mon, 23 Aug 93 09:48:56 -0400 Message-Id: <9308231348.AA10088@ftp.com> To: rcallon@wellfleet.com, big-internet@munnari.oz.au Subject: Re: Using MAC-addresses is A loser! From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > Do you mean that a large public WAN based on ATM should use switches > which understand IP addresses, or that the same organization which > runs the ATM WAN should also run a mesh of IP/IPng routers which run > IP and IPng service over top of the WAN? In effect, doesn't this mean either: 1. That the LPW (Large Public WAN) is composed of individual IP subnetworks and that the Internetwork Layer would not treat the LPW as a single data-link layer component, or 2. The LPW uses IP Addresses as its "data link layer address"? The former would mean that the LPW is not a general network, but is really just a set of point-to-point links over which we run IP and only IP -- and only IP can be run over the LPW. This looks bad. The latter means that we tie IP and the LPW-protocols together in a manner that is a bit too close for comfort to me. Changing one would require changing the other. In the worst case, a LPW protocol change that requires a change to the addressing, might require a change to every IP host on the Internetwork. This (admitedly worst case) scenario is very very bad. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Tue Aug 24 00:33:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13274; Tue, 24 Aug 1993 00:33:43 +1000 (from owner-Big-Internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13269; Tue, 24 Aug 1993 00:33:31 +1000 (from 0003858921@mcimail.com) Received: by MCIGATEWAY.MCIMail.com id aa09914; 23 Aug 93 14:12 GMT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab09170; 23 Aug 93 13:56 GMT Date: Mon, 23 Aug 93 14:01 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: embedding link-layer addresses Message-Id: <84930823140148/0003858921NA1EM@mcimail.com> Greg Mnshall said: >The point is not the last time you moved. The last time you moved, you got >a new IP address, as well as a new phone number, as well as a new postal >address. The last two times I moved in my office, I kept the same office address and phone number, but crossed the 'line of death' and needed a new IP number. The last time I moved my home, I kept the same phone number, but lost a special, discountinued service. So your model does not always hold Greg. I know people that move in the same apartment building or condo complex to get a larger or 'better' unit. At work, explaining the difference between a 'small' move and a 'large' move is hard on the users. They don't understand that even if the move is within a building and they can keep their phone number and even their Chrysler Internal Mail Stop, they have to get a new IP number. Bob From owner-Big-Internet@munnari.oz.au Tue Aug 24 00:58:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14194; Tue, 24 Aug 1993 00:58:30 +1000 (from owner-Big-Internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14187; Tue, 24 Aug 1993 00:58:21 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA19468; Mon, 23 Aug 93 10:51:10 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA28760; Mon, 23 Aug 93 10:59:41 EDT Date: Mon, 23 Aug 93 10:59:41 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308231459.AA28760@cabernet.wellfleet> To: minshall@wc.novell.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, rcallon@wellfleet.com >An address says *where* a system is, not *how to get there*. If you >want to make routing efficient, then *where* a system is means "where >the system is attached into the overall Internet Topology". Thus, if >you have a small stub routing domain (which we are likely to see many >millions of in the future), which is attached to a very large public >service provider, then if you choose to embed the subnet address of >the stub domain on the service provider in the address, then you are >in effect saying "please consider *where* this system is in the overall >Internet topology to be "hung off of this large service provider". Let's say you have a small stub routing domain, which is attached to a very large public *IP* service provider (my crystal ball being just as murky as anyone else's). Within the service provider, there is a last hop router, which has an IP address within the service provider's domain. Would you then argue that the addresses in the stub routing domain should have embedded in them the (IP) address of this last hop router of the service provider? Greg; Good question (I am sort of editting my response as I write). I think that the answer comes out "no", but it takes some thinking to figure out why. (Philosophy) In general there is some flexibility in how you say where you are. Thus much of the art of addressing is to figure out how to describe where you are topologically in a way which makes routing to you easier. (Practical) Let's assume that the IP service provider is very large (perhaps 1,000,000 customers). In your example, we might assume that the IP routers within the IP service provider are interconnected in a reasonably well designed topology, which facilitates routing amongst the IP routers. If the IP service provider is *very* large, then it will want to assign addresses of stub's attached to it in a hierarchical manner. Thus, if the addresses of stub domains looked like: Then (assuming that stub within provider is assigned in a flat space) you could end up with a hard routing issue even over the IP provider. However, if the addresses of stub domains looked like: Then if you assign the sub-part within the provider carefully, then you can make routing much simpler. The last question is of course what the "sub-part of provider" should look like. This could be the router, or could be a group of routers (which we might call "area"). Whatever it is, it will effect the prefixes that are passed around in routing protocols. If it were router, then it is not clear to me that you need the IP address of the router. Given that the well designed hierarchy of IP routers is probably running a dynamic routing protocol, they should be able to tell each other what IP prefixes they can route to, and their IP addresses can be found from the routing protocol (which they are already running). Thus even if "sub-part of provider" were to specify the router (which is not clearly necessary), it should probably use some identifier which is more compact than an IP address. What is the difference between the two examples? For the "large public service provider offering ATM or POTS service", the "switches" in the public service provider know how to route ATM or Phone addresses between each other, not IP addresses. In the large IP service provider example, the switches in the service provider are really IP routers, and know how to route IP addresses between them. In both bases, the switches make use of some hierarchical addressing structure, and the level of addressing used for routing over the large public network is assigned in a manner which corresponds to the topology of the large network. Ross From owner-Big-Internet@munnari.oz.au Tue Aug 24 01:06:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14470; Tue, 24 Aug 1993 01:07:01 +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 AA14465; Tue, 24 Aug 1993 01:06:49 +1000 (from jmh@anubis.network.com) Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA12339; Mon, 23 Aug 93 10:09:16 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA07766; Mon, 23 Aug 93 10:06:17 CDT Date: Mon, 23 Aug 93 10:06:17 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9308231506.AA07766@anubis.network.com> To: big-internet@munnari.oz.au Subject: Re: Using MAC-addresses is A loser! > > > Do you mean that a large public WAN based on ATM should use switches > > which understand IP addresses, or that the same organization which > > runs the ATM WAN should also run a mesh of IP/IPng routers which run > > IP and IPng service over top of the WAN? > >In effect, doesn't this mean either: >1. That the LPW (Large Public WAN) is composed of individual IP subnetworks > and that the Internetwork Layer would not treat the LPW as a single > data-link layer component, or >2. The LPW uses IP Addresses as its "data link layer address"? > >The former would mean that the LPW is not a general network, but >is really just a set of point-to-point links over which we run IP >and only IP -- and only IP can be run over the LPW. This looks bad. > >The latter means that we tie IP and the LPW-protocols together in >a manner that is a bit too close for comfort to me. Changing one would >require changing the other. In the worst case, a LPW protocol change >that requires a change to the addressing, might require a change to every >IP host on the Internetwork. This (admitedly worst case) scenario >is very very bad. > >-- >Frank Kastenholz This is exactly why the ROLC group has been created. I do not want or expect all public switches to be IP sensitive, nor do I want the topology tied together in a physical sense. and it is clearly desirable not to carve the universe into small nets, each of which must be traversed to get from sources to destinations. Please excuse the plug for work I feel is important, and needs all the help it can get to produce good results. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.oz.au Tue Aug 24 02:38:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17969; Tue, 24 Aug 1993 02:38:16 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17965; Tue, 24 Aug 1993 02:38:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05396; Mon, 23 Aug 93 12:38:26 -0400 Date: Mon, 23 Aug 93 12:38:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308231638.AA05396@ginger.lcs.mit.edu> To: deering@parc.xerox.com, rcallon@wellfleet.com Subject: Re: Using MAC-addresses is A loser! Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu From: rcallon@wellfleet.com (Ross Callon) Do you mean that a large public WAN based on ATM should use switches which understand IP addresses, or that the same organization which runs the ATM WAN should also run a mesh of IP/IPng routers which run IP and IPng service over top of the WAN? ... I agree with you that it would be very desireable for very large WANs to support IP (and IPng) directly. I tend to think that this means that the internal switches in the WAN should essentially know how to route IP much as if they were IP routers. From: Steve Deering They should run a mesh of IP/IPng routers *instead* of ATM. Exactly. There are certain generic problems you will run into in trying to create a large network out of a mesh of packet switches, such as routing, resource allocation, etc. In trying to build a large ATM network, the ATM people are going to wind up *recreating* all the same mechanisms that IP is going to have, *except* that their solutions will be limited to a single network. Duplicate engineering, duplicate overhead, etc, etc. A good analogy would be that, every time you get on an Interstate (motorway, autobahn, autostrada, etc, etc) your car gets put onto another wheeled device, which works only on that road, and taken off that device when you leave. Pretty pointless, huh? From: rcallon@wellfleet.com (Ross Callon) The notion of having the switches understand IP was proposed at the ATM forum (and also at the IETF) as a way to handle IP over ATM. However, this idea was not accepted. ... I interpreted the discussion as many folks feeling that ATM switches should be separated from IP ... Thus, it appears that folks who are thinking of building large ATM public networks are also thinking of building large ATM public networks in which the switches are not aware of IP I think their attitude is understandable - they don't want to get involved in the internetworking protocols hassles, and in any case no extant inter- networking protocol has the sophisticated service model them need to fully utilize the ATM capabilities in terms of bandwidth quarantees, etc. It also think their attitude is in some ways naive - they don't understand the difficultly, *or* the futility, in the long run, of what they are trying to do. There's nothing you can do. Just stand back and watch, and keep on developing a complete, fully functional, advanced internet architecture. Eventually the world will realize that a world-wide ATM mesh is the wrong way to go, but it will take lots of heads banging on lots of walls for a long time before it sinks in. Noel From owner-big-internet@munnari.oz.au Tue Aug 24 08:16:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01570; Tue, 24 Aug 1993 08:16:25 +1000 (from owner-big-internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22597; Tue, 24 Aug 1993 04:24:17 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20695; Mon, 23 Aug 93 14:17:01 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA28950; Mon, 23 Aug 93 14:25:33 EDT Date: Mon, 23 Aug 93 14:25:33 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308231825.AA28950@cabernet.wellfleet> To: big-internet@munnari.oz.au Subject: Re: Rolc mission (was Using MAC-addresses...) Cc: rcallon@wellfleet.com > Do you mean that a large public WAN based on ATM should use switches > which understand IP addresses, or that the same organization which > runs the ATM WAN should also run a mesh of IP/IPng routers which run > IP and IPng service over top of the WAN? In effect, doesn't this mean either: 1. That the LPW (Large Public WAN) is composed of individual IP subnetworks and that the Internetwork Layer would not treat the LPW as a single data-link layer component, or 2. The LPW uses IP Addresses as its "data link layer address"? The former would mean that the LPW is not a general network, but is really just a set of point-to-point links over which we run IP and only IP -- and only IP can be run over the LPW. This looks bad. The latter means that we tie IP and the LPW-protocols together in a manner that is a bit too close for comfort to me. Changing one would require changing the other. In the worst case, a LPW protocol change that requires a change to the addressing, might require a change to every IP host on the Internetwork. This (admitedly worst case) scenario is very very bad. (Frank) Someone else made the suggestion that due to the importance of the Internet, we can reasonably expect that Very Large Public WAN's will offer IP service. I was just asking how they would do this, and trying to understand the consequences. I am not sure that you interpreted my comments in the manner which I intended them. I will try to be more complete. (I also think that you have brought up a good point -- see below). I would assume that whatever solution is used for IP is likely to be also used for some other protocol suites. Thus, there would not be an issue of the large public WAN only supporting IP. Also, if IP service (and therefore by implication multi-protocol routing service) is offered by running a "mesh" of routers over top of the LPW, then this does not necessarily imply that the LPW is used solely as a bunch of point to point links. I think that this is central to assumptions about what the ROLC group is trying to do: When I say "a mesh of IP/IPng routers which run IP and IPng service over top of the WAN" I mean that there is a WAN which offers directly some sort of data service, but *not* IP service (thus the WAN may be ATM, Plain Old Telephone Service (POTS), or something similar). There are a bunch of routers (IP or multi- protocol routers) which have interfaces to the WAN, and which to some extent know about each other. If we assume that the routers are "normal" IP or multiprotocol routers, then they are probably running some sort of dynamic routing protocol between themselves. However, given the presumed large scale of the net, I might assume that it is not feasible for them to all think of each other as neighbors, in the normal sense of running dynamic routing protocols with each other on a continuous basis. On the other hand, they could be set up in some sort of hierarchy, so that each router can get to each other router indirectly. It is my impression then that part of the point of what ROLC is trying to do (or at least part of the point of Joel's original proposal) is to come up with ways to avoid the indirect routing problem, so that after some initial period the packets going from router A to router X across the WAN can do so directly, rather than via other routers (subject to link layer filtering and policies). Thus, *IF* we are going to run a mesh of IP routers over top of the WAN, then I would expect that (i) the routers would actually be multiprotocol, not just IP; and (ii) there would be some mechanisms to shortcut, so that the WAN is not used as *just* a bunch of point to point links. In this case, I would wonder who is going to be operating and maintaining the mesh of routers (Can we assume that this will be the same organization which is running the WAN?). Also, I think that you are on to a possible issue: If addresses are going to reflect topology, then *if* the LPW is going to route on IP addresses internally, then the IP addresses are going to need to be assigned in ways which reflect the internal structure of the LPW. This would make it pretty much impossible to radically change the internal structure of the LPW. Similarly if the LPW were to route on multiple types of addresses, then the assignment of the multiple types of addresses would be constrained to all fit the topology (which implies that they would all fit each other to some extent). For a "small address" protocol such as IP there would seem to be only one other choice, which is to have a structure of routers or name servers superimposed over top of the WAN (and then optimize in various ways to minimize extra hops). Again however this structure would need to reflect the manner in which IP addresses are assigned, and thus it would be extremely hard to change this structure except in incremental ways (although the underlying WAN could be changed in this case). This is exactly why the ROLC group has been created. I do not want or expect all public switches to be IP sensitive, nor do I want the topology tied together in a physical sense. and it is clearly desirable not to carve the universe into small nets, each of which must be traversed to get from sources to destinations. Please excuse the plug for work I feel is important, and needs all the help it can get to produce good results. (Joel) Yes, it is my understanding is that the point of the ROLC group is to figure out how to make this "mesh" of routers (or name/ARP/ routing servers) superimposed over the large cloud work efficiently, with "shortcut" to allow efficient routing (not involving extra hops, except as a temporary situation). Ross From owner-Big-Internet@munnari.oz.au Tue Aug 24 09:26:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04296; Tue, 24 Aug 1993 09:27:22 +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 AA04275; Tue, 24 Aug 1993 09:26:57 +1000 (from kre@munnari.OZ.AU) To: rcallon@wellfleet.com (Ross Callon) Cc: big-internet@munnari.oz.au Subject: Re: Rolc mission (was Using MAC-addresses...) In-Reply-To: Your message of "Mon, 23 Aug 1993 14:25:33 EDT." <9308231825.AA28950@cabernet.wellfleet> Date: Tue, 24 Aug 1993 09:26:42 +1000 Message-Id: <20196.746148402@munnari.OZ.AU> From: Robert Elz Date: Mon, 23 Aug 93 14:25:33 EDT From: rcallon@wellfleet.com (Ross Callon) Message-ID: <9308231825.AA28950@cabernet.wellfleet> I would assume that whatever solution is used for IP is likely to be also used for some other protocol suites. Only if the other protocol suites have enough customers wanting to access the WAN that the WAN needs to care about them. That is something of the order of your million that you assumed would exist. Frankly I don't see very many protocols attracting that kind of support - whatever wins the general household market, that is, which allows supermarket, bank, library, ... access, and gets it there first is going to be the protocol that has millions of customers wanting access. The others will all be in the hundreds of thousands type capacity max, and will probably diminish to wards obscurity. In this case, I would wonder who is going to be operating and maintaining the mesh of routers (Can we assume that this will be the same organization which is running the WAN?). I would - the point is that there are a million customers demanding some service, if the WAN vendor doesn't provide it, someone else will, and the customers will go there. For a "small address" protocol such as IP I doubt there is much expectation that this will ever really happen with IPv4 (though I haven't been following ROLC work). The million customer scenario is definitely something for IPng, which might, or might not, be a small locator protocol. Finally, I don't necessarily see "IP support" across large WANs as meaning that the WAN needs to route IP. Recall the problem that was to be solved, where the proposal was to embed WAN locators in the IP locator - that is, the problem of address resolution to find the WAN exit point for a packet coming from IP. Certainly one way for the WAN to support that would be to route IP internally, and simply use the IP locator to determine its internal route. But that's not the only way - another way a WAN vendor may choose to support IP (and other protocols where the demand is great enough) would be to provide a directory service, where customers could send simple lookups, keyed by the locator of the protocol they're using, and receiving the WAN locator to use to send packets to that destination (ie: an ARP equivalent which would work easily). kre ps: yes, I am trying hard not to use the evil 'a' word, I'm also trying hard not to assume that locators exist in every packet, not that that is relevant here. From owner-Big-Internet@munnari.oz.au Wed Aug 25 00:24:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15042; Wed, 25 Aug 1993 00:24:29 +1000 (from owner-Big-Internet) Return-Path: Received: from [192.73.213.12] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15036; Wed, 25 Aug 1993 00:24:07 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA04606; Tue, 24 Aug 93 10:21:28 -0400 Date: Tue, 24 Aug 93 10:21:28 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9308241421.AA04606@er.doe.gov> To: art@opal.acc.com, minshall@wc.novell.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au I think what the "Ross Scheme" might need is a method for including wild cards in the attachment point address. For example, if your net had 2 attachment points to provider X one might have an address xxx.xx.xxx1 and the other xxx.xx.xxx2 then the machine MAC could be referred to as xxx.xx.xxx?.MAC which could find either attachment point. It is still true that if one attachment is provider X and the other is provider Y you still have the usual multi home mess althoufgh[4~ the wildcard may help you here too. One other thing that the wildcard might allow is grouping MAC addresses together for subnetting. For example if you had a collection of MAC addesses {MAC} then referring to it as xxx.xx.xx1.{MAC} would let you tie these systems together a s a subnet but sending to xxx.xx.xx?.MAC would still reach a machine independant of which subnet it was on. DH From owner-big-internet@munnari.oz.au Wed Aug 25 02:18:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19369; Wed, 25 Aug 1993 02:18:44 +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 AA15554; Wed, 25 Aug 1993 00:36:29 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA04651; Tue, 24 Aug 93 10:34:12 -0400 Date: Tue, 24 Aug 93 10:34:12 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9308241434.AA04651@er.doe.gov> To: kre@munnari.oz.au, rcallon@wellfleet.com Subject: Re: Using MAC-addresses is A loser! Cc: big-internet@munnari.oz.au It seems to me that this debate is similar to the discussions about running IP over X.25. In fact it seems that the most likely outcome is for ATM to act as a link layer like protocol with IPng running on top of it. This is both a disadvantage and an opportunity. Of course from an efficiency point of view running an integrated stack over the lightest weight lower layers seems to be most advantageous (But note that this sort of assumes that the services offerred over the network layer require siimilar network layer capabilities). Of course doing ARP to find addresses in a global ATM net is not a good idea either. On the other hand perhaps the ATM service definition and TOS things are underlying capabilities that IP could use and not have to build. DH From owner-big-internet@munnari.oz.au Wed Aug 25 04:54:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25492; Wed, 25 Aug 1993 04:54:46 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16905; Wed, 25 Aug 1993 01:13:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12384; Tue, 24 Aug 93 11:12:52 -0400 Date: Tue, 24 Aug 93 11:12:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308241512.AA12384@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, jmh@anubis.network.com Subject: Re: Using MAC-addresses is A loser! Cc: jnc@ginger.lcs.mit.edu I do not want or expect all public switches to be IP sensitive I think that in the short run (i.e. less than 3 years), this is a not unreasonable attitude. IP can't scale to that degree, the world is still deciding on a single internetwork layer (yes, I know, we may well need the ability to migrate, but a single ubiquitous internetwork layer, to allow the widest possible communciation base, is inevitable), etc. The providers simply don't want to get into this hassle. In the long run, this makes less sense, because of the duplication of mechanism I keep ranting about. It's also crucial to realize that functions like routing and resource allocation are things which need to be done in a system-wide fashion. Carving off chunks of the internet, and doing these functions in a whole different layer inside them, with a giant impenetrable firewall between the network's version and the internetwork's version, has *proven in the past* to be the wrong way to go. What scares me is the thought that we will go down this road (for the short-term reasons given up top), and then find ourselves in a dead end (for the reasons given above), and unable to back out easily, because of deployed base, sunk investment, etc. I wish I could see a way out of this, but I don't.. it is clearly desirable not to carve the universe into small nets, each of which must be traversed to get from sources to destinations. Depending on your model, this is what is happening anyway; it's just happening at different layers, so you don't see it. I mean, what's the difference between: - a giant ATM mesh, where to get from the router on my LAN to the router on your LAN, you go through 77 ATM switches, and all the intermediate links, and - a giant internetworking mesh, where to get from the router on my LAN to the router on your LAN, you go through 77 internetworking switches, errr, routers, and lots of intermediate links? My model of the "network of the future" is that it will be composed of boxes with a "bottom half", which looks like an ATM switch, and a "top half", which looks like an IP router. Once a "flow" is set up through the switches, it will only traverse the bottom halves; only flow setup, datagram traffic, routing and management, etc, will get to the top halves. Noel From owner-Big-Internet@munnari.oz.au Wed Aug 25 11:55:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12940; Wed, 25 Aug 1993 11:55:32 +1000 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12929; Wed, 25 Aug 1993 11:55:17 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA17614 (5.65/1.23); Tue, 24 Aug 93 21:53:34 -0400 Date: Tue, 24 Aug 93 21:53:34 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9308250153.AA17614@sadye.emba.uvm.edu> To: Craig Partridge Cc: Big-Internet mailing list Subject: re: address sizes In-Reply-To: <9308152316.AA00430@aland.bbn.com> References: <9308152316.AA00430@aland.bbn.com> I've been thinking about this as I've walked home over the past week, and I figured it was time to share some of my thoughts. Note that a lot of this is a combination of conjecture and gut feeling; reasonable people may disagree. My apologies for using the `A word'; in the particular cases that I'm thinking of, I'm talking about the field labeled ``address'' in the Pip header, which consists of a variable number of 16-bit numbers whose meaning is determined from other fields in the transit part of the packet. < said: > What I care about is memory loads -- there's a big penalty for > discovering that you don't have all of the header that you need > loaded into cache, there's an even bigger penalty for memory traps > (from overestimating and loading non-existent memory), and if you > avoid the memory trap, you still pay some cost for loading > substantially more data than you need because it eats memory load > cycles (and we're fast getting to the point where routers are memory > speed limited, not processor speed limited). > So my nightmare is that either: > (1) at the key point in the forwarding loop, the router stalls for > tens of cycles to go get the last bytes of a variable length > address; OR > (2) router performance suffers because everyone is loading 80 bytes > of header, even though the average variable length header is only 40 > bytes, because they are trying to avoid the stalls of (1). I have a few responses to this... 1) I think you have to solve the memory speed problem anyway, in order to make fast networks work. New ideas and services are going to place more demands on CPU and memory speed whether we have long variable-length addresses or not, so if those services and speeds are considered important enough, they will drive the technology. 2) I have a gut feeling that potentially long variable-length addresses are necessary in order to fulfill some of the other requirements we have set out for IPng; to the extent that proposals other than Pip do not provide for this, they will grow address-like appendages in other fields of the packet (such as options). 3) If these sorts of addresses cannot be accomodated, the decrease in performance will necessitate the development of a flow-based architecture (where potentially long, potentially variable-length addresses give way to usually short, potentially variable-length flow identifiers, which can fit into the address field). 4) It's not just the software that's getting more sophisticated. Some of the problems that you mention can be alleviated by increasing the intelligence of the hardware, or just by changing the way the hardware interfaces to the rest of the system. Back in July, I was talking with John Wroclawski about some work he's doing on an Alpha-based DEC 5000, and one of the features that he liked about that architecture (correct me if I'm wrong, John) was that hardware devices could be mapped into cache memory (if they were fast enough, I assume). (As someone who has spent most of the past decade working on PCs, I wondered for a while why this was such an achievement: most of the PC network interfaces that I am aware of use dual-ported memory rather than DMA; in the driver that I wrote, I went to considerable pains to make sure that a packet was something useful before I bothered to copy in it from adapter memory. If PC Ethernet adapters had a reasonable amount of memory to begin with, the copy in could be avoided, but I was working with only 16k, and it was necessary to ensure that useless packets were discarded as quickly as possible.) 5) While I think that the capacity for long variable-length addresses is important, you shouldn't take that to mean that I think the average address will be particularly long. Quite the contrary; if network traffic exhibits locality of reference (and I think it does now and will continue to do so in the future), then most traffic will have relatively short addresses (at least under Pip), since for the most part the long stuff is not needed for intra-domain transmissions. So there's my five reasons... -GAWollman [Feel free to to quote me. Your Mileage May Vary. The preceding program is not intended, and should not be construed, as investment advice. Consult your doctor before use. Some settling may have occurred during shipment. UVM doesn't have the faintest idea what I'm talking about, and shows no signs of learning.] -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Thu Aug 26 02:22:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17575; Thu, 26 Aug 1993 02:23:43 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17543; Thu, 26 Aug 1993 02:22:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21253; Wed, 25 Aug 93 12:20:10 -0400 Date: Wed, 25 Aug 93 12:20:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308251620.AA21253@ginger.lcs.mit.edu> To: rcallon@wellfleet.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu (Thing are finally quiet enough for me to have time to comment on Ross' scheme for embedded service provider link-level addresses... :-) An address [i.e. "locator" -jnc] says *where* a system is, not *how to get there*. Yes to the first, but it can have some subtle influences on the calculation of routes (to do the second), particularly in the presence of "thinning"; i.e. discarding of *useful* routing information to keep the routing overhead reasonable as the system scales up in size. Most instances of "aggregation" involve some "thinning". More on this inter-relation of addresses, err, locators and routes later... if you have a small stub routing domain (which we are likely to see many millions of in the future), which is attached to a very large public service provider, then if you choose to embed the subnet address of the stub domain on the service provider in the address This is an interesting idea. In a way, it reminds me of Dave Clark's "route suffixes", or "route fragments". Both have the same aim: to propogate information needed to compute a route to a given destination, but at the time the source decides it wants to go there, and not before (as is the case with current routing architetures, where both the routing data and the route computation is performed in advance). +++ Parenthetically, and in concise form, this crystallizes some recent trends and techniques used to reduce overhead in large-scale routing architectures. The first step was to delay the *computation* of routes until they were needed, and we have since moved on to attempting to delay the propogation of routing data until it is needed. +++ The information which is propogated is different in the two: in the route suffix scheme, when you look up an 'address', you also get some source route fragments, which the destination has created and provided, and which lead from various "well known" entities such as major providers, to the destination. The source picks, from the ones provided by the destination, a major provider it is happy with, and can route to, and puts that together with the approriate suffix to form a route to the destination. In your scheme, which is more limited, you only get the exit point from the major provider. Another way to look at what your scheme does is that it is the analogue, at this level, of doing away with ARP. If you provide each stub client off a service provider with a number, which is that stub's locator, all you are really doing is providing an externally visible name which the attached routers have to transform into the link-level address of the exit router. I.e., in provider A.B, you have stub A.B.Q, and you have to get from Q to the exit router's link-level address. Normally, this is a two step-process; the routers use internetwork-level routing to decide on a next-hop router for that internet destination, of all of the possible next-hop routers; then, an address resolution step happens to get the link-level address of that router. However, with stubs the first step is no-op, there is only one possibility, so you just need the address transformation, and you fan on this by putting it right into the destination internetwork locator. If you screw your head on the right way, this can look like a source route. However, as I said before, there is a funny interaction between locators and routes. In a situation where there *is* only one entrance-way to a destination, almost inevitably the locator will *feel like* a source route, since it causes you to go that way. More imporantly, in more complex situations, the places in which you put the topology naming abstraction boundaries, and the way in which you thin, can conspire to make the locator *again* feel like a source route. I.e. if thinning has caused you to lose other potential routes to a given destination, leaving only one, the locator will tie you to a single route. However, in none of these cases is the locator *really* a source route; the routing architeture has only left you with a single route to that locator. I prefer to go back to the highlighted thought above: what is really going on here is to delay the propogation of certain data needed to compute a route, until it is required. In hindsight, this has been happening for a while; the Local Abstraction Control mechanism in Nimrod (aka the "Blister Model", for those who were there at ISI that week :-) is effectively just this. The problem with LAC is that it provides no mechanism for deciding *which* extra info you need. Route suffixes, and now this scheme, are attempts to do this. In a way, I like this scheme, since it's very simple, but in a way it is very unsatisfying. The problem is that it handles a limited case: a common case, true, but a limited one. It fails completely as soon as a stub has a second provider (we need a word for "non-transit, non-stub" :-), unless you provide every host in the stub a second address. The question for me is: given that we have identified the main goal, which is to delay propogation of routing data until it is needed, is the a more general purpose mechanism which is about as cost-effective? After Dave Clark attacked Nimrod's capabilty to prevent thinning from causing single routing, and showed how route suffixes can prevent this, I went away and thought about it for a while. Route suffixes I'm not crazy about, since they include the destination's policy constraints, not the source's. I don't have a complete answer, but in section 6.3 of the Nimrod spiel, I discussed a number of alternatives. My current preferred option is to have the source receive a certain amount of topology information about the area near the destination. This real-world analogy is that when you get an invitation to a party at a friend house, they usually include a simplified map showing where they are. Still, the goal is: to provide an efficient way, which is as flexible as possible, to delay propogation of routing data until it is needed. Noel From owner-Big-Internet@munnari.oz.au Thu Aug 26 02:36:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18263; Thu, 26 Aug 1993 02:37:03 +1000 (from owner-Big-Internet) Return-Path: Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18256; Thu, 26 Aug 1993 02:36:46 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA00695; Wed, 25 Aug 93 12:29:20 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA29559; Wed, 25 Aug 93 12:38:00 EDT Date: Wed, 25 Aug 93 12:38:00 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308251638.AA29559@cabernet.wellfleet> To: art@opal.acc.com, hitchcoc@oerv01.er.doe.gov, minshall@wc.novell.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au I think what the "Ross Scheme" might need is a method for including wild cards in the attachment point address. For example, if your net had 2 attachment points to provider X one might have an address xxx.xx.xxx1 and the other xxx.xx.xxx2 then the machine MAC could be referred to as xxx.xx.xxx?.MAC which could find either attachment point. It is still true that if one attachment is provider X and the other is provider Y you still have the usual multi home mess although the wildcard may help you here too. One other thing that the wildcard might allow is grouping MAC addresses together for subnetting. For example if you had a collection of MAC addesses {MAC} then referring to it as xxx.xx.xx1.{MAC} would let you tie these systems together a s a subnet but sending to xxx.xx.xx?.MAC would still reach a machine independant of which subnet it was on. Dan; The scheme would also be helped by what the old X.25 guys called "hunt group" addresses (the same as what Paul Francis has more recently being calling "anycast"). With Hunt Group or Anycast addresses, there is one address which will route a call (or packet) to any one of several addresses. Thus if a small stub domain was attached to a single provider via two different routers (for example, to provide redundancy), then the embedded subnet address in the IPng address of the systems in the stub would use an anycast address for the two routers (note that the routers might want to have individual addresses also for other reasons, but this does preclude using one anycast address to access the two routers). I think that the anycast address idea is also very useful for a number of other purposes (including use of well known anycast addresses for finding resources in networks where multicast is inherently expensive, or not available at all). Thus this is a service that a network such as ATM really *should* offer for a variety of reasons. Ross From owner-big-internet@munnari.oz.au Thu Aug 26 13:36:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17233; Thu, 26 Aug 1993 13:36:49 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09156; Thu, 26 Aug 1993 10:50:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23726; Wed, 25 Aug 93 20:50:08 -0400 Date: Wed, 25 Aug 93 20:50:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308260050.AA23726@ginger.lcs.mit.edu> To: rcallon@wellfleet.com Subject: Re: embedding link-layer addresses in IPng addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The scheme would also be helped by what the old X.25 guys called "hunt group" addresses ... if a small stub domain was attached to a single provider via two different routers ... the embedded subnet address in the IPng address of the systems in the stub would use an anycast address for the two routers ... This one set off my kludge alarm. What you have here is an alternate path choice; i.e. a routing decision. I happen to think all routing decisions should be made by a single unified system, for reasons I won't belabour again. Sticking this particular odd case into a pseudo-multicast is a kludge. It won't help you in the case where the stub is connected to two service providers, which I reckon will be common. If you solve that case with a reasonably efficient mechanism, this one will get handled too, without any extra mechanism, let alone a kludgy one. I think that the anycast address idea is also very useful for a number of other purposes (including use of well known anycast addresses for finding resources ... Thus this is a service that a network such as ATM really *should* offer for a variety of reasons. Not a bad idea, but, once again, it would be nice it it wasn't a special purpose mechanism, particular to one net. Perhaps if such an anycast mechanism was defined at the internet level; on networks which supported it at the link level you use the facility directly, but on nets which do not, the routers (or some other server) implement it? Would it be reasonably efficient if doen at the internet layer? Noel From owner-big-internet@munnari.oz.au Fri Aug 27 01:10:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14953; Fri, 27 Aug 1993 01:10:39 +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 AA08499; Thu, 26 Aug 1993 22:40:56 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA12012; Thu, 26 Aug 1993 08:39:09 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199308261239.AA12012@world.std.com> Subject: Re: embedding link-layer addresses in IPng addresses To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 26 Aug 1993 08:39:09 -0400 (EDT) Cc: rcallon@wellfleet.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9308260050.AA23726@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 25, 93 08:50:08 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2646 In the context of embedding MAC or other "medium" addresses in the IPng address, I'd like to propose a slightly different way of doing things. This may achieve the goals of both camps, those that want a "provider" or "medium" address and those that want to keep routing decisions in routers. There are other goals to be considered. I suggest that the "embedding" should be semantic when viewing a header as a whole, but not part of the actual address. A "syntactic" embedding is the sort of thing we do when a MAC address becomes the station ID in an NSAP address....it's a visible "element" inside the primary address. If we have a separate field for one (1) "medium" ID, we separate the EID-like global addressing and the local address resolution problems. If I understand what Ross is saying about access to large clouds, we need a single transit subnetwork address to get there. This might be an X.121, E.164, or other "locator," each of which has a different format. Noel does not want routes or near-routes embedded in the actual addresses. I think this proposal deals with that, because, at least for the nonbroadcast multiaccess subnetwork case, this second field is as much a policy as it is a route. The "gateway" between the local domain and the transit/provider could be privileged to change the "secondary locator," but not the EID-like primary address. Such changing is exactly what one might want to do in multi-homed networks, or in the closely related case where policies exist for sharing traffic among several commercial transit networks. The latter use is similar to the RPOA selector facility in X.25. Note that X.25 defaults to no RPOA selection. Since different subnetworks have different address formats, we would need either something like the NSAP AFI, or perhaps bit flags denoted which of a small set of formats are in use. I am _not_ proposing we reinvent NSAP addresses. Where an NSAP address is of the general form AFI->IDP-->HO-DP-->Station->Selector, where all fields are variable-length, I am suggesting an IPng addressing structure with three fields, probably fixed: global EID (64 bit?)...secondary locator format... secondary locator value (64 bit?) To get better packing, I'd encode X.121 addresses as binary. The secondary locator format might include policy flags as well as format identifiers; a typical policy might be "secondary locator substitution permitted/not permitted." ------ Howard ------ PS to the list: I'm trying to do an internal justification for my first IETF trip to Houston. Help on planned activities and other benefits would be very helpful! From owner-big-internet@munnari.oz.au Fri Aug 27 07:14:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00110; Fri, 27 Aug 1993 07:15:16 +1000 (from owner-big-internet) Return-Path: Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16031; Fri, 27 Aug 1993 01:36:51 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04703; Thu, 26 Aug 93 11:29:19 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA29832; Thu, 26 Aug 93 11:38:03 EDT Date: Thu, 26 Aug 93 11:38:03 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9308261538.AA29832@cabernet.wellfleet> To: jnc@ginger.lcs.mit.edu Subject: Re: Anycast (was embedding link-layer addresses in IPng addresses) Cc: big-internet@munnari.oz.au, rcallon@wellfleet.com I think that the anycast address idea is also very useful for a number of other purposes (including use of well known anycast addresses for finding resources ... Thus this is a service that a network such as ATM really *should* offer for a variety of reasons. Not a bad idea, but, once again, it would be nice it it wasn't a special purpose mechanism, particular to one net. Perhaps if such an anycast mechanism was defined at the internet level; on networks which supported it at the link level you use the facility directly, but on nets which do not, the routers (or some other server) implement it? Would it be reasonably efficient if doen at the internet layer? Noel; But how hard it is to do anycast depends a great deal on what the addressing structure is, and how far apart the various alternative end systems are. If you use a hierarchical address structure (which we both feel is necessary for a very large Internet) then if all of the alternative destinations for a particular anycast are in the same lower level "thing" in the hierarchy, then anycast is trivial. Since IP routes to subnets, this would imply that they would need to be attached to the same subnet for anycast to be trivial. Since IS-IS for CLNP routes to areas, two or more end systems in the same area could be alternative anycast destinations trivially. CLNP end systems which wanted to receive anycast messages sent to a particular well known address could send out two sets of ES hellos, one for their normal address, and one for an anycast address which they wanted to listen in on. If two or more end sytems both advertised the same ES address and were in the same area, then IS-IS would just route a packet to the nearest such ES, and would not know nor need to know whether there were really one ES connected in several places, or multiple ESs connected in one place each. Thus IS-IS already supports anycast, provided that (i) the end sytems are in the same area, and (ii) someone assigns an anycast address from that area's address space. I don't see this as a kludge at all, I think that this is just a natural way to route to several end systems which are willing to receive packets for the same address. Naturally OSPF could do the same thing equally trivially, except that since OSPF routes to subnets, the hosts would need to be on the same subnet. Now, if the systems were *not* in locations which map into the same lower level hierarchical part of the address space, then with hierarchical addressing you get an issue: Do you give the anycast destinations a single address in some part of the regular address space, or do you reserve some "anycast" part of the address space. Clearly you could do something similar to IP multicast (where you pick a different part of the address space, which is not topologically assigned), but this is going to have a problem in scaling if there are an enormous number of anycast addresses in use. My guess is that we might want to do something similar to mobile host for this: Use one address which states where the anycast core is, and then a packet is re-routed to the nearest available system that supports that anycast (even if the system is not in the same area). In fact, mobile host support may be just a special case of a wider problem, where for some reason a system needs an address which is not closely linked to its current actual topological location (where this could be caused by mobility, multiple anycast hosts with the same address, or a hierarchical address structure with a non-hierarchical topology). Ross From owner-Big-Internet@munnari.oz.au Fri Aug 27 08:53:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03633; Fri, 27 Aug 1993 08:53:23 +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 AA03627; Fri, 27 Aug 1993 08:53:10 +1000 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB21200; Thu, 26 Aug 93 15:46:20 PDT Date: Thu, 26 Aug 93 15:46:20 PDT Message-Id: <9308262246.AB21200@wc.novell.com> To: Steve Deering From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com (Unverified) Subject: Re: Terminology problems Cc: big-internet@munnari.oz.au Steve, Noel said: >"address" - The structured name of an attachment point to the network. The > structure is used by the routing to make its (difficult :-) job a > little easier. I believe it is an inescapable truth, (and have so > argued at length :-) that things which have related addresses must > be topologically related, or else the routing will break down, but > let's leave that for a bit. The address might or might not appear > in all packets (see "f-selector"). to which you replied: >I have trouble with the "attachment point" part of your definition. >Ethernet "addresses" do not identify attachment points, because if you >change the point at which a computer attaches to an Ethernet cable, its >address doesn't change. NSAP "addresses" also (formally) do not name >attachment points. Common usage of the term "address" in networking is >somwhat looser than your definition (loose enough even to allow for >"multicast addresses" which certainly don't name "an attachment point"). An ethernet address is a structured (with the trivial structure) name of an attachment point to an ethernet network. If your problem is that to you, "attachment point" == "tap/10-base-t-hub-port/whatever", then i see the issue. Otherwise, i don't. Ethernet addresses have no structure. Ethernet cables, from the network (not to mention the internetwork) view, have no structure. What a fit! NSAP addresses i know even less about, but i assume they name a node within an area (since within an area ?? host routing is used)? > An "address" is a unique label for a node or (in the case of > multicast) set of nodes in an network. (This definition > intentionally does not say whether or not a "node" is a box or > a box's interface to a network or a "pseudo-node" representing > a subnetwork; it may be any or all of those.) > > A "hierarchical address" is an address of the form L1, L2, ..., Ln, > where: > > - L1 is a label for a connected region of the network. > > - L2 is a label for a connected region of L1. > > - ... > > - Ln is a label for a node or set of nodes in region Ln-1. > > A label Li is required to be unique only with region Li-1. > >Reminder: a region is called "connected" if there is a intra-region path from >any node to every other node within the region. One of the things people seem to beat Noel up about is whether an address has topological significance. He says "things which have related addresses must be topologically related". (Notice that he doesn't define the "related" function.) It seems worthwhile to point out that you (and your definition) agree with this (where LnRelated(a1, a2) ==> Li(a1) == Li(a2) for all 1<=i<=n). >Note that the definition of "address" does not prevent a node from keeping >its address when it "moves" in the topology (thus, for example, an Ethernet >device can keep its address when it is plugged into a different point on the >same cable.) With "hierarchical addresses", a node or a group of nodes may >keep their addresses when they move in the topology, as long as the >"connectedness" requirement is not violated. Precisely. But, if you move a node from Xerox to Novell, its address will change. That is because each Li defines some region in the topology, and if something previously below that Li moves out of that region (and the region isn't changed to accomodate this), then that thing needs to get a new address. Greg From owner-big-internet@munnari.oz.au Fri Aug 27 14:52:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18136; Fri, 27 Aug 1993 14:52:55 +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 AA08528; Fri, 27 Aug 1993 10:59:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00472; Thu, 26 Aug 93 20:57:08 -0400 Date: Thu, 26 Aug 93 20:57:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308270057.AA00472@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, minshall@wc.novell.com Subject: Re: Terminology problems Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu (You're using the first version of this terminology. An updated one came out on Date: Thu, 19 Aug 93 01:14:45 -0400.) > "host identifier", "h-id" - A name ... for a host. (Much the same as an > EID, for those who understand that term.) Under what conditions would an "address" or an "i-name" not be *usable* as an "h-id"? When, for any reason, an old topological sensitive name for the entity is no longer valid or applicable, but the entity is still operational. One example is when the host has moved. You can put in a new field which is the real "address" (i.e. locator), or have the packet wrapped at a forwarding server at the host's old location, etc, but in all cases the old "address" is no longer the correct locator for the host. Another example is mobile processes; if A, B and C start out on the same machine, and only A moves, there's no single "address" which correctly describes the state before *and* after the move. Etc, etc, etc. Noel