From owner-ipng Sat Oct 1 12:56:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00671; Sat, 1 Oct 94 12:56:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00665; Sat, 1 Oct 94 12:56:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13450; Sat, 1 Oct 94 12:53:15 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA12583; Sat, 1 Oct 94 12:52:53 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm036-27.dialip.mich.net [141.211.7.69]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA19344 for ; Sat, 1 Oct 1994 15:52:48 -0400 Date: Sat, 1 Oct 94 18:39:57 GMT From: "William Allen Simpson" Message-Id: <3270.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Just back from a week on the road, and have limited time to answer 65 messages on this list in the past 4 days. But I thought this one most critical to progress: > From: Robert Elz > From: "William Allen Simpson" > If a host has two interfaces, and all routers say "I have the same match > to the world", then by definition, they are equally as good for reaching > the destination. Preferences are to break the tie. > > Bill, this is only true from a very limited perspective. From > the router's point of view, this may very well be correct. > >From the hosts' its simply not so. > Actually, I would put it the other way. It is _always_ true from the host perspective, and not necessarily from the routers. Multiple routers could have different metrics. A ---------------------------- H1 H2 R1 ------- world B ---------------------------- > > Using your scheme, I see no way at all that all traffic going > externally will not travel from both hosts to the world over one > of the two ethernets. > You misunderstand. All traffic from one host will always travel (outbound) over one of the 2 ethernets. This ethernet is selected by the preference when the prefixes are equal. In the example, the prefixes will always be equal on both links, since all they come from R1. All traffic from the _other_ host could in fact go over the other ethernet. This is selected by the prefix matching against its _own_ (source) prefix. That is why there are both a Cluster prefix and a Preference in each advertisement. There is no requirement that both H1 and H2 have the same prefixes. This is not new. This is the same as IPv4 Router Discovery. > That's not what I want - if for no other reason than to spread the > load over the two nets (for this purpose you can imagine no other > hosts on the two ethernets if you want, with the idea being that > each host will have one dedicated net, and another interface for > backup use in case the first net dies). > Sounds fine to me. But it would require hand configuration. > There's no way the router can say anything in any kind of multicast > or broadcast message that will result in this behaviour, as the > result depends on the host, not the router. > I don't understand. The prefixes and preferences are already in the advertisements! The router advertisement on A would say: cluster xxxA0 preference 1 cluster xxxB0 preference 2 The router advertisement on B would say: cluster xxxA0 preference 2 cluster xxxB0 preference 1 Here, assume H1 has address xxxA1, and H2 has address xxxB2. H1 will always send out A, with fallback to B. And vice versa for H2. > time. With that info, the hosts can learn that the route to > the world is equal out each interface, then use local interface > knowledge - either administrator preference, or knowledge that > one interface has better performance than the other, to choose > between equal interfaces. > Snooping routing protocols will not fix the problem you outlined above. The routing protocols will all tell both hosts the same metric to the outside world. For the routing protocols, that preference mechanism is the metric. But, none of the routing protocols we use today has a separate metric dependent on which _source_ (host) is used. So, the routing protocols cannot solve the stated problem. Performance choice would cause both H1 and H2 to pick one link, which would not solve your stated problem. You still need an "administrative preference" mechanism, as you admit here. You could configure each host, as you say. Better to have the administrator configure the (fewer) routers. Perhaps you are expecting load balancing without hand configuration? Do you have a method? > Once one admits that multi-homed hosts really need to at least be > able to act as routers, since many users want that in any case, > whether we like it or not, then almost all the arguments against > making other hosts be dumb go away. I do not admit that. There seems to be a very basic misunderstanding of the interaction of Router Discovery (both IPv4 and IPv6) with routing protocols. Routing protocol metrics are based on the _destination_ address. Router preferences are based on the _SOURCE_ address. The algorithm (see the old drafts, or wait for the new one next week) is as follows: - Choose a link based on the destination match. This is called the "Local/Remote" decision. See RFC-1122. (In your case, the decision would decide "remote". So far, so good.) - When not local, choose a router based on the source match. The source is matched against the list of addresses in the router advertisements. See RFC-1256. - Choose the router with the highest preference for the same source match. (Only applies to multiple routers on the same link.) Steve Deering told me that this capability was included so that multiple organizations could share links and routers, but have different preferences. I have preserved that capability. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 2 10:36:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00836; Sun, 2 Oct 94 10:36:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00830; Sun, 2 Oct 94 10:36:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08561; Sun, 2 Oct 94 10:33:14 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA20487; Sun, 2 Oct 94 10:32:51 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23390; Mon, 3 Oct 1994 01:56:25 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: next hop resolution In-Reply-To: Your message of "Sat, 01 Oct 1994 18:39:57 GMT." <3270.bill.simpson@um.cc.umich.edu> Date: Mon, 03 Oct 1994 01:56:20 +1000 Message-Id: <7466.781113380@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sat, 1 Oct 94 18:39:57 GMT From: "William Allen Simpson" Message-ID: <3270.bill.simpson@um.cc.umich.edu> Sounds fine to me. But it would require hand configuration. Yes, or something like that (in many cases hosts have interfaces with different performance characteristics, they could automatically choose to prefer a high performance interface over a lower performance one, all else being equal, without hand configuration, but in general, yes, I agree). The important part is for the host to be able to discover the "all else being equal" part of this. Snooping routing protocols will not fix the problem You don't have to convince me of that - I agree fully. Routing protocol "snooping" is definitely not what we want - quite apart from the fact that while it works with RIP (and similar), there's absolutely no guarantee than any random routing protocol that may be in use is snoopable. If something involving routing protocols is needed, then my suggestion was for the multi-homed host to participate fully in the routing protocol (as a router, though probably biasing its advertisments so that no traffic would ever be routed though it). You still need an "administrative preference" mechanism, as you admit here. Yes. You could configure each host, as you say. Better to have the administrator configure the (fewer) routers. I still don't believe its possible to configure the routers for this - its too intimately tied to the properties of the hosts. I especially don't believe that the host's addresses are even slightly useful to aid it in making the choice - there's too much host specific knowledge required. In particular, in your .. Here, assume H1 has address xxxA1, and H2 has address xxxB2. no, not quite, H1 is xxxA1 and xxxB1, and H2 is xxxA2 and xxxB2 and now H1 and H2 are no better off than they were before, the preferences and advertisments coming from the router tell them nothing (nor conceivably could they - unless the router were go go and specifically query H1 and H2 as to their configurations, and then either somehow compute the messages it sends based on some algorithm which would pander to their preferences - possible with two hosts, unlikely with hundreds - or send directed messages to each host instead of multi-casting them. Neither would work). Perhaps you are expecting load balancing without hand configuration? Do you have a method? Its not load balancing, and no I'm not expecting that, and no I don't have a method, nor is that what I'm looking for. > Once one admits that multi-homed hosts really need to at > least be able to act as routers, I do not admit that. I think you missed this following phrase... > since many users want that in any case, That is, many (if not most) users want to be able to use multi-homed hosts as back up for routers - in the diagram I haven't reproduced, if R1 (assumed to be the only real router linking nets A and B) goes down, or its A or B interface dies, most users look at the config that's left and say "I can send packets for net B from net A through H1 or H2, can't I, they provide my backup for when the router dies, I don't need an expensive redundant router here" .. I know we do for certain. If you accept that many people want to be able to use multi-homed hosts as routers - some use only multi-homed hosts as routers, others, like me, use real routers, but can't afford to make them redundant, so we use our multi-homed hosts for the redundancy - then you have to accept that those hosts have to participate in the routing protocol (not "snoop") or as a backup router they're useless. You only need to show a reasonable market for such a configuration for the host vendors to realise they don't want to have to ship special versions for those customers - then they ship routing code with every box they sell - or at least every box that can possibly be multi-homed. They all do that now - everyone ships routed, which isn't much of an example, but it is one. My suggestion was simply that given that we can assume the existance of this code, multi-homed hosts could use it to determine the "all else being equal" above - I wasn't expecting any more than that. Christian Huitema sent me a (semi-)private response to my last message pointing out that in some environments it would be absurd to make everything that is multi-homed a router, as literally everything is multi-homed for redundancy (redundancy here for a broken cable, or host interface - that kind of redundancy most people I know can't afford, but certainly some both can and do justify it). I agree with what he pointed out - this means that we simply can't require multi-homed hosts to participate in the routing protocol, so that part of my previous message is dead. In reply (to him) I suggested that perhaps a formalised "routing protocol snooping" - though that suggests the wrong thing - that is, a third category of object perhaps, between hosts & routers, for multi-homed hosts, which would listen to information sent from the routers, and make decisions based on that. Single homed hosts have much simpler decisions to make, and need much less complexity (which I don't think anyone ever doubted). It may be that your draft provides this already, I'll wait for the next release and read again more carefully. If so its doing rather more than I had assumed it was - which is not at all undesireable, in fact, it may be necessary. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 2 12:57:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00855; Sun, 2 Oct 94 12:57:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00849; Sun, 2 Oct 94 12:57:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10864; Sun, 2 Oct 94 12:54:07 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA24546; Sun, 2 Oct 94 12:53:39 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Discovery Date: Sun, 2 Oct 94 20:50:55 GMT From: Ran Atkinson Message-Id: <9410022050.aa04244@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian, I have a fair number of multi-homed hosts. I do want them to make reasonable choices when selecting an outgoing interface. I do NOT want them to participate in routing in ANY manner. Eavesdropping on RIP is considered particularly undesirable in my environment and I cannot see any value to such eavesdropping in my environment. The current router selection proposal for IPv6 Discovery appears to be just like the extant IPv4 Router Discovery (which is in wide use and seems to work well). I'd like to keep that approach to Router Discovery in IPv6. IMHO, the IPv6 specs MUST NOT require that multi-homed hosts act in any way as routers. If particular users wish to turn multi-homed hosts into routers (many customers do) then that should be supported by host vendors, though it should require sys admin intervention toconfigure and enable routing and should not be automatically turned on. In practice this means that host vendors have to ship kernels that can support IP forwarding (as has been noted several times already). The main change I'd make from the current practice is one that appears to be outside the IETF scope. That change is to remove the code inside most vendors /etc/rc* scripts to _automatically_ enable RIP routing whenever the host detects that it has more than 2 interfaces. I'd like to see manual configuration be required before any host turned itself _automatically_ into a router. A second change I'd like to see would be killing off routed(8) entirely and replacing it with something (e.g. gated(8)) that supported at least OSPFv2 (possibly also supporting a modern version of RIP for backwards compatibility reasons). Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 00:28:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00941; Mon, 3 Oct 94 00:28:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00935; Mon, 3 Oct 94 00:28:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25337; Mon, 3 Oct 94 00:24:39 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA02786; Mon, 3 Oct 94 00:24:16 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10495; Mon, 3 Oct 1994 08:24:14 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18720; Mon, 3 Oct 1994 08:24:12 +0100 Message-Id: <9410030724.AA18720@dxcoms.cern.ch> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Mon, 3 Oct 1994 08:24:12 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410022050.aa04244@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Oct 2, 94 08:50:55 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2370 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, Was this triggered by something I said? I've lost track of it. Anyway I agree with you. Machines that start routing by default are a disaster, especially if they run RIP. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 >--------- Text sent by Ran Atkinson follows: > > > Brian, > > I have a fair number of multi-homed hosts. I do want them to make > reasonable choices when selecting an outgoing interface. I do NOT > want them to participate in routing in ANY manner. Eavesdropping on > RIP is considered particularly undesirable in my environment and I > cannot see any value to such eavesdropping in my environment. The > current router selection proposal for IPv6 Discovery appears to be > just like the extant IPv4 Router Discovery (which is in wide use and > seems to work well). I'd like to keep that approach to Router > Discovery in IPv6. > > IMHO, the IPv6 specs MUST NOT require that multi-homed hosts act in > any way as routers. If particular users wish to turn multi-homed > hosts into routers (many customers do) then that should be supported > by host vendors, though it should require sys admin intervention > toconfigure and enable routing and should not be automatically turned > on. In practice this means that host vendors have to ship kernels > that can support IP forwarding (as has been noted several times > already). > > The main change I'd make from the current practice is one that > appears to be outside the IETF scope. That change is to remove the > code inside most vendors /etc/rc* scripts to _automatically_ enable > RIP routing whenever the host detects that it has more than 2 > interfaces. I'd like to see manual configuration be required before > any host turned itself _automatically_ into a router. A second change > I'd like to see would be killing off routed(8) entirely and replacing > it with something (e.g. gated(8)) that supported at least OSPFv2 > (possibly also supporting a modern version of RIP for backwards > compatibility reasons). > > Regards, > > Ran > atkinson@itd.nrl.navy.mil > > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 02:26:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00982; Mon, 3 Oct 94 02:26:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00970; Mon, 3 Oct 94 02:25:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28123; Mon, 3 Oct 94 02:22:28 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA17319; Mon, 3 Oct 94 02:22:05 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA00932; Mon, 3 Oct 1994 02:06:03 -0700 Date: Mon, 3 Oct 1994 02:06:03 -0700 From: Tony Li Message-Id: <199410030906.CAA00932@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: Ran Atkinson's message of Sun, 2 Oct 94 20:50:55 GMT <9410022050.aa04244@sundance.itd.nrl.navy.mil> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A second change I'd like to see would be killing off routed(8) entirely and replacing it with something (e.g. gated(8)) that supported at least OSPFv2 (possibly also supporting a modern version of RIP for backwards compatibility reasons). I strongly disagree. This will simply cause people to run OSPF on their hosts. Bad Idea. routed should just die. gated should be part of the host vendors "router package". Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 02:26:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00981; Mon, 3 Oct 94 02:26:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00969; Mon, 3 Oct 94 02:25:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28123; Mon, 3 Oct 94 02:22:28 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA17319; Mon, 3 Oct 94 02:22:05 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA00932; Mon, 3 Oct 1994 02:06:03 -0700 Date: Mon, 3 Oct 1994 02:06:03 -0700 From: Tony Li Message-Id: <199410030906.CAA00932@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ip-ng@sunroof2.Eng.Sun.COM In-Reply-To: Ran Atkinson's message of Sun, 2 Oct 94 20:50:55 GMT <9410022050.aa04244@sundance.itd.nrl.navy.mil> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A second change I'd like to see would be killing off routed(8) entirely and replacing it with something (e.g. gated(8)) that supported at least OSPFv2 (possibly also supporting a modern version of RIP for backwards compatibility reasons). I strongly disagree. This will simply cause people to run OSPF on their hosts. Bad Idea. routed should just die. gated should be part of the host vendors "router package". Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 09:28:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01176; Mon, 3 Oct 94 09:28:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01049; Mon, 3 Oct 94 07:12:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04939; Mon, 3 Oct 94 07:08:53 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA25983; Mon, 3 Oct 94 07:08:30 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA13401; Mon, 3 Oct 94 07:01:03 -0700 Received: by xirtlu.zk3.dec.com; id AA22446; Mon, 3 Oct 1994 10:01:00 -0400 Message-Id: <9410031401.AA22446@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Sun, 02 Oct 94 20:50:55 GMT." <9410022050.aa04244@sundance.itd.nrl.navy.mil> Date: Mon, 03 Oct 94 10:00:54 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, Not that I don't agree with your mail. But, routed et al are defacto standards not "dejure", and the IETF can only kill a defacto standard by providing a "formal" proposal for that standard and then having it be accepted by the market. We can't kill defacto standards by saying in non-related IPv6 specs you should not use "this or that" without proposing what exactly to use. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 09:28:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01183; Mon, 3 Oct 94 09:28:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01035; Mon, 3 Oct 94 06:40:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03873; Mon, 3 Oct 94 06:37:14 PDT Received: from texas.nynexst.com by Sun.COM (sun-barr.Sun.COM) id AA22532; Mon, 3 Oct 94 06:36:52 PDT Received: from dssar1.nynexst.com by texas.nynexst.com (4.1/SMI-4.1.nynexst) id AB00141; Mon, 3 Oct 94 09:36:42 EDT Date: Mon, 3 Oct 94 09:36:42 EDT From: ajay@nynexst.com (Ajay Joseph) Message-Id: <9410031336.AB00141@texas.nynexst.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NSAPs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ----- Begin Included Message ----- From owner-ipng@sunroof2.Eng.Sun.COM Fri Sep 30 18:41:51 1994 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Subject: Re: (IPng) NSAPs To: ipng@sunroof.Eng.Sun.COM Date: Fri, 30 Sep 1994 13:26:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 766 Sender: owner-ipng@sunroof.Eng.Sun.COM Reply-To: ipng@sunroof.Eng.Sun.COM Jack, 1. I have already had unofficial indications that the Finnish NSAP scheme could readily be compressed into the 16-byte format; in fact I told them to slow down because nothing is decided yet. 2. I suspect the ATM Forum will be looking very closely indeed at IPv6 addressing. In fact they could trivially use the proposed IPv6-in-NSAP embedding without changing much at all. (It remains a mystery to me why the ATM Forum chose to copy a Level 3 address format for Level 2 addressing, but that is another discussion.) Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ----- End Included Message ----- Brian, >>(It remains a mystery to me why the ATM Forum chose to copy a Level 3 address >>format for Level 2 addressing, but that is another discussion.) I guess by Level 3 you mean IPv6 what is Level 2 addresing in this context? The reason I am asking is because I had made a contribution to the ATMF on embedding IPv6 into the NSAP for ATM routing of IP. --Ajay-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 09:28:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01205; Mon, 3 Oct 94 09:28:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01101; Mon, 3 Oct 94 09:05:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12078; Mon, 3 Oct 94 09:02:32 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA14417; Mon, 3 Oct 94 09:02:09 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-17.dialip.mich.net [35.1.48.98]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA28098 for ; Mon, 3 Oct 1994 12:02:05 -0400 Date: Mon, 3 Oct 94 15:30:04 GMT From: "William Allen Simpson" Message-Id: <3284.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM KRE and I seem to be merrily agreeing right up until: > From: Robert Elz > I especially don't believe that the host's addresses are even > slightly useful to aid it in making the choice - there's too much > host specific knowledge required. In particular, in your .. > > Here, assume H1 has address xxxA1, and H2 has address xxxB2. > > no, not quite, H1 is xxxA1 and xxxB1, and H2 is xxxA2 and xxxB2 > and now H1 and H2 are no better off than they were before, the > preferences and advertisments coming from the router tell them > nothing You are absolutely right, if those addresses _were_ assigned. The confusion seems to be from familiarity with BSD subnets, the BSD expectation that every interface have a different IP address, and the BSD inability to cope with multiple subnets on a wire. BSD is _NOT_ the be-all and end-all of network code. Although it's too late for IPv4, we are trying to _fix_ the bogus BSD model for IPv6. I've worked on plenty of systems (MS-DOS, Mac, and embedded KA9Q NOS), where the node has a single IP address on several interfaces. I think that this will not be resolved in the low bandwidth mailing list, and should be a primary topic in person next week. > In reply (to him) I suggested that perhaps a formalised "routing > protocol snooping" - though that suggests the wrong thing - that > is, a third category of object perhaps, between hosts & routers, > for multi-homed hosts, which would listen to information sent from > the routers, and make decisions based on that. Single homed > hosts have much simpler decisions to make, and need much less > complexity (which I don't think anyone ever doubted). > > It may be that your draft provides this already, I'll wait for the > next release and read again more carefully. If so its doing rather > more than I had assumed it was - which is not at all undesireable, > in fact, it may be necessary. > Yes, my draft already provides this. The "other-identifier" extension which indicates the addresses on other interfaces for multi-homed nodes, both hosts and routers. Some people have complained that this is "routing" knowledge. Indeed, I sent a memo to the SIP list long ago showing how a very light weight maximum 2 hop routing protocol could be created. SIP WG rejected that proposal, and it is probably best to stick with the decision. But, yes, you and I are trying to solve many of the same problems. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 09:28:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01202; Mon, 3 Oct 94 09:28:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01056; Mon, 3 Oct 94 07:16:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05139; Mon, 3 Oct 94 07:12:44 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA26455; Mon, 3 Oct 94 07:12:20 PDT Received: from relay.imsi.com by wintermute.imsi.com id KAA03067 for ; Mon, 3 Oct 1994 10:12:07 -0400 Received: from snark.imsi.com by relay.imsi.com id KAA09932 for ; Mon, 3 Oct 1994 10:12:07 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01802; Mon, 3 Oct 94 10:12:06 EDT Message-Id: <9410031412.AA01802@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 02:06:03 PDT." <199410030906.CAA00932@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 03 Oct 1994 10:12:06 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > > A second change > I'd like to see would be killing off routed(8) entirely and replacing > it with something (e.g. gated(8)) that supported at least OSPFv2 > (possibly also supporting a modern version of RIP for backwards > compatibility reasons). > > I strongly disagree. This will simply cause people to run OSPF on > their hosts. Bad Idea. routed should just die. gated should be part > of the host vendors "router package". In an environment where one depends on every local subnet to have multiple exit points to assure no single point of failure, and in which most critical hosts have more than one interface for the same reason (such networks resembling virtually all the networks clients of mine run) having a routing program on most machines seems to be a Good Thing. Are things going to work as well for me without such packages in the brave new world? I know that all the autodiscovery stuff is supposed to fix this -- but I'm not sure that it really will. I'm particularly concerned about what happens during extreme instability, which current schemes seem to handle very well. It seems that everyone is assuming the normal case to be very simpleminded hosts on fairly simpleminded networks, when those of us with real money riding on our nets abandoned that model a long time ago. I want to see the brave new world prototyped and running on real, complex networks before I, a real-world user, believe in it. (BTW, One of the tricks that have been a favorite of mine and of other people's for some time have been to have the routers (yes, Tony, I recommend Cisco these days :-) trust one routing protocol (typically a good one :-) and export information on another routing protocol that they do not believe -- this has allowed hosts to get the sort of rapid routing information updates for the very complex nets my clients tend to run without risk that the hosts might contaminate the routing protocols. Perhaps what we need is a routing information export protocol designed just to convey such information on routing maps determined by other protocols that hosts can listen to without contaminating.) Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 10:00:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01324; Mon, 3 Oct 94 10:00:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01041; Mon, 3 Oct 94 06:42:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03919; Mon, 3 Oct 94 06:38:44 PDT Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA22694; Mon, 3 Oct 94 06:38:19 PDT Received: by nero.dcrc.com (4.1/1.34) id AA02796; Mon, 3 Oct 94 09:37:57 EDT Date: Mon, 3 Oct 94 09:37:57 EDT From: mad@nero.dcrc.com (Michael A. Davis) Message-Id: <9410031337.AA02796@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Status of old SIPP/IPNG drafts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello, I am just starting to implement the SIPP specs, and have run into a few hitches that I may be able to resolve with your help. Please direct me to the correct forum if this is not it. My questions concern the following documents: draft-ietf-sipp-bsd-api-02.txt: Are there any changes to this draft other than replacing the various references to 64-bit with 128-bit? (Sections 1, 2, 4.2, 4.6). Is a modified document in the works? draft-ietf-sipp-icmp-igmp-00.txt: This document is more than 6 months old, so I wonder if it is being updated? Some parts of this document have been superceded by the new discovery documents. Should the other parts (Dest. Unreach, Time Exceeded, Parm. Problem, Redirect, Echo Request/Reply), be assumed current? Thanks -mad - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + Mike Davis + Do not use the return address + + Penril Datability Networks + Use mike@dss.com + + 190 North Main Street +- -- -- -- -- -- -- -- -- -- -- -+ + Natick, MA 01760 + "POST NO BILLS" + - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 11:31:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01533; Mon, 3 Oct 94 11:31:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01527; Mon, 3 Oct 94 11:31:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24534; Mon, 3 Oct 94 11:27:49 PDT Received: from ski.utah.edu ([128.110.124.10]) by Sun.COM (sun-barr.Sun.COM) id AA08658; Mon, 3 Oct 94 11:25:36 PDT Received: (from haas@localhost) by ski.utah.edu (8.6.9/8.6.9) id MAA27153; Mon, 3 Oct 1994 12:29:07 -0600 From: Tired of the Information Superhype Message-Id: <199410031829.MAA27153@ski.utah.edu> Date: Mon, 3 Oct 94 12:29:06 MDT Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM In-Reply-To: ipng@sunroof.Eng.Sun.COM, Mon, 03 Oct 1994 10:12:06 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry Metzger wrote: >In an environment where one depends on every local subnet to have >multiple exit points to assure no single point of failure, and in >which most critical hosts have more than one interface for the same >reason (such networks resembling virtually all the networks clients of >mine run) having a routing program on most machines seems to be a Good >Thing. Are things going to work as well for me without such packages >in the brave new world? I know that all the autodiscovery stuff is >supposed to fix this -- but I'm not sure that it really will. I'm >particularly concerned about what happens during extreme instability, >which current schemes seem to handle very well. It seems that everyone >is assuming the normal case to be very simpleminded hosts on fairly >simpleminded networks, when those of us with real money riding on our >nets abandoned that model a long time ago. I want to see the brave new >world prototyped and running on real, complex networks before I, a >real-world user, believe in it. Hear hear! I'm getting a little concerned about the talk of using Novell as a model... our experience with our (literally thousands) of Novell machines is that the convenience of autoconfiguration is bought at the price of operating reliability... the autoconfiguration mechanisms create dependencies that make the hosts much less reliable. The current IPv4 on the other hand requires lots of elaborate hand configuration, which is expensive, but the benefit is that one can shut down almost any box in an IPv4 network and all the other boxes will struggle along based on their hand-configured information. It's become a commonplace around here that when an application gets to be "serious", it migrates off the Novell network and onto a Unix system that speaks TCP/IP. Reliability isn't the only reason, of course, speed is another, but in general Novell can't compare with the performance and reliability of TCP/IP protocols. I would really hate to think of migrating to a new generation of IP that suffered some of the problems we see from Novell autoconfiguration. Perhaps a reasonable compromise would be autoconfiguration that can be overridden by hand configuration, for those applications where the increased reliability is worth the additional labor cost. -- Walt ------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 11:46:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01632; Mon, 3 Oct 94 11:46:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01626; Mon, 3 Oct 94 11:46:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26182; Mon, 3 Oct 94 11:42:57 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA11537; Mon, 3 Oct 94 11:42:26 PDT Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA25278; Mon, 3 Oct 1994 14:01:41 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA10011; Mon, 3 Oct 1994 14:01:39 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA00522; Mon, 3 Oct 1994 13:38:20 -0400 Message-Id: <9410031738.AA00522@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Discovery Date: Mon, 03 Oct 94 13:38:20 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM What makes a host act as a router? 1. forwarding packets 2. listening to routing information 3. diseminating (advertizing) routing information concerning itself In my view a host that does (1.), and (2.) without (3.) is not harmful. A host can do (1.) and (2.) only for its own traffic, without affecting other hosts. In many implementations multi-homed hosts do (1.) as an "internal pseudo-forwarding of packets". Also many hosts do (2.) and as long as the routing information that they collect is correct - this depends largely on those routers that advertize it - the damage that they may casue is minimal, if any. IPv6 makes this function at least partially a permanent function. I would say hosts SHOULD NOT do by default (3.), because that is what makes a host known as a router, and makes other hosts send packets to it for forwarding - I included creating static routes in (3.). Alex ========================= Ran, Was this triggered by something I said? I've lost track of it. Anyway I agree with you. Machines that start routing by default are a disaster, especially if they run RIP. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 >--------- Text sent by Ran Atkinson follows: > > > Brian, > > I have a fair number of multi-homed hosts. I do want them to make > reasonable choices when selecting an outgoing interface. I do NOT > want them to participate in routing in ANY manner. Eavesdropping on > RIP is considered particularly undesirable in my environment and I > cannot see any value to such eavesdropping in my environment. The > current router selection proposal for IPv6 Discovery appears to be > just like the extant IPv4 Router Discovery (which is in wide use and > seems to work well). I'd like to keep that approach to Router > Discovery in IPv6. > > IMHO, the IPv6 specs MUST NOT require that multi-homed hosts act in > any way as routers. If particular users wish to turn multi-homed > hosts into routers (many customers do) then that should be supported > by host vendors, though it should require sys admin intervention > toconfigure and enable routing and should not be automatically turned > on. In practice this means that host vendors have to ship kernels > that can support IP forwarding (as has been noted several times > already). > > The main change I'd make from the current practice is one that > appears to be outside the IETF scope. That change is to remove the > code inside most vendors /etc/rc* scripts to _automatically_ enable > RIP routing whenever the host detects that it has more than 2 > interfaces. I'd like to see manual configuration be required before > any host turned itself _automatically_ into a router. A second change > I'd like to see would be killing off routed(8) entirely and replacing > it with something (e.g. gated(8)) that supported at least OSPFv2 > (possibly also supporting a modern version of RIP for backwards > compatibility reasons). > > Regards, > > Ran > atkinson@itd.nrl.navy.mil > > --------------------------------------------------------------------------- ***--- > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not s ***ubject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 12:28:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01664; Mon, 3 Oct 94 12:28:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01658; Mon, 3 Oct 94 12:28:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29767; Mon, 3 Oct 94 12:24:49 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA19157; Mon, 3 Oct 94 12:24:16 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19880; Tue, 4 Oct 1994 05:12:45 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: next hop resolution In-Reply-To: Your message of "Mon, 03 Oct 1994 15:30:04 GMT." <3284.bill.simpson@um.cc.umich.edu> Date: Tue, 04 Oct 1994 05:12:36 +1000 Message-Id: <7672.781211556@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 3 Oct 94 15:30:04 GMT From: "William Allen Simpson" Message-ID: <3284.bill.simpson@um.cc.umich.edu> The confusion seems to be from familiarity with BSD subnets, Well, maybe, more from (perhaps) confusion on the way that IPv6 plans to handle routing and numbering... the BSD expectation that every interface have a different IP address, I thought that was an IPv6 expectation too (in fact, I thought that was more an IPv4 expectation than a BSD one). The IPv4 model, which I thought was being carried into IPv6, is that cables are labelled (this is as opposed to the area model), where a "cable" is whatever one can reach without passing through a router. Interfaces take addresses from the cables they are connected to. Am I suffering under a misunderstanding? Is this not the IPv6 model too? and the BSD inability to cope with multiple subnets on a wire. That's old BSD, and what's more seems to be irrelevant here. and should be a primary topic in person next week. Unfortunately, I won't be there, but I'll be interested to learb what transpires. Yes, my draft already provides this. Good. Some people have complained that this is "routing" knowledge. I hope they are right, but that their complaints are ignored. I don't care if its called routing knowledge or not though. Indeed, I sent a memo to the SIP list long ago showing how a very light weight maximum 2 hop routing protocol could be created. I doubt a "routing protocol" is needed for this, or not anything nearly full blown - what's needed might be a "routing information protocol" (ugh) - ie: a way for concerned hosts to learn information about routing from the routers, though not to participate. This is what I meant by "intermediate level" (between hosts and routers) in an earlier message. In another message, Perry Metzger suggested just the same ... Perhaps what we need is a routing information export protocol designed just to convey such information on routing maps determined by other protocols that hosts can listen to without contaminating. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 12:37:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01687; Mon, 3 Oct 94 12:37:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01681; Mon, 3 Oct 94 12:37:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00626; Mon, 3 Oct 94 12:33:34 PDT Received: from atlas.xylogics.com by Sun.COM (sun-barr.Sun.COM) id AB20662; Mon, 3 Oct 94 12:32:32 PDT Received: by atlas.xylogics.com id AA15597 (5.65c/UK-2.1-940401); Mon, 3 Oct 1994 13:57:22 -0400 From: Gary Scott Malkin Date: Mon, 3 Oct 1994 13:57:22 -0400 Message-Id: <15597.199410031757@atlas.xylogics.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: bound@zk3.dec.com's message of Mon, 03 Oct 94 10:00:54 -0400 <9410031401.AA22446@xirtlu.zk3.dec.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > But, routed et al are defacto > standards not "dejure" I beg to differ. Routed runs RIP as defined in RFC 1058. It is a full Internet Standard (STD 34). ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two! ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 13:00:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01723; Mon, 3 Oct 94 13:00:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01711; Mon, 3 Oct 94 12:59:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02395; Mon, 3 Oct 94 12:56:30 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA23680; Mon, 3 Oct 94 12:49:59 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA04683; Mon, 3 Oct 1994 12:49:39 -0700 Date: Mon, 3 Oct 1994 12:49:39 -0700 From: Tony Li Message-Id: <199410031949.MAA04683@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com In-Reply-To: conta@zk3.dec.com's message of Mon, 03 Oct 94 13:38:20 -0400 <9410031738.AA00522@brigit.zk3.dec.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, 1. forwarding packets 2. listening to routing information 3. diseminating (advertizing) routing information concerning itself Also many hosts do (2.) and as long as the routing information that they collect is correct - this depends largely on those routers that advertize it - the damage that they may casue is minimal, if any. IPv6 makes this function at least partially a permanent function. Unfortunately, with modern routing protocols, there's no way for a host to do (2) without creating a non-trivial overhead for the routing fabric. But I believe that there is a good alternative, as other people have hinted at. Imagine a routing information query protocol. The host, on having traffic to send fires a query to its selected router(s). [Note that there is no RTT delay as the first packet can be sent irrespective of optimality.] The router(s) reply(s) with a selection of information: metric, administrative distance, next hop, lifetime, and prefix. The host now populates a cache with the information with the optimal administrative distance and metric. The entry is expired after the given lifetime. The next hop allows for on-cable shortcuts. The prefix allows the router to help the host generalize. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 13:06:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01736; Mon, 3 Oct 94 13:06:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01730; Mon, 3 Oct 94 13:06:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02842; Mon, 3 Oct 94 13:02:50 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AB25096; Mon, 3 Oct 94 13:00:09 PDT Received: from relay.imsi.com by wintermute.imsi.com id PAA03778 for ; Mon, 3 Oct 1994 15:58:17 -0400 Received: from snark.imsi.com by relay.imsi.com id PAA11859 for ; Mon, 3 Oct 1994 15:58:16 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02308; Mon, 3 Oct 94 15:58:16 EDT Message-Id: <9410031958.AA02308@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 12:29:06 MDT." <199410031829.MAA27153@ski.utah.edu> X-Reposting-Policy: redistribute only with permission Date: Mon, 03 Oct 1994 15:58:15 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tired of the Information Superhype says: > Hear hear! I'm getting a little concerned about the talk of using Novell > as a model... our experience with our (literally thousands) of Novell > machines is that the convenience of autoconfiguration is bought at the > price of operating reliability... the autoconfiguration mechanisms create > dependencies that make the hosts much less reliable. The current IPv4 > on the other hand requires lots of elaborate hand configuration, which is > expensive, but the benefit is that one can shut down almost any box in > an IPv4 network and all the other boxes will struggle along based on their > hand-configured information. Actually, my experience has been that its fairly straightforward to build automated configuration systems for running IPv4 networks and their hosts. At Lehman Brothers, for instance, we built a network management system and configuration tools that meant that no host on the network ever had any of its networking information manually configured -- indeed, we'd virtually eliminated all manual steps associated with machine installation and configuration. The solution was not new protocols but very powerful management databases and fairly potent automated installation systems to "implement" what the databases "knew". Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 13:12:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01756; Mon, 3 Oct 94 13:12:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01750; Mon, 3 Oct 94 13:12:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03365; Mon, 3 Oct 94 13:08:50 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA26172; Mon, 3 Oct 94 13:06:15 PDT Subject: (IPng) Address-per-interface To: IPng Mailing list Date: Mon, 3 Oct 1994 15:59:11 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 881 Message-Id: <9410032059.aa05416@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I've been watching the kre - Simpson exchange regarding address-per-interface. My take on this has been: * An interface in IPv6 has AT LEAST one unique address per interface. This means that multiple subnets per interface can exist. * The stated reason for this is because of multicast group difficulties. I'm not the expert on multicast, but if Steve Deering comes out of hiding, I'm sure he'll be happy to explain. * Another good reason for sticking with what I believe to be the case (>=1 address per interface) is that according to Ran, no trusted system can be built B1 or higher with one address over multiple interfaces. (Think of the "Secret" interface, the "unclassified" interface, and the "Top Secret" interface, all on the same machine.) I agree with Dr. Elz on this one. I'd like to see what the "official" line is on this. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 14:51:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02597; Mon, 3 Oct 94 14:51:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02587; Mon, 3 Oct 94 14:51:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11823; Mon, 3 Oct 94 14:47:41 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA12041; Mon, 3 Oct 94 14:47:02 PDT Received: from relay.imsi.com by wintermute.imsi.com id RAA04031 for ; Mon, 3 Oct 1994 17:27:22 -0400 Received: from snark.imsi.com by relay.imsi.com id RAA12658 for ; Mon, 3 Oct 1994 17:27:21 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02436; Mon, 3 Oct 94 17:27:21 EDT Message-Id: <9410032127.AA02436@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 12:49:39 PDT." <199410031949.MAA04683@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 03 Oct 1994 17:27:20 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > Unfortunately, with modern routing protocols, there's no way for a > host to do (2) [listening in on routing information] without > creating a non-trivial overhead for the routing fabric. > > But I believe that there is a good alternative, as other people have > hinted at. Imagine a routing information query protocol. The host, > on having traffic to send fires a query to its selected router(s). > [Note that there is no RTT delay as the first packet can be sent > irrespective of optimality.] The router(s) reply(s) with a selection > of information: metric, administrative distance, next hop, lifetime, > and prefix. > > The host now populates a cache with the information with the optimal > administrative distance and metric. The entry is expired after the > given lifetime. The next hop allows for on-cable shortcuts. The > prefix allows the router to help the host generalize. This is the problem as I see it. What happens during periods of problems? Right now, my major client has a fully redundant network in which all hosts run routed. The cisco routers export, but do not trust, RIP; they route using IGRP. If a router goes south, within moments all the hosts on any given cable have been told to use the other one attached to the same cable. This is very solid and reliable. Now, in your proposed scheme, I'll have cached routing information for both routers, and UNTIL I ASK FOR THE INFORMATION AGAIN, my packets for huge chunks of my network will go into a black hole. When you really rely on your network, you can't have a situation like that happen. This isn't acceptable. I can't convince my clients to downgrade to a situation where their network will be less reliable. I think its a good idea that hosts be informed of routing changes by a mechanism other than the ordinary routing protocols, both to reduce overhead and to prevent route contamination by rogue hosts. However, the mechanism must somehow inform hosts of routing problems ASAP in order to prevent the sort of of problem I just described. Any mechanism that results in less reliability than I have now isn't a good idea. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 14:54:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02653; Mon, 3 Oct 94 14:54:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02644; Mon, 3 Oct 94 14:54:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12218; Mon, 3 Oct 94 14:50:37 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA12968; Mon, 3 Oct 94 14:49:52 PDT Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA04432; Mon, 3 Oct 1994 17:49:32 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA05603; Mon, 3 Oct 1994 17:49:29 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA00785; Mon, 3 Oct 1994 17:26:08 -0400 Message-Id: <9410032126.AA00785@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: kre@munnari.OZ.AU, bsimpson@morningstar.com, conta@zk3.dec.com Subject: Re: (IPng) Re: next hop resolution In-Reply-To: Your message of "Tue, 04 Oct 94 05:12:36 +1000." <7672.781211556@munnari.OZ.AU> Date: Mon, 03 Oct 94 17:26:08 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>The confusion seems to be from familiarity with BSD subnets, > Well, maybe, more from (perhaps) confusion on the way that IPv6 > plans to handle routing and numbering... >> the BSD expectation that every interface have a different >> IP address, > I thought that was an IPv6 expectation too (in fact, I thought > that was more an IPv4 expectation than a BSD one). The IPv4 > model, which I thought was being carried into IPv6, is that > cables are labelled (this is as opposed to the area model), > where a "cable" is whatever one can reach without passing through > a router. Interfaces take addresses from the cables they are > connected to. Am I suffering under a misunderstanding? Is this > not the IPv6 model too? That was my understanding too. At any rate, having one IPv6 address associated with multiple interfaces is OK, whether all interfaces are part of the same subnet or not. The case of an association between multiple IPv6 addresses and multiple interfaces needs some clarification though in case they are part of different subnets. The clarification is that if a packet is sent to a host that is directly connected to the same link (wire), the source IPv6 address that the host puts in the IPv6 header must have the same subnet as the destination IPv6 address. This will prevent confusion if the source and destination have to be reversed. >> and the BSD inability to cope with multiple subnets on a wire. > That's old BSD, and what's more seems to be irrelevant here. Very old BSD. >> Some people have complained that this is "routing" knowledge. >I hope they are right, but that their complaints are ignored. >I don't care if its called routing knowledge or not though. >>Indeed, I sent a memo to the SIP list long ago showing how a very light >>weight maximum 2 hop routing protocol could be created. >I doubt a "routing protocol" is needed for this, or not anything >nearly full blown - what's needed might be a "routing information >protocol" (ugh) - ie: a way for concerned hosts to learn >information about routing from the routers, though not to >participate. This is what I meant by "intermediate level" >(between hosts and routers) in an earlier message. >In another message, Perry Metzger suggested just the same ... >Perhaps what we need is a routing information export >protocol designed just to convey such information on routing maps >determined by other protocols that hosts can listen to without >contaminating. And use ICMP as a pseudo-transport? I would not give up UDP. For reasons I stated in an earlier mail, it is cheaper to implement and use a 'transport' for delivering 'routing information' than a 'pseudo-transport' like ICMP. Besides, the separation of routing information disemination/listening, routing information processing, routing cache (table) creation/updating on one side, from routing decision making on the other side, was a big step forward that IPv4 achieved in simplifying the routing layer and the communications kernels, as well as providing great flexibility in adopting various routing protocols and algorithms. IPv4 was and is superior in that, to other networking architectures, which are older or not. It allowed implementation of routing daemons in the application layer, where space and processing cost is cheap, and minimize the routing sublayer in the IP layer where space and processing cost is expensive. We have to be careful and not lose in IPv6 what IPv4 achieved so elegantly. Additionally, I think that the ICMP as an error and control protocol has to be kept at a minimum in terms of complexity, which translates to an acceptable minimum in terms of infomation passed in packets, and acceptable minimum in terms of processing. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 14:57:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02711; Mon, 3 Oct 94 14:57:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02701; Mon, 3 Oct 94 14:57:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12560; Mon, 3 Oct 94 14:53:57 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13659; Mon, 3 Oct 94 14:52:59 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA21010; Mon, 3 Oct 94 14:26:39 -0700 Received: by xirtlu.zk3.dec.com; id AA13416; Mon, 3 Oct 1994 17:26:23 -0400 Message-Id: <9410032126.AA13416@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 94 13:38:20 EDT." <9410031738.AA00522@brigit.zk3.dec.com> Date: Mon, 03 Oct 94 17:26:17 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Does everyone realize that many UNIX Servers exists at end user sites with two Ethernets separating two networks. This is the forward (1) mentioned in Alex's mail. End users do this often to avoid the cost of buying a router. I don't think we should break this ability with IPv6 for end users. I also think we need to discuss Alex's (3) point because I think hosts should be able to solicit addresses during discovery. Especially in the Dentist office. But I agree it may not be the default. p.s. I know there are other systems than UNIX but having worked on most major UNIX hosts I know that all of them have documentation on how to set up the above and it pretty much looks the same and very easy to do. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 14:59:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02742; Mon, 3 Oct 94 14:59:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02735; Mon, 3 Oct 94 14:58:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12715; Mon, 3 Oct 94 14:55:29 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13807; Mon, 3 Oct 94 14:53:44 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA20041; Mon, 3 Oct 94 14:10:42 -0700 Received: by xirtlu.zk3.dec.com; id AA12931; Mon, 3 Oct 1994 17:10:18 -0400 Message-Id: <9410032110.AA12931@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 94 10:12:06 EDT." <9410031412.AA01802@snark.imsi.com> Date: Mon, 03 Oct 94 17:10:11 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I agree with Tony and Perry. We use routed for over 300 developers and none of the hosts have to much at all to get connected to our IP development network and this is just one group in my company. I look forward to the brave new world too. I even believe some of it will be better. But as one of the IETFers trying to work with my colleagues to build a prototype to test this brave new world I have to tell you we can't implement discovery, icmp, orutoconfig based on present specs and as I said before I am past the point of justifying throw away code unless we reached consensus on a spec and then revisited that spec per interoperability testing (in this case its OK to throw away the code if the implementation is bogus). So I agree until I see this brave new discovery world running (and more than just a LAN) I will keep in my reserve routed and gated as options for IPv6. I will highly object to folks killing either without demonstrating real code that will perform the same function. I mean folks we are still asking bootstrap questions and we still don't know how to build a local address and whether we have consensus to use IEEE MAC Addresses. I hope after San Jose some of this is nailed down. This is not pessimistic but where I thought we would be in Oct 94. And we still have not finished the discussion of the grand host view vs the grand router view. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 15:33:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03044; Mon, 3 Oct 94 15:33:20 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03036; Mon, 3 Oct 94 15:32:58 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA08319; Mon, 3 Oct 1994 15:29:30 -0700 Date: Mon, 3 Oct 1994 15:29:30 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410032229.PAA08319@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199410031949.MAA04683@lager.cisco.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony, > But I believe that there is a good alternative, as other people have > hinted at. Imagine a routing information query protocol. The host, > on having traffic to send fires a query to its selected router(s). > [Note that there is no RTT delay as the first packet can be sent > irrespective of optimality.] The router(s) reply(s) with a selection > of information: metric, administrative distance, next hop, lifetime, > and prefix. How would you think this would work for multihomed hosts? Bob ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 15:47:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03121; Mon, 3 Oct 94 15:47:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03115; Mon, 3 Oct 94 15:46:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16328; Mon, 3 Oct 94 15:43:24 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA22199; Mon, 3 Oct 94 15:42:58 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Discovery Date: Mon, 3 Oct 94 23:38:46 GMT From: Ran Atkinson Message-Id: <9410032338.aa05701@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian, My apologies for confusing who wrote which note. Jim, I intended to make clear that I don't think that the IETF can/should prevent vendors from shipping routed(8). I was trying to say that IMHO _good_ vendors will ship something better than routed(8) [for example gated(8)] as part of their "host as router" software set. If I do turn a host into a router, I'd always like to use a really good routing protocol (such as OSPF) rather than RIP. IMHO, good vendors also won't ever automatically turn a host into a router with boot-time shell scripts (as DEC, Sun, SGI, and HP currently appear to do :-). Tony, I think we are agreeing violently. I am strongly opposed to hosts that automatically turn themselves into routers. I agree that ALL routing software, whether routed(8), gated(8), or something else, should be part of a separate "host as router" software set (possibly included with the base OS shipment, but not automatically turned on ever). Perry, I suspect that IPv4 Router Discovery would turn out to be a perfectly fine way for your hosts to get the data that they really need. Hence, I suspect that the listen-only use of routed(8) can be replaced in most (all ?) cases by good router configuration and host use of rdisc(8). This approach clearly doesn't work if one has older host software that doesn't support router discovery, but most modern OS releases do support router discovery. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 16:20:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03317; Mon, 3 Oct 94 16:20:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03310; Mon, 3 Oct 94 16:20:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19507; Mon, 3 Oct 94 16:17:12 PDT Received: from black-ice.cc.vt.edu ([128.173.14.71]) by Sun.COM (sun-barr.Sun.COM) id AA26889; Mon, 3 Oct 94 16:10:05 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id RAA25415; Mon, 3 Oct 1994 17:19:17 -0400 Message-Id: <199410032119.RAA25415@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 13:38:20 EDT." <9410031738.AA00522@brigit.zk3.dec.com> From: Valdis.Kletnieks@vt.edu Date: Mon, 03 Oct 1994 17:19:16 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Mon, 03 Oct 1994 13:38:20 EDT, you said: > 1. forwarding packets > ... > In my view a host that does (1.), and (2.) without (3.) is not harmful. A > host can do (1.) and (2.) only for its own traffic, without affecting other > hosts. In many implementations multi-homed hosts do (1.) as an I see some problems here. A host may have interfaces on several cables, and snarf up and internally forward packets headed for it's own 'other' interface. I have some problems with this, as for many media, the originating host will have dropped the packet on the wire pointed at the router that "officially" gates to the destination network - this implies either that the host can say "Hey wait a moment, I can grab it instead" which is uncomfortably close to a routing protocol, or promiscuously suck in packets, and somehow deal with the router sending a (now) duplicate to the other interface. The other case is 'several interfaces on the same cable'. I'm not sure what the pragmatics of internally routing between interfaces is here, but I suspect that what's needed is a better way of telling the sending host where to go to in the first place (ie 'shuffle address' DNS entries, etc). Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 16:25:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03351; Mon, 3 Oct 94 16:25:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03344; Mon, 3 Oct 94 16:25:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19889; Mon, 3 Oct 94 16:22:06 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA28964; Mon, 3 Oct 94 16:21:18 PDT Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA07994; Mon, 3 Oct 1994 19:20:14 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA17217; Mon, 3 Oct 1994 19:20:06 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA00905; Mon, 3 Oct 1994 18:56:46 -0400 Message-Id: <9410032256.AA00905@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: (IPng) preliminary IPv6 ICMP specs for review Date: Mon, 03 Oct 94 18:56:46 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Note: Steve Deering didn't have a chance to review this latest variant of the document. Your comments and suggestions will be included and the next version of the document will be made available as an Internet-Draft. Thanks, Alex -------------------------------------- Network Workging Group S. Deering (Xerox PARC) INTERNET-DRAFT A. Conta (Digital Equipment Corporation) September 1994 ICMP and IGMP for the Internet Protocol Version 6 (IPv6) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. Table of Contents 1. Introduction.......................................1 2. ICMP for IPv6......................................2 2.1 Destination Unreachable Message.............5 2.2 Time Exceeded Message.......................7 2.3 Parameter Problem Message...................8 2.4 Echo and Echo Reply.........................9 2.5 Solicitation................................10 2.6 Advertisment................................10 3. IGMP for IPv6......................................10 4. References.........................................12 5. Acknowledgements...................................13 6. Security Considerations............................13 1. Introduction The Internet Protocol Version 6 (IPv6) is a new version of IP. IPv6 uses the Internet Control Message Protocol (ICMP [1]) and the Internet Group Management Protocol (IGMP [7]) as defined for IP v4 with a few changes. This document describes the format of control messages used in ICMP Expires in six months [Page 1] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 and IGMP for IPv6. This document does not describe the procedures that use these messages to achieve functions like Router Discovery and Path MTU Discovery; these procedures are described in companion documents ([4], [5], and [6]). Terminology defined in the IPv6 specification [2] and the IPv6 Routing and Addressing specification [3] applies to this document as well. 2. ICMP for IPv6 IPv6 Internet Control Message Protocol (IPv6 ICMP) is used by IPv6 routers to report errors encountered in processing packets. IPv6 hosts may also send IPv6 ICMP messages; the Echo message is one such. As with IPv4, IPv6 ICMP is an integral part of IPv6 and MUST be implemented by every IPv6 host. ICMP messages are grouped into two classes. ICMP error messages: Destination Unreachable Time Exceeded Parameter Problem ICMP query messages: Advertisement Solicitation Echo and Echo Reply This document defines the message formats for the following IPv6 ICMP messages: Destination Unreachable (see section 2.1) Time Exceeded (see section 2.2) Parameter Problem (see section 2.3) Echo and Echo Reply (see section 2.4) [6] defines in detail the message formats for the following IPv6 ICMP messages: Advertisement Solicitation Every IPv6 ICMP message is preceded by a IPv6 header and zero or more IPv6 option headers. The header immediately preceding the IPv6 ICMP message MUST have a Next Header Type of 1. Expires in six months [Page 2] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 Like IPv4 ICMP messages, IPv6 ICMP messages have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Body | | | The type field indicates the type of the message. Its value determines the format of the remaining data. The code field depends on the message type. It is used to create an additional level of message granularity. The checksum is the 16-bit one's complement of the one's complement sum of the IPv6 Source Identifying Address, the IPv6 Destination Identifying Address, the IPv6 Payload Length, the IPv6 Next Header Type, and the entire ICMP message starting with the ICMP message type. (The rationale for this checksum computation is described in [2]). For computing the checksum, the checksum field is zeroed. If the destination of a transmitted ICMP message, or the source of a received ICMP message, is an IPv4 host (the IPv6 address would indicate such a host [8]), the checksum is the 16-bit one's complement of the one's complement sum of the IPv6 Source Identifying Address, the IPv6 Destination Identifying Address, the IPv6 Next Header Type and the entire ICMP message starting with the ICMP message type. Implementation Note: An application that sends ICMP messages has to fill in the ICMP header both the Source and Destination IPv6 Addresses before calculating the checksum. If the host has multiple source addresses, it is necessary to make an appropriate selection, based on the destination address, type of service, and flow id. This requires the implementation of a function: source_ipv6_address = get_source_address ( destination_ipv6_address, type_of_service, flow-id ) The following rules are suggested for implementing this mapping: (a) If the remote Internet address lies on one of the (sub)nets to which the host is directly connected, a corresponding source address may be chosen, unless the corresponding interface is known Expires in six months [Page 3] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 to be down. (b) The route cache may be consulted, to see if there is an active route to the specified destination network through any network interface; if so, a local IPv6 address corresponding to that interface may be chosen. If the route cache does not contain information about static routes or default routers, then consult similarly: (c) The table of static routes, and (d) The table of default routers. As default routers may be associated with a preference, chose the highest preference router. As with IPv4 ICMP, implementations MUST observe the following rules when processing IPv6 ICMP messages (from [9]): If an IPv6 ICMP message of unknown type is received, it MUST be silently discarded. Every IPv6 ICMP error message (the first three messages in the above list) includes as much of the IPv6 offending (invoking) packet (the packet that causes the error) as it will give clear indication of the problem and it will fit without making the error message packet exceed 576 octets. In case the ICMP packet that would result exceeds the size of 576 octets, then there are two options: I. to truncate the ICMP packet to a size of 576 octets, in which case, it is probable that useful information from the offending IPv6 packet gets lost. II. select from the offending IPv6 packet header the information that is relevant to the problem and its cause, and put that in the ICMP packet. This can be done as it follows: divide the ICMP information in two parts: 1. mandatory: information that defines, and describes the error, and its cause. This information is the minimum that the sender of the offender IPv6 packet needs to take an appropriate action. 2. optional: Expires in six months [Page 4] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 information that does not relate directly to the error, but can supply additional characterization of the offender IPv6 packet. The optional information may be useful in logging ICMP messages, or crash dump analysis at the host or router that sent the offender IPv6 packet. Discussion: If the error condition was created by: a. the IPv6 header, then return the IPv6 header in totality. Returning subsequent IPv6 extension headers, transport headers and user data is optional. b. an IPv6 extension header, then return the IPv6 header and the offending IPv6 extension header in totality, in that order. Returning the other IPv6 extension headers, and transport headers is optional. If returning the offending IPv6 extension header does not fit in 576 octets, then remove the next preceding IPv6 extension headers until the offending IPv6 extension header fits. c. transport header then return the IPv6 header, IPv6 extension headers and transport header in totality. If all IPv6 headers and the offending transport header do not fit in the ICMP packet maximum size of 576 bytes, then return the IPv6 header, followed by as much of the IPv6 extension headers as possible, to fit the transport header in totality. Returning transport option headers and user data is optional. NOTE: The length of the removed IPv6 extension headers can be specified in the In those cases where the Internet layer is required to pass a IPv6 ICMP error message to the transport layer, the IPv6 Transport Protocol MUST be extracted from the original header (contained in the body of the IPv6 ICMP error message) and used to select the appropriate transport protocol entity to handle the error. An IPv6 ICMP error message MUST NOT be sent as a result of receiving: Expires in six months [Page 5] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 an IPv6 ICMP error message, or a packet destined to an IPv6 multicast address (an exception to this rule is the "packet too big" Destination Unreachable Message - Section 2.1 - to allow Path MTU discovery to work for IPv6 multicast), or a packet sent as a link-layer broadcast, or a non-initial fragment, or a packet whose source address does not uniquely identify a single host -- e.g., the IPv6 Unspecified Address, the IPv6 Loopback Address, or an IPv6 multicast address. Finally, to each sender of an erroneous data packet, an IPv6 node SHOULD not send more than N ICMP error messages per second. The value of N should be fixed. The value of for N is recom- mended. The following sections describe the message formats for the above IPv6 ICMP messages. 2.1. Destination Unreachable Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | | as will give information about | | the problem and its cause and | | as will fit without error packet | | exceeding 576 octets | | | IPv6 Fields: Source Address The IPv6 address of the host or router that composes (sends) the ICMP message. Destination Address The IPv6 address of the host or router to which the ICMP message is sent. IPv6 ICMP Fields: Expires in six months [Page 6] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 Type 3 Code 0 - router address unreachable 1 - host address unreachable 2 - next header type unknown 3 - port unreachable 4 - packet too big 5 - unused 6 - destination network unkown 7 - destination host unknown 8 - source host isolated 9 - communication with destination network administratively prohibited 10 - communication with destination host administratively prohibited 11 - router unreachable for type of service 12 - host unreachable for type of service 13 - router unreachable for flow id 14 - host unreachable for flow id Unused This field is unused for all code values other than 4 and must have a zero value. For the "packet too big" message (code 4), the higher order 16-bits of this field are unused and must have a zero value and the lower order 16-bits contain the next-hop MTU size [4]. If in returning the offending IPv6 packet header information in the ICMP message some of the IPv6 extension headers had to be removed, then the 'unused' part of this field MAY contain the size of the removed part. Description A Destination Unreachable SHOULD be sent by a router in response to a packet which it cannot forward either because the next router destination address is unreachable (code 0), the host destination address is unreachable (code 1), the next router destination address is unknown (code 6), the host destination address is unknown (code 7), or if the router is administratively prohibited from forwarding packets to the destination of the IPv6 packet either to a router (code 11), or to the final destination which is a host (code 12). A router SHOULD generate a Destination Unreachable message in response to a packet when the packet's IPv6 type of service (code 11) or flow id (code 13) is not recognized . A Destination Unreachable MUST be sent by a router in response to a packet which it cannot forward because the packet is larger than the MTU of the outgoing link (code 4). A host SHOULD generate a Destination Unreachable message in response to a packet when the packet's IPv6 Next Header Type is not recognized Expires in six months [Page 7] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 (code 2), or when the transport protocol indicated by the Next Header Type field (such as UDP) is unable to demultiplex the packet (code 3) but has no protocol mechanisms to inform the sender. A host SHOULD generate a Destination Unreachable message in response to a packet when the packet's IPv6 Type of Service (code 12) or flow ID (code 14) is not recognized. The minimum legal value of the next-hop MTU field in a "packet too big" message (code 4) received by an IPv6 host is 68 octets. While IPv6 requires all links in the Internet to have an MTU of 576 octets or greater, the smaller minimum legal value is required to allow Path MTU discovery to work correctly when IPv6 packets are undergo translation to IPv4 packets (see Section 5 in [8]). It is expected that routing information advertized by routers will include accurate PMTU information. If PMTU information is not available, a host sending packets that need fragmentation in a router will receive from that router the ICMP (code 4) message that will indicate the appropriate value for PMTU. The host SHOULD store that PMTU information and use it for subsequent packets sent to the same destination. Using this mechanism, if the packets are traversing several networks (forwarded by several routers), a host may receive several ICMP (code 4) messages until the PMTU to the final destination is learned. It is up to the transport or application protocol to make sure that packets lost because of unadequoate PMTU are retransmitted. 2.2. Time Exceeded Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | | as will give information about | | the problem and its cause and | | as will fit without error packet | | exceeding 576 octets | | | IPv6 Fields: Source Address The IPv6 address of the host or router that composes (sends) the ICMP message. Destination Address Expires in six months [Page 8] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 The IPv6 address of the host or router to which the ICMP message is sent. IPv6 ICMP Fields: Type 11 Code 0 - hop limit exceeded in transit 1 - fragment reassembly time exceeded Unused If in returning the offending IPv6 packet header information in the ICMP message some of the IPv6 extension headers had to be removed, then the 'unused' part of this field MAY contain the size of the removed part. Description If an IPv6 router encounters an IPv6 packet with a zero hop limit, it discards the packet and sends an IPv6 ICMP Time Exceeded message with code 0. This indicates either a routing loop or too small an initial hop limit value. IPv6 systems are expected to avoid fragmentation by implementing Path MTU discovery. However, IPv6 defines an end-to-end fragmentation function for backwards compatibility with existing higher-layer pro- tocols and IPv4-to-IPv6 translation. From [9], the IPv6 layer within IPv6 hosts MUST implement reassembly of IPv6 fragments. There MUST be a reassembly timeout. The reassem- bly timeout SHOULD be a fixed value. It is recommended that this value lie between 60 and 120 seconds. If the timeout expires, the partially-reassembled datagram MUST be discarded. If the fragment with offset zero was received, the destination host SHOULD also send an IPv6 ICMP Time Exceeded message with code 1. An incoming Time Exceeded message MUST be passed to the transport layer. 2.3. Parameter Problem Message Expires in six months [Page 9] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of invoking packet | | as will give information about | | the problem and its cause and | | as will fit without error packet | | exceeding 576 octets | | | IPv6 Fields: Source Address The IPv6 address of the host or router that composes (sends) the ICMP message. Destination Address The IPv6 address of the host or router to which the ICMP message should be sent. IPv6 ICMP Fields: Type 12 Code 0 means Pointer field indicates incorrect parameter. Pointer If code = 0, identifies the octet offset within the invoking packet where an error was detected. Unused If in returning the offending IPv6 packet header information in the ICMP message some of the IPv6 extension headers had to be removed, then the 'unused' part of this field MAY contain the size of the removed part. Description If an IPv6 node processing a packet finds a problem with the parame- ters in the IPv6 header or optional headers such that it cannot com- plete processing the packet, it MUST discard the packet and SHOULD send an ICMP Parameter Problem message. Unlike the corresponding IPv4 ICMP message, the Pointer occupies the lower 16-bits of the second 32-bit word. 2.4 Echo and Echo Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Expires in six months [Page 10] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+- IPv6 Fields: Source Address The IPv6 address of the host or router that composes (sends) the ICMP message. Destination Address The IPv6 address of the host or router to which the ICMP message should be sent. IPv6 ICMP Fields: Type 0 - Echo Reply Message 8 - Echo Message Code 0 Identifier If code = 0, some identifier to match echo messages with echo replies. May be zero. Sequence Number If code = 0, a sequence number to aid in matching echo messages with echo replies. May be zero. Description The data received in the echo message must be returned unmodified in the echo reply message. Implementation Note: An application that sends ICMP ECHO messages has to fill in the ICMP header both the Source and Destination IPv6 Addresses before calculating the checksum. See the Implementation Note in Section 2. Expires in six months [Page 11] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 2.5. Solicitation 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Body | | | Type 10 [6] defines in detail this ICMP message header format. 2.6. Advertisment 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Body | | | Type 9 [6] defines in detail this ICMP message header format. 3. IGMP for IPv6 The IPv6 Internet Group Management Protocol (IGMP) is used by IPv6 hosts to report their group memberships to any immediately- neighboring multicast routers and by multicast routers to query hosts for group membership information. IPv6 IGMP is an integral part of IPv6 and MUST be implemented by every IPv6 host. IGMP messages may also be sent between routers to exchange group membership, prune and join information; the formats of such messages are not specified here. Each IPv6 IGMP message is preceded by an IPv6 header and zero or more IPv6 option headers. The header immediately preceding the IPv6 header MUST have a Next Header Type of 2. Expires in six months [Page 12] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 IPv6 IGMP messages have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Unused | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | + Multicast | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 IGMP Fields: Version 1 Type There are two types of IGMP messages of concern to hosts: 1 - Host Membership Query 2 - Host Membership Report Reserved Zeroed when sent, ignored when received. Checksum If the destination of the ICMP message is an IPv4 mul- ticast group (the C-bit in the destination address is 1 [8]), the checksum is the 16-bit one's complement of the one's complement sum of the IPv6 Source Identify- ing Address, the IPv6 Destination Identifying Address, the IPv6 Next Header Type and the entire ICMP message starting with the ICMP message type. Otherwise, the checksum is the 16-bit one's complement of the one's complement sum of the IPv6 Source Identifying Address, the IPv6 Destination Identifying Address, the IPv6 Payload Length, the IPv6 Next Header Type, and the entire ICMP message starting with the ICMP message type. (The rationale for this checksum computation is described in [2]). For computing the checksum, the checksum field is zeroed. IPv6 Multicast Address In a Host Membership Query message, the IPv6 multicast address is zeroed when sent and ignored when received. In a Host Membership Report message, the IPv6 multi- cast address field holds the multicast address of the group being reported. Description Multicast routers send Host Membership Query messages to discover Expires in six months [Page 13] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 which host groups have members on attached networks. These queries are sent to the IPv6 All-Hosts multicast group with intra-link scope. Hosts respond to a query by generating Host Membership Reports, reporting each group they belong to on the network interface from which the query was received. Reports are generally sent to the IPv6 multicast group address of the group being reported, with intra-link scope; other members of the group receive this report and desist from sending a report themselves. Hosts receiving a group report should confirm that the IPv6 destination address and the multicast address in the IPv6 IGMP message are identical; the report MUST be silently discarded otherwise. Details of the protocol are described in [7]. 4. References [1] J. Postel, "Internet Control Message Protocol", RFC 792. [2] S. Deering, "Internet Protocol Version 6 Specification", Internet Draft, [3] S. Deering, (TBD) [4] J. Mogul and S. Deering, "Path MTU Discovery", RFC 1191. [5] S. Deering, "ICMP Router Discovery", RFC 1256. [6] W. A. Simpson "Neighbor Discovery", Internet Draft, [7] S. Deering, "Host Extensions for IP Multicasting", RFC 1112. [8] R.Gilligan, E. Nordmark, R. Hinden, "The IPv6 Interoperability and Transition Mechanism", Internet Draft, [9] R. Braden, "Requirements for Internet Hosts - Communication Layers", RFC 1122. 5. Acknowledgements The document is derived from the "ICMP and IGMP for SIPP" document published as a draft by Ramesh Govindan and Steve Deering in March 1994. Expires in six months [Page 14] INTERNET-DRAFT ICMP and IGMP for IPv6 September 30, 1994 6. Security Considerations Security considerations ane not discussed in this memo. Authors' Addresses: Alex Conta Stephen Deering Digital Equipment Corporation Xerox Palo Alto Research Center 110 Spitbrook Rd 3333 Coyote Hill Road Nashua, NH 03062 Palo Alto, CA 94304 +1-603-881-0744 +1-415-812-4839 email: conta@zk3.dec.com email: deering@parc.xerox.com -------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 19:15:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03621; Mon, 3 Oct 94 19:15:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03615; Mon, 3 Oct 94 19:14:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04270; Mon, 3 Oct 94 19:11:11 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA11172; Mon, 3 Oct 94 19:10:50 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA13201; Mon, 3 Oct 94 19:07:08 -0700 Received: by xirtlu.zk3.dec.com; id AA21878; Mon, 3 Oct 1994 22:07:04 -0400 Message-Id: <9410040207.AA21878@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: next hop resolution In-Reply-To: Your message of "Mon, 03 Oct 94 17:26:08 EDT." <9410032126.AA00785@brigit.zk3.dec.com> Date: Mon, 03 Oct 94 22:06:58 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> I thought that was an IPv6 expectation too (in fact, I thought >> that was more an IPv4 expectation than a BSD one). The IPv4 >> model, which I thought was being carried into IPv6, is that >> cables are labelled (this is as opposed to the area model), >> where a "cable" is whatever one can reach without passing through >> a router. Interfaces take addresses from the cables they are >> connected to. Am I suffering under a misunderstanding? Is this >> not the IPv6 model too? >That was my understanding too. Mine too!!! In addition did we not say a wire would not contain more than one subnet? And the concept of an IS-IS Area is not in the plan either. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 19:25:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03633; Mon, 3 Oct 94 19:25:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03627; Mon, 3 Oct 94 19:25:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04917; Mon, 3 Oct 94 19:21:55 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA13909; Mon, 3 Oct 94 19:21:29 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA13617; Mon, 3 Oct 94 19:16:16 -0700 Received: by xirtlu.zk3.dec.com; id AA21929; Mon, 3 Oct 1994 22:16:12 -0400 Message-Id: <9410040216.AA21929@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 94 23:38:46 GMT." <9410032338.aa05701@sundance.itd.nrl.navy.mil> Date: Mon, 03 Oct 94 22:16:06 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, >Jim, > I intended to make clear that I don't think that the IETF can/should >prevent vendors from shipping routed(8). I was trying to say that >IMHO _good_ vendors will ship something better than routed(8) [for >example gated(8)] as part of their "host as router" software set. If >I do turn a host into a router, I'd always like to use a really good >routing protocol (such as OSPF) rather than RIP. IMHO, good vendors >also won't ever automatically turn a host into a router with boot-time >shell scripts (as DEC, Sun, SGI, and HP currently appear to do :-). Instead of saying "appear" to do when talking about vendor products it might be good if you go down to a lab and install and configure hands on and mistakes like your last sentence would not happen. Hmmm Ran I am confused by the last statement. On our UNIX you have to run netsetup and some other scripts. In fact when you boot TCP/IP is essentially not configured (well with IPv6 we may be able to ship like this). When you run those scripts you have the option of turning on routed or gated depending on what your network administrator wants to do. Or you can do it at the command line interface later. In fact I have never worked on a UNIX Host that booted as a router unless some network admin person configured it that way and then I got the machine to do some testing (which has only happened once). /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 19:48:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03645; Mon, 3 Oct 94 19:48:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03639; Mon, 3 Oct 94 19:48:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06086; Mon, 3 Oct 94 19:44:43 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA19325; Mon, 3 Oct 94 19:44:20 PDT Received: from relay.imsi.com by wintermute.imsi.com id WAA04684 for ; Mon, 3 Oct 1994 22:44:19 -0400 Received: from snark.imsi.com by relay.imsi.com id WAA14671 for ; Mon, 3 Oct 1994 22:44:18 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02914; Mon, 3 Oct 94 22:44:18 EDT Message-Id: <9410040244.AA02914@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 22:16:06 EDT." <9410040216.AA21929@xirtlu.zk3.dec.com> X-Reposting-Policy: redistribute only with permission Date: Mon, 03 Oct 1994 22:44:17 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bound@zk3.dec.com says: > >routing protocol (such as OSPF) rather than RIP. IMHO, good vendors > >also won't ever automatically turn a host into a router with boot-time > >shell scripts (as DEC, Sun, SGI, and HP currently appear to do :-). [...] > [...] I have never worked on a UNIX Host that booted as a router > unless some network admin person configured it that way and then I got > the machine to do some testing (which has only happened once). Suns ship with in.routed set in rc.local to run automatically if it's present and no default route has been hardwired in by the admin -- and they don't run it with the -q option which would suppress outgoing routing information. Sun kernels are shipped by default with ip forwarding on. (In fact, turning it off requires work.) That means that if you boot a Sun with multiple configured interfaces and do nothing else, it will advertise itself via RIP as a router. I cannot speak to any other vendors as it has been a while since I've used their stuff. Perry Who's client machines have to all run routed or gated anyway even though they aren't routers because there are multiple redundant routers on his networks that he needs to automatically get used in case of network failure. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 21:46:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03673; Mon, 3 Oct 94 21:46:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03667; Mon, 3 Oct 94 21:46:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10794; Mon, 3 Oct 94 21:43:10 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA11078; Mon, 3 Oct 94 21:42:48 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA06649; Mon, 3 Oct 94 21:39:28 -0700 Received: by xirtlu.zk3.dec.com; id AA24084; Tue, 4 Oct 1994 00:39:26 -0400 Message-Id: <9410040439.AA24084@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 94 13:57:22 EDT." <15597.199410031757@atlas.xylogics.com> Date: Tue, 04 Oct 94 00:39:20 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> But, routed et al are defacto >> standards not "dejure" >I beg to differ. Routed runs RIP as defined in RFC 1058. It is a >full Internet Standard (STD 34). Gary I stand corrected good point. I was just thinking of the user daemon. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 22:41:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03726; Mon, 3 Oct 94 22:41:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03720; Mon, 3 Oct 94 22:40:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12895; Mon, 3 Oct 94 22:37:25 PDT Received: from bridge2.NSD.3Com.COM by Sun.COM (sun-barr.Sun.COM) id AA19427; Mon, 3 Oct 94 22:37:00 PDT Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA19469 (5.65c/IDA-1.4.4nsd for ); Mon, 3 Oct 1994 22:34:54 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA19500 (5.65c/IDA-1.4.4-910725 for ); Mon, 3 Oct 1994 22:31:00 -0700 Message-Id: <199410040531.AA19500@remmel.NSD.3Com.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 22:16:06 EDT." <9410040216.AA21929@xirtlu.zk3.dec.com> Date: Mon, 03 Oct 1994 22:27:28 -0700 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Six or seven years ago, Sun 3/280 file-servers booted with forwarding enabled, if two or more ethernet interfaces were present. Not running RIP, but simply with the feature that packets not addressed to the host's ip address would be forwarded. This made for a few interesting debug sessions, back when routers were still "gateways". Tracy ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 3 22:43:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03738; Mon, 3 Oct 94 22:43:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03732; Mon, 3 Oct 94 22:42:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12944; Mon, 3 Oct 94 22:39:31 PDT Received: from bridge2.NSD.3Com.COM by Sun.COM (sun-barr.Sun.COM) id AA19554; Mon, 3 Oct 94 22:39:09 PDT Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA19553 (5.65c/IDA-1.4.4nsd for ); Mon, 3 Oct 1994 22:36:40 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA19501 (5.65c/IDA-1.4.4-910725 for ); Mon, 3 Oct 1994 22:32:51 -0700 Message-Id: <199410040532.AA19501@remmel.NSD.3Com.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 22:16:06 EDT." <9410040216.AA21929@xirtlu.zk3.dec.com> Date: Mon, 03 Oct 1994 22:29:20 -0700 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM P.S. We were told it was a feature of 4.2 bsd(default to forwarding if two ethernet interfaces were present) Tracy ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 00:40:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03864; Tue, 4 Oct 94 00:40:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03858; Tue, 4 Oct 94 00:40:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17931; Tue, 4 Oct 94 00:36:50 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA00176; Tue, 4 Oct 94 00:36:28 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26273; Tue, 4 Oct 1994 08:36:26 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29398; Tue, 4 Oct 1994 08:36:24 +0100 Message-Id: <9410040736.AA29398@dxcoms.cern.ch> Subject: Re: (IPng) NSAPs To: ipng@sunroof.Eng.Sun.COM Date: Tue, 4 Oct 1994 08:36:23 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410031336.AB00141@texas.nynexst.com> from "Ajay Joseph" at Oct 3, 94 09:36:42 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ajay, Can you send the ATMF contribution please? The proposed embedding for IPv6 in NSAPA is in the annex of draft-carpenter-ip6-nsap-map-00.txt and I hope you are consistent. Brian > > ------- Start of forwarded message ------- > From: ajay@nynexst.com (Ajay Joseph) > Sender: owner-ipng@sunroof.Eng.Sun.COM > To: ipng@sunroof.Eng.Sun.COM > Subject: Re: (IPng) NSAPs > Date: Mon, 3 Oct 94 09:36:42 EDT > > .... > > Brian, > >>(It remains a mystery to me why the ATM Forum chose to copy a Level 3 address > >>format for Level 2 addressing, but that is another discussion.) > > I guess by Level 3 you mean IPv6 what is Level 2 addresing in this context? > The reason I am asking is because I had made a contribution to the ATMF > on embedding IPv6 into the NSAP for ATM routing of IP. > - --Ajay-- > - ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------- End of forwarded message ------- > r ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 00:56:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03900; Tue, 4 Oct 94 00:56:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03894; Tue, 4 Oct 94 00:56:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18725; Tue, 4 Oct 94 00:52:39 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA01140; Tue, 4 Oct 94 00:52:18 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA08348; Tue, 4 Oct 1994 00:52:17 -0700 Date: Tue, 4 Oct 1994 00:52:17 -0700 From: Tony Li Message-Id: <199410040752.AAA08348@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Bob Hinden's message of Mon, 3 Oct 1994 15:29:30 -0700 <199410032229.PAA08319@jurassic.Eng.Sun.COM> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > But I believe that there is a good alternative, as other people have > hinted at. Imagine a routing information query protocol. The host, > on having traffic to send fires a query to its selected router(s). > [Note that there is no RTT delay as the first packet can be sent > irrespective of optimality.] The router(s) reply(s) with a selection > of information: metric, administrative distance, next hop, lifetime, > and prefix. How would you think this would work for multihomed hosts? Run router discovery on each interface. Query one router on each interface. The problem of multihomed hosts interacting with multiple IGPs with multiple administrative domains (and thereby without clear definiton of administrative distance) is an open problem. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 01:19:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03964; Tue, 4 Oct 94 01:19:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03958; Tue, 4 Oct 94 01:19:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19760; Tue, 4 Oct 94 01:15:44 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA03035; Tue, 4 Oct 94 01:15:23 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA08814; Tue, 4 Oct 1994 01:15:22 -0700 Date: Tue, 4 Oct 1994 01:15:22 -0700 From: Tony Li Message-Id: <199410040815.BAA08814@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Mon, 03 Oct 1994 17:27:20 -0400 <9410032127.AA02436@snark.imsi.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, This is the problem as I see it. What happens during periods of problems? You still have problems. Just like today's. Only faster. ;-) Right now, my major client has a fully redundant network in which all hosts run routed. The cisco routers export, but do not trust, RIP; they route using IGRP. If a router goes south, within moments all the hosts on any given cable have been told to use the other one attached to the same cable. This is very solid and reliable. Now, in your proposed scheme, I'll have cached routing information for both routers, and UNTIL I ASK FOR THE INFORMATION AGAIN, my packets for huge chunks of my network will go into a black hole. When you really rely on your network, you can't have a situation like that happen. Well, I don't know why not. Today, with the convergence time of RIP and IGRP you will have huge chunks of your network go into a black hole called holddown. The question that you're trying to raise is what is the convergence time of this scheme. You're assuming things that I haven't said about the timers which were not intended. Like things are slow. Or that that was the entire protocol. No, sorry, that wasn't the entire spec. I think its a good idea that hosts be informed of routing changes by a mechanism other than the ordinary routing protocols, both to reduce overhead and to prevent route contamination by rogue hosts. However, the mechanism must somehow inform hosts of routing problems ASAP in order to prevent the sort of of problem I just described. Any mechanism that results in less reliability than I have now isn't a good idea. There are several things that can happen here. First, you need some low overhead mechanism for insuring liveness. In this case, router discovery is already available. Loss of router liveliness for the router that was queried should immediately render the information suspect. Similarly, in the case where the next hop is a router, loss of liveliness there should also cast doubt on the information. Next, some mechanism is needed to invalidate the caches on hosts in the face of routing table changes. The router can reasonably cache which prefixes have been advertised and send invalidation requests to hosts on noticing changes. It's an open question if it's cheaper to do this on per-host basis or simply broadcast invalidation notices. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 01:28:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04026; Tue, 4 Oct 94 01:28:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04020; Tue, 4 Oct 94 01:28:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20225; Tue, 4 Oct 94 01:25:10 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA04017; Tue, 4 Oct 94 01:24:48 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA08934; Tue, 4 Oct 1994 01:24:48 -0700 Date: Tue, 4 Oct 1994 01:24:48 -0700 From: Tony Li Message-Id: <199410040824.BAA08934@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Mon, 03 Oct 1994 10:12:06 -0400 <9410031412.AA01802@snark.imsi.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, In an environment where one depends on every local subnet to have multiple exit points to assure no single point of failure, and in which most critical hosts have more than one interface for the same reason (such networks resembling virtually all the networks clients of mine run) having a routing program on most machines seems to be a Good Thing. I've had more than one customer try to install OSPF on 2000 hosts in their network. Would you like to try to convince them that this is a Good Thing? ;-) Perhaps what we need is a routing information export protocol designed just to convey such information on routing maps determined by other protocols that hosts can listen to without contaminating.) Almost exactly. However, hosts don't want full maps. Nor is that a scalable solution. We need to avoid periodic update, avoid the usual pitfalls of existing routing protocols (holddown, reliable LSA flooding, expensive computations) and provide good convergence time. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 01:31:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04048; Tue, 4 Oct 94 01:31:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04032; Tue, 4 Oct 94 01:30:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20313; Tue, 4 Oct 94 01:27:13 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04250; Tue, 4 Oct 94 01:26:51 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id EAA03898 for ; Tue, 4 Oct 1994 04:26:49 -0400 Date: Tue, 4 Oct 94 07:46:44 GMT From: "William Allen Simpson" Message-Id: <3288.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) preliminary IPv6 ICMP specs for review Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, _every_ spec should be an internet-draft. They SHOULD NOT be sent to the list. Many people have mailers that throw away more than 32 or 64K. And I really don't appreciate waiting an extra 10 minutes for my mail to come in when somebody has tossed a big email message in the pool. Just use internet-drafts, as we intended. It's a draft.... Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 01:31:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04049; Tue, 4 Oct 94 01:31:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04037; Tue, 4 Oct 94 01:30:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20322; Tue, 4 Oct 94 01:27:15 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04260; Tue, 4 Oct 94 01:26:53 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id EAA03901 for ; Tue, 4 Oct 1994 04:26:51 -0400 Date: Tue, 4 Oct 94 07:54:47 GMT From: "William Allen Simpson" Message-Id: <3289.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: next hop resolution Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Mine too!!! In addition did we not say a wire would not contain more > than one subnet? > Well, I'm sure I said it earlier. We aren't going to come to agreement in this low bandwidth mailing list environment. For what it's worth, we can alreay have dozens of subnets on one link. The problem is that in IPv4 we have to go through a router to communicate between them. That's fixed in IPv6 Discovery. And we have to stop thinking about "wires". There will certainly be hundreds of subnets in a radio link, particularly in globe spanning RF. > And the concept of an IS-IS Area is not in the plan either. > Yes, that's what we agreed. But certain folks are still pushing it. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04468; Tue, 4 Oct 94 09:41:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04314; Tue, 4 Oct 94 05:40:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29002; Tue, 4 Oct 94 05:37:13 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA01552; Tue, 4 Oct 94 05:36:46 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA17418; Tue, 4 Oct 94 08:32:39 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410041232.AA17418@pluto.dss.com> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Tue, 4 Oct 1994 08:32:38 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <199410040824.BAA08934@lager.cisco.com> from "Tony Li" at Oct 4, 94 01:24:48 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2953 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Perry, > In an environment where one depends on every local subnet to have > multiple exit points to assure no single point of failure, and in > which most critical hosts have more than one interface for the same > reason (such networks resembling virtually all the networks clients of > mine run) having a routing program on most machines seems to be a Good > Thing. > I've had more than one customer try to install OSPF on 2000 hosts in > their network. Would you like to try to convince them that this is a > Good Thing? ;-) Of course not. OSPF is a bad thing which should die a quick death. I can only assume that the principals involved in the specification of OSPF were naifs who: 1) had little experience with the problems of synchronization and distribution of large databases (especially in the embedded systems environment where memory constraints are often a real problem), 2) had little experience with protocol specification (Moy's document while a reasonable implementation guide is miserable as a protocol specification and betrays a complete lack of understanding with respect to what a protocol specification should be -- the IETF bears most of the blame for this situation) and 3) simply had little understanding of how people really build networks (I don't know how many times I have heard horror stories of the set-up of large OSPF networks where the users suddenly found that their networks suddenly stopped working because hosts had been dependent on the distribution of routing information via a routing protocol which had been turned off (and into which the purchased OSPF either did not propagate routes or did not propagate routers correctly). > Perhaps what we need is a routing information export > protocol designed just to convey such information on routing maps > determined by other protocols that hosts can listen to without > contaminating.) > Almost exactly. However, hosts don't want full maps. Nor is that a > scalable solution. We need to avoid periodic update, avoid the usual > pitfalls of existing routing protocols (holddown, reliable LSA > flooding, expensive computations) and provide good convergence time. If I configure my OSPF routers to propagate routing information into RIP but only accept information from OSPF and allow my hosts only to receive my routes from RIP, of course OSPF still suffers from all the usual problems and stupidities of OSPF, but on the RIP side (now essentially a router to host route distribution protocol), what problems do you see? > Tony Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04462; Tue, 4 Oct 94 09:41:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04344; Tue, 4 Oct 94 07:33:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03819; Tue, 4 Oct 94 07:29:55 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA16195; Tue, 4 Oct 94 07:29:21 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA18248; Tue, 4 Oct 94 10:25:11 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410041425.AA18248@pluto.dss.com> Subject: Re: (IPng) Address-per-interface To: ipng@sunroof.Eng.Sun.COM Date: Tue, 4 Oct 1994 10:25:10 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9410032059.aa05416@sundance.itd.nrl.navy.mil> from "Dan McDonald" at Oct 3, 94 03:59:11 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2333 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I've been watching the kre - Simpson exchange regarding > address-per-interface. My take on this has been: > * An interface in IPv6 has AT LEAST one unique address per > interface. This means that multiple subnets per interface can > exist. > * The stated reason for this is because of multicast group > difficulties. I'm not the expert on multicast, but if Steve > Deering comes out of hiding, I'm sure he'll be happy to explain. These comments may make sense as long as interface referes to logical network layer interfaces. Constellation Series Brouters/LAN switches and (I believe) IBM 6611s and perhaps Ciscos configured for bridge groups can map logical network layer interfaces to logical subbridges which may contain more than one physical interface or MAC port. > * Another good reason for sticking with what I believe to be the > case (>=1 address per interface) is that according to Ran, no > trusted system can be built B1 or higher with one address over > multiple interfaces. (Think of the "Secret" interface, the > "unclassified" interface, and the "Top Secret" interface, all > on the same machine.) Again I assume interface here means logical network interface. By the way in the Constellation series architecture (or general virtual device architecture), it is possible to map multiple network layer interfaces to multiple logical MAC ports on a logical subbridge. It has been a long time since I thought about the security issues, but multilevel secure machines have been built in the past. If a machine supports multiple network layers and multilevel security is implemented on the network via MAC layer security envelopes, I am not sure it would be impossible to build a machine trusted at B1 or higher with one network address effectively assigned to multiple phsyical interfaces. > I agree with Dr. Elz on this one. I'd like to see what the "official" line > is on this. > Dan Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04473; Tue, 4 Oct 94 09:41:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04324; Tue, 4 Oct 94 06:06:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29905; Tue, 4 Oct 94 06:03:01 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA03922; Tue, 4 Oct 94 06:02:37 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA05425 for ; Tue, 4 Oct 1994 09:02:35 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA18178 for ; Tue, 4 Oct 1994 09:02:35 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA03349; Tue, 4 Oct 94 09:02:34 EDT Message-Id: <9410041302.AA03349@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Mon, 03 Oct 1994 23:38:46 GMT." <9410032338.aa05701@sundance.itd.nrl.navy.mil> X-Reposting-Policy: redistribute only with permission Date: Tue, 04 Oct 1994 09:02:33 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran Atkinson says: > Perry, > I suspect that IPv4 Router Discovery would turn out to be a > perfectly fine way for your hosts to get the data that they really > need. Hence, I suspect that the listen-only use of routed(8) can be > replaced in most (all ?) cases by good router configuration and host > use of rdisc(8). This approach clearly doesn't work if one has older > host software that doesn't support router discovery, but most modern > OS releases do support router discovery. This is going to sound rather whiny. Please don't take it as such. I am NOT an IPv6 guru. I'm just a user. I have a requirement. I'm just telling you about it. Again, what would actively and reliably inform me of the disappearance of a router or the appearance of a router? From what I understand, I'm protected from black holes solely because of timeouts on discovered/advertised routing information. Well, either you are going to set the timeouts on all cached router advertisements to thirty or fifteen seconds or even less and have lots of traffic associated with router advertisements (which is much the way things are done now), or I'm going to be spewing packets at black holes for substantial periods. The current draft I saw of Bill Simpson's had router advertisement packets with lifetimes in them of up to 18 hours. My clients are typically shipping around trading information. Need I mention that during the middle of the day in the midst of a complex program trade execution, a couple of minutes of network outage is a disaster? It is possible that everyone is contemplating one of these things going by like a heartbeat every few moments with twenty second lifetime -- if this is the case, please let me know now. However, that 18 hour figure made me gasp -- I can hardly imagine a situation in which I could feel like I could trust routing information that long, and with time I imagine my constraints on reliability will reduce, not increase, my windows in which to re-assemble my network during failures. Hosts keep their IP addresses for months or years, so timeouts and caching make sense in DNS, but routers come and go all day long. My current practice, as I've said, is read-only slurping of passing routing information. This has the advantage that RIP packets are guaranteed to be going by every thirty seconds and that I'm likely to notice the disappearance of a router very fast. Still not fast enough, by the way -- but I was hoping for V6 to provide improvements, not steps backward. We are not talking about large networks in which caching and timeouts are completely reasonable ways of handling slow moving data, like the DNS case. We are talking about subnetworks of at most a few hundred machines and typically under fifty machines, where we are talking about a small number of routers and a small amount of routing information who's timelyness is critical. I'd very much like it if, as soon as a router knew that its partner on a network went down, it was kind enough to inform me of the fact so that I don't keep sending packets into space when there is a perfectly good other router on the same subnet. I suppose this implies some degree of mutual monitoring by the routers -- but much of this is implicit in our routing protocols anyway. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04469; Tue, 4 Oct 94 09:41:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04331; Tue, 4 Oct 94 07:04:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB02576; Tue, 4 Oct 94 07:01:06 PDT Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA11960; Tue, 4 Oct 94 07:00:44 PDT Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01116 Wed, 5 Oct 1994 00:00:05 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: next hop resolution In-Reply-To: Your message of "Tue, 04 Oct 1994 07:54:47 GMT." <3289.bill.simpson@um.cc.umich.edu> Date: Tue, 04 Oct 1994 23:58:58 +1000 Message-Id: <7753.781279138@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 4 Oct 94 07:54:47 GMT From: "William Allen Simpson" Message-ID: <3289.bill.simpson@um.cc.umich.edu> Well, I'm sure I said it earlier. We aren't going to come to agreement in this low bandwidth mailing list environment. Perhaps not to agreement, but we might get some of the isues more out in the open so that more people understand exactly what the issues that need deciding are. Its true that electronic discussions don't often reach consensus - its also true that face to face meeings more often do - but that's partly because in those short, hectic, meetings there is little time for adequate reflection and understanding - the views of someone who appears to understand the issue can be accepted merely because of lack of time to adequately reflect on the issues. Low bandwidth can have advantages. For what it's worth, we can alreay have dozens of subnets on one link. The problem is that in IPv4 we have to go through a router to communicate between them. That's fixed in IPv6 Discovery. Bill, this is not the issue, its not even close - the question that arose from your example of how you'd solve the problem I raised is whether you can have one subnet on dozens of (or even two) links. That's the exact converse of what you say, the answer is unrelated. And we have to stop thinking about "wires". There will certainly be hundreds of subnets in a radio link, particularly in globe spanning RF. The only way to stop thinking about "wires" is if ... > And the concept of an IS-IS Area is not in the plan either. Yes, that's what we agreed. But certain folks are still pushing it. areas come back, which I certainly hope they don't. Otherwise we number wires (real ones, or virtual ones) with one or more numbers each. The relevant point is that once a number is allocated to a wire, it can't be allocated to a different one. Now go back and see if there's some way a dumb multi-homed host can figure which of its interfaces it should send through based on information a router connected to both wires sends. I don't think its possible, the host can't be dumb. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04466; Tue, 4 Oct 94 09:41:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04380; Tue, 4 Oct 94 08:56:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09788; Tue, 4 Oct 94 08:53:11 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA02982; Tue, 4 Oct 94 08:52:39 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA17551; Tue, 4 Oct 1994 11:52:33 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA11612; Tue, 4 Oct 1994 11:52:30 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA01281; Tue, 4 Oct 1994 11:29:10 -0400 Message-Id: <9410041529.AA01281@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: danmcd@sundance.itd.nrl.navy.mil, conta@zk3.dec.com Subject: Re: (IPng) Address-per-interface In-Reply-To: Your message of "Mon, 03 Oct 94 15:59:11 CDT." <9410032059.aa05416@sundance.itd.nrl.navy.mil> Date: Tue, 04 Oct 94 11:29:09 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perhaps in a closely similar cathegory would be TOS and 'flow ID' that may attach to IPv6 addresses. Alex --------------------------- I've been watching the kre - Simpson exchange regarding address-per-interface. My take on this has been: * An interface in IPv6 has AT LEAST one unique address per interface. This means that multiple subnets per interface can exist. * The stated reason for this is because of multicast group difficulties. I'm not the expert on multicast, but if Steve Deering comes out of hiding, I'm sure he'll be happy to explain. * Another good reason for sticking with what I believe to be the case (>=1 address per interface) is that according to Ran, no trusted system can be built B1 or higher with one address over multiple interfaces. (Think of the "Secret" interface, the "unclassified" interface, and the "Top Secret" interface, all on the same machine.) I agree with Dr. Elz on this one. I'd like to see what the "official" line is on this. Dan ----------------------------------------------------------------------------- ***- IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04472; Tue, 4 Oct 94 09:41:45 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04374; Tue, 4 Oct 94 08:56:18 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA10862; Tue, 4 Oct 1994 08:52:44 -0700 Date: Tue, 4 Oct 1994 08:52:44 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410041552.IAA10862@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199410040752.AAA08348@lager.cisco.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony, > How would you think this would work for multihomed hosts? > > Run router discovery on each interface. Query one router on each > interface. The problem of multihomed hosts interacting with multiple > IGPs with multiple administrative domains (and thereby without > clear definiton of administrative distance) is an open problem. Thanks. I was thinking about the case where a host had multiple interfaces in the same administrative domain. The case you mention would be a problem. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04465; Tue, 4 Oct 94 09:41:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04245; Tue, 4 Oct 94 03:20:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24235; Tue, 4 Oct 94 03:16:57 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA16939; Tue, 4 Oct 94 03:16:32 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA13386; Tue, 4 Oct 1994 11:18:45 +0100 Message-Id: <199410041018.AA13386@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Tue, 04 Oct 1994 01:15:22 MST." <199410040815.BAA08814@lager.cisco.com> Date: Tue, 04 Oct 1994 11:18:42 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, This discussion is interesting, but inconclusive. There are a very few points of agreements - for example I believe we all agree that IPv6 follows the IPv4 "subnet" model, and that interfaces can be individually addressed (I know Bill does not, but we did debate this point in the SIP list long ago, and there was a clear consensus). This does not mean that we cannot evolve - there is room for debate, or more precisely for experimentation, like allowing multiple subnets on the same wire (that is IMHO a must), having a single subnet cross multiple wires (that is mostly a maybe, we have to see a clear plan there), letting a visiting "mobile host" use its own permanent address (although getting a new address in the subnet realm is workable too - this new address being used as a "care of" address in the mobile ip model). The unconclusiveness of the "multihomed" host discussion is quite predictable - there is no good model. In fact, there are three models, each of which has some advantages and some weak points: 1) Do nothing special. The multihomed host essentially picks the outgoing interface at random, tries many of them for several packets, get some "statistics", eventually determine all by himself what the best route is for each addresses within its "working set". This is in accordance with the end to end principle; it is robust, but maybe slow. 2) Ask the routers to broadcast their routing tables at regular intervals (the "RIP on the wire" solution). This is either slow, if the broadcast interval is large, or very heavy, if the interval is short: the routing tables may be quite large. It is also overshooting the target by a wide margin: hosts are not interested in complete routing tables, but in a subset - their working set. Then we have the metric problem which Tony pointed out: the comparison only works if all the routers of all the subnets to which the host is linked use consistent metrics. This is by definition not the case if they dont belong to the same administration. 3) Ask the routers to respond to "distance queries", e.g. "what is the distance to dest X, Y, Z". Multi-homed hosts would ask this to one router on each subnet; the partners of multi-homed hosts or the client of multi-hosted services would ask this to their local routers. This is as fast as can be, but implies a large overhead - just suppose that all host start playing this game, pretty soon the routers will be spending all their cycles responding to the queries. Also, currents protocols such as BGP do not allow the routers to compute significative distances when the destination is in a remote AS. My personal preference is for (1). I don't believe that (2) scales well, specially if the routing tables grow very large; I do believe that (3) generates far too much overhead. In fact, it would be a good idea to combine (1) with some form of black-hole detection, so that multi-homed hosts do not use misfunctioning routers! Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04471; Tue, 4 Oct 94 09:41:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04354; Tue, 4 Oct 94 07:56:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05145; Tue, 4 Oct 94 07:53:03 PDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA20909; Tue, 4 Oct 94 07:52:36 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04500; 4 Oct 94 10:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-rekhter-ipng-arch-IPv6-addr-01.txt Date: Tue, 04 Oct 94 10:49:50 -0400 Message-Id: <9410041049.aa04500@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Architecture for IPv6 Unicast Address Allocation Author(s) : Y. Rekhter, T. Li Filename : draft-rekhter-ipng-arch-IPv6-addr-01.txt Pages : 25 Date : 10/03/1994 This document provides an architecture for allocating IPv6 unicast addresses in the Internet. This document does not go into the details of an addressing plan. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-rekhter-ipng-arch-IPv6-addr-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19941003095741.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-rekhter-ipng-arch-IPv6-addr-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941003095741.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04464; Tue, 4 Oct 94 09:41:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04338; Tue, 4 Oct 94 07:21:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03257; Tue, 4 Oct 94 07:18:02 PDT Received: from atlas.xylogics.com by Sun.COM (sun-barr.Sun.COM) id AA14485; Tue, 4 Oct 94 07:17:35 PDT Received: by atlas.xylogics.com id AA30457 (5.65c/UK-2.1-940401); Tue, 4 Oct 1994 10:23:37 -0400 From: Gary Scott Malkin Date: Tue, 4 Oct 1994 10:23:37 -0400 Message-Id: <30457.199410041423@atlas.xylogics.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Tue, 04 Oct 94 00:39:20 -0400 <9410040439.AA24084@xirtlu.zk3.dec.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >> But, routed et al are defacto > >> standards not "dejure" > > >I beg to differ. Routed runs RIP as defined in RFC 1058. It is a > >full Internet Standard (STD 34). > > Gary I stand corrected good point. I was just thinking of the user > daemon. Oh, I see. Yes, it is true that many of the daemons are not RFC 1058 compliant. There are several router vendors' implementations which are not compliant too. I really wish they'd fix that; they've got no excuse. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two! ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:43:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04563; Tue, 4 Oct 94 09:43:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04467; Tue, 4 Oct 94 09:41:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13731; Tue, 4 Oct 94 09:37:03 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA12192; Tue, 4 Oct 94 09:36:35 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27899; Wed, 5 Oct 1994 01:34:23 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: next hop resolution In-Reply-To: Your message of "Mon, 03 Oct 1994 17:26:08 -0400." <9410032126.AA00785@brigit.zk3.dec.com> Date: Wed, 05 Oct 1994 01:34:19 +1000 Message-Id: <7777.781284859@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 03 Oct 94 17:26:08 -0400 From: conta@zk3.dec.com Message-ID: <9410032126.AA00785@brigit.zk3.dec.com> And use ICMP as a pseudo-transport? I would not give up UDP. Nor would I. I've been somewhat bemused by all the recent desire to make almost everything new be run out of icmp, which makes close to no sense to me at all. ICMP should go back to being an error reporting protocol - a way for intermediate devices to send errors without necessarily knowing any of the details of the protocol being carried. Even the address mask, time of day, (etc etc) requests - conceivably even echo (ping) though that is probably useful enough to keep for testing the IP path without requiring higher level protocols to be running - should all be moved out of ICMP. Its not as if there's any real practical difference between the two protocols, except that there's only one "type" (== "port") field rather than one for source & one for destination, which is a limitation of icmp for general purposes, not a benefit. Oh, that and the fact that BSD chose not to provide any reasonable programming interface to ICMP, keeping the whole thing in the kernel - that could be fixed though, and will probably need to be if all the rest of the proposals for trash to be lumped into ICMP actually goes ahead. Implemeting UDP is no harder than implementing ICMP, in fact, they're so close to identical its almost funny. Its not even as if anyone can avoid implementing UDP in anything serious - SNMP requires it, so does the DNS, so its going to be there anyway. What is the real reason that UDP is being downgraded as a protocol to use in favour of ICMP ? Is it that UDP checksums are (in IPv4) optional, so ICMP is somehow "trusted" more for reliability? Or that people tend to filter on UDP ports more than they do on ICMP types? I'd really like one of the "put the world in ICMP" devotees to tell me why they think ICMP is preferable (for anything other than error messages and echo) to UDP. Please - this is a serious request, not rhetorical. Oh yes - if UDP is not a suitable protocol, then ICMP probably isn't either, and what's likely to be needed is likely to be a new protocol above IP - that I could understand. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 09:44:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04664; Tue, 4 Oct 94 09:44:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04652; Tue, 4 Oct 94 09:44:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14282; Tue, 4 Oct 94 09:40:56 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA12593; Tue, 4 Oct 94 09:39:16 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29907; Wed, 5 Oct 1994 02:37:09 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) preliminary IPv6 ICMP specs for review In-Reply-To: Your message of "Mon, 03 Oct 1994 18:56:46 -0400." <9410032256.AA00905@brigit.zk3.dec.com> Date: Wed, 05 Oct 1994 02:37:03 +1000 Message-Id: <7785.781288623@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 03 Oct 94 18:56:46 -0400 From: conta@zk3.dec.com Message-ID: <9410032256.AA00905@brigit.zk3.dec.com> A few comments ... ICMP messages are grouped into two classes. ICMP error messages: ICMP query messages: I just had my rave on the latter in another message, so I won't repeat that again... (briefly, they don't belong in ICMP at all, except possibly ECHO). One matter of editorial style - I'd much prefer the ICMP docs arranges so one doc gives the general format of ICMP messages, checksum procedures, ..., then the individual ICMP messages be described in whatever document naturally relates to them (things like "destination unreachable" would appear where routing is described). They appear in those places ayway, keeping them only there avoids inconsistencies. Finally, one updatable doc giving the latest list of ICMP types and codes and pointers to where they are defined (which could be a part of assigned numbers, were that ever to appear again) If the error conditionwas created by: b. an IPv6 extension header, [...] NOTE: The length of the removed IPv6 extension headers can be specified in the Something has been lost there. An IPv6 ICMP error message MUST NOT be sent as a result of receiving: [...] a packet sent as a link-layer broadcast, or surely "link level multicast" a non-initial fragment, or Does this restriction need to apply in IPv6, where only originating hosts fragment? eg: should a host split a large packet into two fragments, and happen to make the second slightly larger than the first (the initial fragment) would it not be useful to send back the "too big for MTU" ICMP message? Finally, to each sender of an erroneous data packet, an IPv6 node SHOULD not send more than N ICMP error messages per second. The value of N should be fixed. The value of for N is recom- mended. I believe this is overspecified - all that should be sais is that senders of ICMP error messages should take steps to avoid overwhelming the net with those things - leave it to the implemenations to choose whether they can afford to record individual senders, or not, and what the rate should be. 2.1. Destination Unreachable Message Code 0 - router address unreachable 6 - destination network unkown 7 - destination host unknown What is the difference between those two, and how is it determined? I'd have thought that in v6 the distinction bewteen net & host is even more meaningless than it has become in v4. 9 - communication with destination network administratively prohibited 10 - communication with destination host administratively prohibited Same here. A Destination Unreachable MUST be sent by a router in response to a packet which it cannot forward because the packet is larger than the MTU of the outgoing link (code 4). This conflicts with the requirement that routers should limit the rate at which they send ICMP error messages. Normal precedence rules would probably put the "must" as being more important than "should not", and this require that every packet that exceeds the mtu generate an ICMP - my assumption is that this isn't what's wanted, or hosts ignoring the ICMP's will generate a packet for packet flood of the things in the other direction. The minimum legal value of the next-hop MTU field in a "packet too big" message (code 4) received by an IPv6 host is 68 octets. While IPv6 requires all links in the Internet to have an MTU of 576 octets or greater, the smaller minimum legal value is required to allow Path MTU discovery to work correctly when IPv6 packets are undergo translation to IPv4 packets (see Section 5 in [8]). I'm not sure I understand this rationale? Or perhaps just not the way its presented - in any case this is probably an area where the V6 -> v4 mappings may need some work. First, I'm not sure it makes sense to even say what the minimum value of a field as its received by the host is - what's the host supposed to do with a smaller value? Normally you'd specify the minimum legal value that's allowed to be sent - that, from an IPv6 router is clearly 576. The 68 could only come from translating an IPv4 ICMP into IPv6, and if that's to be done, something is going to have to be said about what an IPv6 host is to do when it receives something that small - its supposed to be guaranteed an MTU of 576 over the whole path. By the time a packet is constructed with IPv6 header, and fragmentation header, its hard to see that a 68 byte MTU is even conceivably useful. 2.2. Time Exceeded Message IPv6 ICMP Fields: 1 - fragment reassembly time exceeded If the fragment with offset zero was received, the destination host SHOULD also send an IPv6 ICMP Time Exceeded message with code 1. This is another case where it might be useful to be able to send the ICMP in response to any fragment, not only the first. While the transport header probably won't be there, the knowledge that some fragments are arriving might be useful - and knowing only when the first arrives seems a bit sketchy to me. 2.3. Parameter Problem Message This is another where a non-initial fragment (arriving at the destination host) could usefully elicit the ICMP - if the 2nd fragment is being sent with an incomprehensible fragment header, how else will the source host (or its managers) ever determine that otherwise? Code 0 means Pointer field indicates incorrect parameter. You might want to say what value should be used when the pointer means nothing (no valid pointer value), and perhaps what other values might mean, or how they should be interpreted. 2.4 Echo and Echo Reply [...] Code 0 Identifier If code = 0, some identifier to match echo messages with echo replies. May be zero. Sequence Number If code = 0, a sequence number to aid in matching echo messages with echo replies. May be zero. Since code is defined to be 0, I don't think the "If code = 0" is required. Nor does the "May be zero" add anything useful to to the description. Description The data received in the echo message must be returned unmodified in the echo reply message. This needs to explicitly include the identifier and sequence number. 2.5. Solicitation [6] defines in detail this ICMP message header format. Which is good, assuming the message deserves being an ICMP at all (oh no, not that again) - but given that, I'd omit this section altogether, it adds no useful knowledge. Same for "Advertisement". 3. IGMP for IPv6 I'd much prefer this to be in a separate doc - after having said that, since I'm not competent to review it further, I'll shut up. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 11:07:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04803; Tue, 4 Oct 94 11:07:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04797; Tue, 4 Oct 94 11:07:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23060; Tue, 4 Oct 94 11:04:14 PDT Received: from ski.utah.edu by Sun.COM (sun-barr.Sun.COM) id AA25089; Tue, 4 Oct 94 11:01:07 PDT Received: (from haas@localhost) by ski.utah.edu (8.6.9/8.6.9) id LAA06191; Tue, 4 Oct 1994 11:51:11 -0600 From: Tired of the Information Superhype Message-Id: <199410041751.LAA06191@ski.utah.edu> Date: Tue, 4 Oct 94 11:51:11 MDT Subject: Re: (IPng) Re: next hop resolution To: ipng@sunroof.Eng.Sun.COM In-Reply-To: ipng@sunroof.Eng.Sun.COM, Tue, 4 Oct 94 07:54:47 GMT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >For what it's worth, we can alreay have dozens of subnets on one link. Yup. Well, we have half a dozen here. >The problem is that in IPv4 we have to go through a router to >communicate between them. Nope. Just set the subnet mask on each host to ARP the union of the subnets, and let the router proxy for anything not on the wire. We do this all over our network, it works fine. >And we have to stop thinking about "wires". There will certainly be >hundreds of subnets in a radio link, particularly in globe spanning RF. Yup. If the global radio implementation assigned a subnet per cell one would find oneself talking to one or more subnets at a time, not unlike some of our current "wires". Biggest new problem is reassigning the IP address of the host while moving from cell to cell. -- Walt ------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 11:24:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04882; Tue, 4 Oct 94 11:24:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04875; Tue, 4 Oct 94 11:24:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24573; Tue, 4 Oct 94 11:20:57 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA27357; Tue, 4 Oct 94 11:16:49 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00829; Wed, 5 Oct 1994 03:04:30 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Tue, 04 Oct 1994 01:15:22 MST." <199410040815.BAA08814@lager.cisco.com> Date: Wed, 05 Oct 1994 03:04:26 +1000 Message-Id: <7796.781290266@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 4 Oct 1994 01:15:22 -0700 From: Tony Li Message-ID: <199410040815.BAA08814@lager.cisco.com> Well, I don't know why not. Today, with the convergence time of RIP and IGRP you will have huge chunks of your network go into a black hole called holddown. Is that necessarily true for the implementation described (using RIP to inform hosts of routing, and no more). Holddown is used to avoid route flapping and consequent instability - if no-one is using the RIP information for calculating routes to redistribute then holddown would not contribute anything, would it? If you had three routers on a net communicating using OSPF, IS-IS, IGRP, or whatever, and then broadcasting their routing tables using RIP, then hosts on detecting that one of the sources of RIP broadcasts has vanished (in theory 3 minutes, however most hosts could probably do that in 45 seconds if they wanted for this purpose), then the host could immediately switch to using the RIP info from the routers that remain. If those routers relied on the first to forward traffic, then the black hole exists, and there's not much that can be done (and what's more, the RIP stuff using poison reverse, or even just split horizon, would indicate that no other path exists) - but if their paths to the destination follow an independant route then the hosts recovedr communications in just as long as the dead router detection takes to kick in. Holddowns don't seem relevant. That is, the host RIP implementation would simply ignore the holddown that routers should implement (which is about what routed does, as I recall it - even when it is running on something pretending to be a router) kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 13:20:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04980; Tue, 4 Oct 94 13:20:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04974; Tue, 4 Oct 94 13:20:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06425; Tue, 4 Oct 94 13:16:59 PDT Received: from sundance.itd.nrl.navy.mil ([132.250.92.89]) by Sun.COM (sun-barr.Sun.COM) id AA17303; Tue, 4 Oct 94 13:14:24 PDT To: ip-ng@sunroof2.Eng.Sun.COM Subject: (IPng) Auto-router mode Date: Tue, 4 Oct 94 21:12:17 GMT From: Ran Atkinson Message-Id: <9410042112.aa07290@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, ULTRIX is an example of an OS where if more than one network interface (e.g. 2 Ethernet cards) is installed, the system automatically starts routing via RIP and routed(8). I looked after an Ultrix VAX 750 for about 3 years in the 80s which is why I know that this is true of at least some versions of Ultrix. I believe that _most_ 4.2 (and 4.2 derived) BSD systems did this. IRIX, Solaris 1.x, Solaris 2.x, HPUX 8.x, and HPUX 9.x will also do this -- if 2 network interfaces are configured in, the host automatically turns itself into a router using RIP and routed/gated. Sure I configured in the IP addresses and netmasks for both interface cards, but no I did not explicitly configure routing on. So I wasn't speaking without some basis in facts. I don't have every version of every vendors OS, but I think the above sample space supports my contention that many vendors do or have-done this. Alex, I think that automatically having a host passively listen to routing can be dangerous in many (but not all) common environments. For example, NRL uses OSPFv2 as its IGP as do many other sites. However, some of our multi-homed machines auto-magically run RIP from routed(8) [as you might guess, I kill these routed(8)s whenever I find them :-]. Hosts that automatically listen passively have routing problems because they all passively listen for RIP advertisements (which are nearly always bogon in an environment like NRL's) rather than OSPFv2 LSAs (which would be accurate if they were heard). In the general case it isn't possible to know which routing protocol is in use without user/administrator intervention. EMPHASIS: I'm NOT objecting to host vendors including routing daemons and services. I WANT host vendors to do that. I'd prefer that hosts not automatically turn the routing services on whenever one of my users adds an Ethernet, FDDI, or ATM interface and configures the IP addr and netmask for that interface. You all as vendors will make business decisions. I grok that. I'm just offering a few suggestions that would save me (a trivially small customer) grief. :-) Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 13:30:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04996; Tue, 4 Oct 94 13:30:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04990; Tue, 4 Oct 94 13:30:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07192; Tue, 4 Oct 94 13:26:39 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA19279; Tue, 4 Oct 94 13:22:53 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA17094; Tue, 4 Oct 1994 13:15:40 -0700 Date: Tue, 4 Oct 1994 13:15:40 -0700 From: Tony Li Message-Id: <199410042015.NAA17094@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Robert Elz's message of Wed, 05 Oct 1994 03:04:26 +1000 <7796.781290266@munnari.OZ.AU> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Well, I don't know why not. Today, with the convergence time of RIP and IGRP you will have huge chunks of your network go into a black hole called holddown. Is that necessarily true for the implementation described (using RIP to inform hosts of routing, and no more). Holddown is used to avoid route flapping and consequent instability - if no-one is using the RIP information for calculating routes to redistribute then holddown would not contribute anything, would it? While it's not necessary in this particular case, the routers will still use holddown withing the IGRP backbone. So... you get the same effect. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 15:18:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05200; Tue, 4 Oct 94 15:18:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05193; Tue, 4 Oct 94 15:18:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17636; Tue, 4 Oct 94 15:15:05 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08717; Tue, 4 Oct 94 15:13:13 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00275; Tue, 4 Oct 94 15:07:24 -0700 Received: by xirtlu.zk3.dec.com; id AA07476; Tue, 4 Oct 1994 18:07:06 -0400 Message-Id: <9410042207.AA07476@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Auto-router mode In-Reply-To: Your message of "Tue, 04 Oct 94 21:12:17 GMT." <9410042112.aa07290@sundance.itd.nrl.navy.mil> Date: Tue, 04 Oct 94 18:06:59 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, I am sending this to clarify the different issues on the table so we technically can break them up into components and resolve them. First you send this message with my name on it and allude to an issue with "shell" scripts at boot-time below. >Jim, > I intended to make clear that I don't think that the IETF can/should >prevent vendors from shipping routed(8). I was trying to say that >IMHO _good_ vendors will ship something better than routed(8) [for >example gated(8)] as part of their "host as router" software set. If >I do turn a host into a router, I'd always like to use a really good >routing protocol (such as OSPF) rather than RIP. IMHO, good vendors >also won't ever automatically turn a host into a router with boot-time >shell scripts (as DEC, Sun, SGI, and HP currently appear to do :-). I responded with what and how our scripts come up and the fact that you can't even run TCP/IP on ULTRIX or OSF/1 until you run the setup scripts. Then you send this focusing the discussion on 2 Ethernets when they are attached. >Jim, > ULTRIX is an example of an OS where if more than one network >interface (e.g. 2 Ethernet cards) is installed, the system >automatically starts routing via RIP and routed(8). I looked after an >Ultrix VAX 750 for about 3 years in the 80s which is why I know that >this is true of at least some versions of Ultrix. I believe that >_most_ 4.2 (and 4.2 derived) BSD systems did this. IRIX, Solaris 1.x, >Solaris 2.x, HPUX 8.x, and HPUX 9.x will also do this -- if 2 network >interfaces are configured in, the host automatically turns itself into >a router using RIP and routed/gated. Sure I configured in the IP >addresses and netmasks for both interface cards, but no I did not >explicitly configure routing on. So I wasn't speaking without some >basis in facts. I don't have every version of every vendors OS, but I >think the above sample space supports my contention that many vendors >do or have-done this. Your right this is part of BSD but also part of using two Ethernets as a gateway to another subnet. You changed your input to us after my mail from your original mail. But thats not the point or what matters. Other than I am not a mind reader and you had not presented all your facts to me in the previous mail. But the point is that unless you configure the system with an address and/or a name it won't forward the packets that was my point there is no intelligence here it must be configured or as you correctly point out this is all bogus. I want to keep what this does in IPv6. I want to use the second Ethernet as a gateway. Lets start there. I don't want any spec in IPv6 to prevent me from doing that. Is that CLEAR? Now because my second Ethernet can forward packets does not mean I believe that interface should be doing advertisement. This is the second issue. I believe that is a separate discussion and part of the overall discussion to resolve how, when, and who can do route advertisement in IPv6. >EMPHASIS: > I'm NOT objecting to host vendors including routing daemons and >services. I WANT host vendors to do that. I'd prefer that hosts not >automatically turn the routing services on whenever one of my users >adds an Ethernet, FDDI, or ATM interface and configures the IP addr >and netmask for that interface. You all as vendors will make business >decisions. I grok that. I'm just offering a few suggestions that >would save me (a trivially small customer) grief. :-) This I think I agree with 100%. Geezzzz. Plus as Gary pointed out we need to make sure those daemons are compliant to what we decide. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 15:34:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05221; Tue, 4 Oct 94 15:34:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05215; Tue, 4 Oct 94 15:34:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19323; Tue, 4 Oct 94 15:31:22 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10845; Tue, 4 Oct 94 15:26:09 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA01309; Tue, 4 Oct 94 15:21:34 -0700 Received: by xirtlu.zk3.dec.com; id AA07749; Tue, 4 Oct 1994 18:21:16 -0400 Message-Id: <9410042221.AA07749@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) preliminary IPv6 ICMP specs for review In-Reply-To: Your message of "Tue, 04 Oct 94 07:46:44 GMT." <3288.bill.simpson@um.cc.umich.edu> Date: Tue, 04 Oct 94 18:21:10 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I dont agree with Bill. If your having trouble getting your authors to do a final review and the working group is in the mode we are in to get the specs stable so we can implement then sending out the draft is a good idea to chase any last minute bugs with the working group before it goes to the IETF masses. I have heard no one colain of drafts of this size causing a mailer problem. For almost two years I have seen folks send much larger drafts than the ICMP draft to SIPP, TUBA, and CATNIP. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 18:23:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05338; Tue, 4 Oct 94 18:23:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05332; Tue, 4 Oct 94 18:22:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07676; Tue, 4 Oct 94 18:19:30 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA17100; Tue, 4 Oct 94 18:19:07 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA07317; Tue, 4 Oct 94 18:11:23 -0700 Received: by xirtlu.zk3.dec.com; id AA13464; Tue, 4 Oct 1994 21:11:17 -0400 Message-Id: <9410050111.AA13464@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: veizades@ftp.com Subject: (IPng) IPv6 Services Date: Tue, 04 Oct 94 21:11:11 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi John, >The Service Location Workign Group has been looking at this problem for >quite a while and has an internet-draft that describes a proposal for doing >this work (draft-ietf-svrloc-protocol-04.txt). The next version of this >document (clarification and formating issues) will be put forth as a >proposed standard and placed into the IPv6 document pool as a draft for >service discovery for IPv6. This protocol is UDP/TCP multicast based and is >designed with secutity, multilingual, and transport independence in mind. >.... >This protocol is a bit more flexible than what Bill has proposed. The >protocol was designed with human interaction as well as programmed control. >With human interaction as a need system advertisements can contain natural >scaling ot a campus environment. Detection of the central cache is done by >both hosts and servers and there is a fall back to a serverless mechanism. >The central cache has an information consistency checking mechanism. I have reviewed the draft. It is very forward thinking and I think the right approach to services after seeing various discussions on this list and thinking deeply about the affect to the total systems environment. As Dan McDonald also pointed out a phrase I liked too which is "kernel bloat". Putting this in the host kernels clearly would cause more kernel bloat. But I think it will take time to reach consensus (just on using the predicates) and to get some vendors on board to implement prototypes. But I hope this happens if it has not already started. Is it possible we can get a light weight version of the protocol for IPv6 produced that could be used to just support the address server and DNS as services on the network. For autoconfig that will use an address server to obtain a global address or for some of the work going on to provide DNS Autoregistration to locate "different classes" of DNS servers accessible to the host. This could be used potentially for IPv6 prototyping during this phase of IPng. The other question I have is related to Authentication. In IPv6 we have built in as an option Authentication as part of IPv6 network layer extended header. Does the service protocol still need the Authentication parts for IPv6? Finally have you or someone else thrown this out to IEEE POSIX, X/Open, or even the CORBA effort as a means to access objects too on the network? I think those are the kinds of folks doing that kind of work too and it may be good to synch up with them, as a thought. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 21:19:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05461; Tue, 4 Oct 94 21:19:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05455; Tue, 4 Oct 94 21:18:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15306; Tue, 4 Oct 94 21:15:27 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20956; Tue, 4 Oct 94 21:15:06 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA15053; Tue, 4 Oct 94 21:11:07 -0700 Received: by xirtlu.zk3.dec.com; id AA18190; Wed, 5 Oct 1994 00:11:03 -0400 Message-Id: <9410050411.AA18190@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) preliminary IPv6 ICMP specs for review In-Reply-To: Your message of "Wed, 05 Oct 94 02:37:03 +1000." <7785.781288623@munnari.OZ.AU> Date: Wed, 05 Oct 94 00:10:57 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM We have had other requests to put IGMP in separate doc. I think this may be a good idea too. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 21:26:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05473; Tue, 4 Oct 94 21:26:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05467; Tue, 4 Oct 94 21:25:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15507; Tue, 4 Oct 94 21:22:20 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA21693; Tue, 4 Oct 94 21:21:54 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA15387; Tue, 4 Oct 94 21:19:33 -0700 Received: by xirtlu.zk3.dec.com; id AA18220; Wed, 5 Oct 1994 00:19:29 -0400 Message-Id: <9410050419.AA18220@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Tue, 04 Oct 94 11:18:42 BST." <199410041018.AA13386@mitsou.inria.fr> Date: Wed, 05 Oct 94 00:19:23 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, Qualifier: Multihome both wires in same admin domain. Is your point 1 on multihome close what Tony suggested to work on? FYI I agree with your conclusion point 1 is best. Might be a point of convergence for the group too. I am not clear we agreed to multiple subnets on one wire and for sure we did not agree that subnets would span multiple wires. What is important to some is that I can have multiple logical network interfaces on one subnet, which is very tricky in IPv4 today but should be less tricky in Ipv6. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 4 23:28:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05553; Tue, 4 Oct 94 23:28:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05547; Tue, 4 Oct 94 23:28:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21167; Tue, 4 Oct 94 23:25:06 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA02771; Tue, 4 Oct 94 23:24:44 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA14943; Tue, 4 Oct 1994 23:24:42 -0700 Date: Tue, 4 Oct 1994 23:24:42 -0700 From: Tony Li Message-Id: <199410050624.XAA14943@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Tue, 04 Oct 1994 09:02:33 -0400 <9410041302.AA03349@snark.imsi.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, It is possible that everyone is contemplating one of these things going by like a heartbeat every few moments with twenty second lifetime -- if this is the case, please let me know now. That IS the idea. Configurable, of course. With the timers set slightly higher for those of us on the Left Coast. ;-) However, that 18 hour figure made me gasp -- I can hardly imagine a situation in which I could feel like I could trust routing information that long, and with time I imagine my constraints on reliability will reduce, not increase, my windows in which to re-assemble my network during failures. Well, that's your situation. Other folks are different. 20s overhead is a waste if your routers are more stable... Still not fast enough, by the way -- but I was hoping for V6 to provide improvements, not steps backward. So turn down your RIP timers. Yes, you'll have to hack routed on your hosts, but if it's THAT important to you... Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 03:40:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05692; Wed, 5 Oct 94 03:40:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05686; Wed, 5 Oct 94 03:39:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27453; Wed, 5 Oct 94 03:36:28 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA08767; Wed, 5 Oct 94 03:36:04 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA15376; Wed, 5 Oct 94 06:31:58 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410051031.AA15376@pluto.dss.com> Subject: Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Wed, 5 Oct 1994 06:31:57 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <199410041018.AA13386@mitsou.inria.fr> from "Christian Huitema" at Oct 4, 94 11:18:42 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2048 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Folks, > The unconclusiveness of the "multihomed" host discussion is quite > predictable - there is no good model. In fact, there are three models, > each of which has some advantages and some weak points: > 2) Ask the routers to broadcast their routing tables at regular > intervals (the "RIP on the wire" solution). This is either slow, if > the broadcast interval is large, or very heavy, if the interval is > short: the routing tables may be quite large. It is also overshooting > the target by a wide margin: hosts are not interested in complete > routing tables, but in a subset - their working set. Then we have the > metric problem which Tony pointed out: the comparison only works if > all the routers of all the subnets to which the host is linked use > consistent metrics. This is by definition not the case if they dont > belong to the same administration. > My personal preference is for (1). I don't believe that (2) scales > well, specially if the routing tables grow very large; I do believe > that (3) generates far too much overhead. In fact, it would be a good > idea to combine (1) with some form of black-hole detection, so that > multi-homed hosts do not use misfunctioning routers! > Christian Huitema One would think it would be possible to make (2) scale well by forcing defaults to be propagated in lieue of genuine routes if the routing table became too large or the distance to a network became too great. If hosts are known to make rip queries for unknown routes, rip could be restricted to only broadcasting changes. After all no real routing would be done with rip. Rip would be used simply to distribute routing info. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 06:38:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05799; Wed, 5 Oct 94 06:38:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05793; Wed, 5 Oct 94 06:38:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03080; Wed, 5 Oct 94 06:34:57 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA01421; Wed, 5 Oct 94 06:34:36 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14449(1)>; Wed, 5 Oct 1994 06:30:29 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 5 Oct 1994 06:34:11 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) IPng implementors' meeting Date: Wed, 5 Oct 1994 06:34:10 PDT From: Steve Deering Message-Id: <94Oct5.063411pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi, ipng-ers. I'm back on line after more than a month of travel and a week of reading the resulting email backlog. (I've read it all, but I haven't even started to answer any of it!) Regarding the implementors' meeting next week: - The meeting times are 9 to 5 on Monday and Tuesday, and 9 to noon on Wednesday. I suggest that everyone plan to arrive at 8:45 in the morning, so we can get started by 9. - The meeting location is the Digital Cambridge Research Lab, One Kendall Square, Building 700, Second Floor, Sahara Conference Room, Cambridge, MA. See the earlier meeting announcement message from Ross Callon for walking/driving directions. - The local host is Jim Bound, and it sounds like he has organized an excellent meeting facility for us. He has arranged for coffee/danish to be provided for the morning break, and soda/cookies for the afternoon. We will be on our own for lunch -- apparently there is a good choice of nearby restaurants. - Appended below is the list of people who have told Jim they are coming to the meeting. If you plan to come, and your name is not on the list, please let Jim (bound@zk3.dec.com) know ASAP. (Also, if you are on the list, but have decided NOT to come, it would nice to let Jim know that.) - Regarding an agenda, we plan to follow the successful formula of the previous implementors' meeting, i.e., the first item of business (after introductions and local arrangements) will be to solicit agenda items from all attendees, merge them, and sort them into an agreed order. So please come prepared with a list of issues that you have tripped across while implementing or reading the specs. The scope is not limited to the base IPv6 protocol, but to all the IPv6 specs (written and unwritten!), including ICMP, security, autoconfig, API issues, transition, etc. See you in Cambridge. Steve ------------- Current list of attendees: Ran Atkinson NRL Dan McDonald NRL Allison Mankin NRL Scott Bradner Harvard Steve Deering XEROX Bob Hinden Sun Erik Nordmark Sun Bob Gilligan Sun Sue Thomson Bellcore Mike Davis Penril Joachim Martillo Penril Tony Buno Penril Bill Simpson Consultant Tony Li Cisco Dave Katz Cisco Charlie Perkins IBM Yakov Rehketer IBM Frank Solensky FTP Marc Hasson Mentat Richard Fox Netcom Julie Myers Network Systems Duan Butler Network Systems Warren Wagner Process Software Bernie Volz Process Software Jim Bound Digital Alex Conta Digital John Day BBN Ross Callon Wellfleet Dimitry Haskin Wellfleet Avri Dora Proteon Rob Austein Epilogue Technology Dave Bridgam Epilogue Technology Justin Walker Apple Ping Chen Apple ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 07:48:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05854; Wed, 5 Oct 94 07:48:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05848; Wed, 5 Oct 94 07:48:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06260; Wed, 5 Oct 94 07:44:37 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA14901; Wed, 5 Oct 94 07:44:01 PDT Received: from relay.imsi.com by wintermute.imsi.com id KAA08263 for ; Wed, 5 Oct 1994 10:43:58 -0400 Received: from snark.imsi.com by relay.imsi.com id KAA26861 for ; Wed, 5 Oct 1994 10:43:57 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04967; Wed, 5 Oct 94 10:43:57 EDT Message-Id: <9410051443.AA04967@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery In-Reply-To: Your message of "Tue, 04 Oct 1994 23:24:42 PDT." <199410050624.XAA14943@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Wed, 05 Oct 1994 10:43:56 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > However, that > 18 hour figure made me gasp -- I can hardly imagine a situation in > which I could feel like I could trust routing information that long, > and with time I imagine my constraints on reliability will reduce, not > increase, my windows in which to re-assemble my network during > failures. > >Well, that's your situation. Other folks are different. 20s overhead >is a waste if your routers are more stable... I can believe the statement "other folks don't need reliability so long timeouts are fine", but the comment about stability makes no sense to me. My client's routers are bloody stable, too -- they are Ciscos, which I must say, Tony, are very good pieces of hardware. However, they have a lot of them -- I've been in environments with very large critical corporate internets where there were HUGE numbers of them. Every once in a while, one fails. When one fails, its may be emergency that you need to route around immediately. The problem is the emergency case, not the average case. You can make routers as stable as you like and the need STILL exists for rapid failover. > Still not fast enough, > by the way -- but I was hoping for V6 to provide improvements, not > steps backward. > > So turn down your RIP timers. Yes, you'll have to hack routed on your > hosts, but if it's THAT important to you... Let me propose a strawman. There are thirty or fourty things wrong with it; just look at the principles. Imagine you have a bunch of hosts on a broadcast type lan with two routers providing exit to the outside world. In a fairly heavy traffic situation the routers should be sending packets most of the time. Now, if each router keeps a deadman timer that goes off if it doesn't see traffic at least every 10 seconds from the other router put out onto the lan, and then proceeds to try to ping the other router if it seems it might be down because the timer expired (routers run special operating systems and can produce far better guarantees about whether they will respond) and then declares the other router down by some multicast protocol on the segment if it doesn't reply, we now have the ability to to route around a problem within fifteen or twenty seconds at most -- a real improvement! (I suggest the routers monitoring each other because their specialized hardware can be rigged to do this sort of thing cheaply where normal hosts would have to go promiscuous and it could get rather ugly.) Now, this is grossly imperfect for all sorts of reasons -- it only does you good on a broadcast network, it burdens the routers, etc. My point is, however, that this is a pretty significant incremental improvement in failover. As we move to multi gigabit networks and machines several orders of magnitude faster than the ones we run now, failover times measured in minutes are going to seem like an eternity. I'm hoping that in the medium term we can move down to seconds and in the long term to subsecond failover times. The IP stack has been gradually improving in speed and reliability over the years and I don't want to see any sort of artificial barrier to that continuing. The IPv6 model as its being discussed currently doesn't seem to be sufficiently flexible to support such things in the long term. In particular, it seems end hosts are being expected simply to find out about black holes from (fairly long) timeouts rather than by some sort of active mechanism. I don't see that you can reasonably lower failover times in the long run by this mechanism -- some sort of active "this router is down" or "route those packets through HERE" mechanism is needed. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 08:00:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05883; Wed, 5 Oct 94 08:00:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05877; Wed, 5 Oct 94 08:00:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06835; Wed, 5 Oct 94 07:56:36 PDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA16979; Wed, 5 Oct 94 07:56:09 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03741; 5 Oct 94 10:48 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-simpson-ipv6-discov-process-00.txt Date: Wed, 05 Oct 94 10:48:09 -0400 Message-Id: <9410051048.aa03741@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Neighbor Discovery -- Processing Author(s) : W. Simpson Filename : draft-simpson-ipv6-discov-process-00.txt Pages : 24 Date : 10/04/1994 This document discusses the techniques for identification of and forwarding to adjacent IPv6 nodes, including Next Hop Determination and Router Discovery. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-simpson-ipv6-discov-process-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-ipv6-discov-process-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19941004100202.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-discov-process-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-discov-process-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941004100202.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 09:04:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05903; Wed, 5 Oct 94 09:04:24 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05897; Wed, 5 Oct 94 09:03:57 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA06866; Wed, 5 Oct 1994 08:59:58 -0700 Date: Wed, 5 Oct 1994 08:59:58 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410051559.IAA06866@jurassic.Eng.Sun.COM> To: ipng@sunroof Cc: hinden@jurassic Subject: (IPng) New Addressing Arch Draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IPng-ers, I sent a new draft of the ipng addressing architecture in to become an internet draft. It should show up in a day or so. In the meantime it can be anonymously ftp'ed from parcftp.xerox.com as pub/sipp/draft-ietf-ipng-addr-00.txt The changes from the pervious version include: o Title and protocol changed to IPng and IPv6. o Address prefixes were redone to put the IPv4, NSAP, and IPX allocations in the 0000 block and to reduce the amount of total address space allocated. Also, the size of the provider based unicast address block initially assigned was reduced. o NSAP format was revised based on Brian Carpenter's latest draft and a reference was included. o The SIT address terminology was updated and the address formats were changed to include 0000 or FFFF in bits above the IPv4 address. o Various clarifications were added and a number of typos were fixed. Bob p.s. It will also soon be in an "ipng" directory at parcftp. The "ipng" directory on parcftp should be set up any day now. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 11:14:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06286; Wed, 5 Oct 94 11:14:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06280; Wed, 5 Oct 94 11:14:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24398; Wed, 5 Oct 94 11:10:39 PDT Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by Sun.COM (sun-barr.Sun.COM) id AA27406; Wed, 5 Oct 94 09:10:53 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03835; 5 Oct 94 10:52 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-thomson-ipng-dns-00.txt Date: Wed, 05 Oct 94 10:52:27 -0400 Message-Id: <9410051052.aa03835@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS Extensions to support IP version 6 Author(s) : S. Thomson, C. Huitema Filename : draft-thomson-ipng-dns-00.txt Pages : 5 Date : 10/04/1994 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new inverse lookup domain to store the inverse mapping, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-thomson-ipng-dns-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-thomson-ipng-dns-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19941004153728.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-thomson-ipng-dns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thomson-ipng-dns-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941004153728.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 11:24:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06322; Wed, 5 Oct 94 11:24:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05809; Wed, 5 Oct 94 07:00:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03953; Wed, 5 Oct 94 06:56:31 PDT Received: from swift.bellcore.com by Sun.COM (sun-barr.Sun.COM) id AA05331; Wed, 5 Oct 94 06:56:09 PDT Received: (from set@localhost) by swift.bellcore.com (8.6.9/8.6.9) id JAA04160 for ipng@sunroof.eng.sun.com; Wed, 5 Oct 1994 09:56:07 -0400 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.swift.galaxy.sun4.41 via MS.5.6.swift.galaxy.sun4_41; Wed, 5 Oct 1994 09:56:06 -0400 (EDT) Message-Id: Date: Wed, 5 Oct 1994 09:56:06 -0400 (EDT) From: Susan Thomson To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) revised DNS draft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have posted a revised DNS spec which should be announced shortly. In the meantime, it is retrievable from thumper.bellcore.com in /pub/sipp/ipv6DNS.txt. The changes to the last version of the SIPP spec include: 1. Taken account of IPv6 address definition in new RR type, now called AAAA. Record type number has been assigned by IANA. 2. Taken account of IPv6 address definition in textual representation. 3. Taken account of IPv6 address definition in inverse lookup name. The inverse lookup name is rooted at IP6.INT, after consultation with IANA. The inverse lookup name is now split along nibble boundaries, to mitigate problems with delegation granularity. 4. Removed the section dealing with transition issues; these will be defined in the transition and operational specifications. Sue ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 13:33:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06464; Wed, 5 Oct 94 13:33:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06458; Wed, 5 Oct 94 13:33:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07453; Wed, 5 Oct 94 13:30:03 PDT Received: from mailhost.wco.ftp.com (kingkong.wco.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA21379; Wed, 5 Oct 94 13:29:05 PDT Date: Wed, 5 Oct 94 13:19:46 PDT Message-Id: <9410052019.AA03478@mailhost.wco.ftp.com> Received: from zoi (zoi.wco.ftp.com) by mailhost.wco.ftp.com; Wed, 5 Oct 94 13:19:46 PDT X-Sender: veizades@wco.ftp.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM From: veizades@ftp.com (John Veizades) Subject: (IPng) Re: IPv6 Services X-Mailer: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 09:11 PM 10/4/94 -0400, bound@zk3.dec.com wrote: >I have reviewed the draft. It is very forward thinking and I think the >right approach to services after seeing various discussions on this list >and thinking deeply about the affect to the total systems environment. >As Dan McDonald also pointed out a phrase I liked too which is "kernel >bloat". Putting this in the host kernels clearly would cause more >kernel bloat. Thanks for the vote of confidence. The issue of kernel bloat is a nonissue in my opinion, you added to the size of the kernel to get some functionality and the question is, is that functionality important enough to warrant the additional code. I believe that a protocols like service location improve the end users ability to use networking protocols like TCP/IP and go a long way to achieving the ease of use requirements we have been lacking for so long. Yes they do add to the size of the networking kernel but they are also an integral part of modern networking protocols. >Is it possible we can get a light weight version of the protocol for >IPv6 produced that could be used to just support the address server and >DNS as services on the network. For autoconfig that will use an address >server to obtain a global address or for some of the work going on to >provide DNS Autoregistration to locate "different classes" of DNS >servers accessible to the host. This could be used potentially for IPv6 >prototyping during this phase of IPng. > The light weight protocol that you want is the service location protocol without the predicate language and the SCOPE stuff. It is acceptable to implement the protocol without implementing these features. For the address server this would be a query for the distinguished attribute of the address server and the same would go for the DNS. >The other question I have is related to Authentication. In IPv6 we >have built in as an option Authentication as part of IPv6 network layer >extended header. Does the service protocol still need the >Authentication parts for IPv6? > This protocol is designed to work over network protocols that do not support authentication at any level (IPv4, AppleTalk) and this feature could easlily be ignored by setting the auth type to 'none'. >Finally have you or someone else thrown this out to IEEE POSIX, X/Open, >or even the CORBA effort as a means to access objects too on the >network? I think those are the kinds of folks doing that kind of work >too and it may be good to synch up with them, as a thought. > I am not involved with any of these groups, so no it has not been brought up. John Veizades... FTP Software, Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 16:18:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06563; Wed, 5 Oct 94 16:18:36 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06557; Wed, 5 Oct 94 16:18:23 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id QAA04302; Wed, 5 Oct 1994 16:14:54 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA14340; Wed, 5 Oct 1994 16:15:20 +0800 Date: Wed, 5 Oct 1994 16:15:20 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9410052315.AA14340@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) New IPv6 socket interface API spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sue Thompson, Jim Bound and myself have put together a revised version of the IPv6 socket interface API spec and sent it in to the internet-drafts editor. The paper is enclosed below. It should show up in the internet-drafts directories in a few days. The changes in this version include: - Support for 128 bit addresses in fixed-size address structure. - Ability to set and retrieve the flow ID. - Ability to set and retrieve source route information. - First cut at support for IPv6 multicast. - Numerous other minor changes suggested by people who reviewed the earlier drafts. There are still a few open issues left. The ones we know about are listed in the paper. If there is interest, we can discuss this paper at the implementors meeting next week. Bob. Internet Engineering Task Force R. E. Gilligan (Sun) INTERNET-DRAFT S. Thomson (Bellcore) J. Bound (Digital) October 5, 1994 IPv6 Program Interfaces for BSD Systems Abstract In order to implement the version 6 Internet Protocol (IPv6) [1] in an operating system based on Berkely Unix (4.x BSD), changes must be made to the application program interface (API). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like to have the same portability to be possible with IPv6 applications. This memo presents a set of extensions to the BSD socket API to support IPv6. The changes include a new data structure to carry IPv6 addresses, new name to address translation library functions, new address conversion functions, and some new setsockopt() options. The changes are designed to be minimal and to provide source and binary compatibility for existing applications. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. This Internet Draft expires on April 5, 1995. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Distribution of this memo is unlimited. draft-ietf-ipv6-bsd-api-00.txt [Page 1] INTERNET-DRAFT IPv6 BSD API Spec October 1994 1. Introduction. While IPv4 addresses are 32 bits long, IPv6 nodes are identified by 128-bit addresses [2]. The socket interface API make the size of an IP address quite visible to an application; virtually all TCP/IP applications for BSD-based systems have knowledge of the size of an IP address. Those parts of the API that expose the addresses need to be extended to accommodate the larger IPv6 address size. This paper presents an attempt to define the API extensions needed to support IPv6 in BSD systems. This specification is preliminary. The API extensions are expected to evolve as we gain more implementation experience. 2. Design considerations There are a number of important considerations in designing changes to this well-worn API: - The extended API should provide both source and binary compatibility for programs written to the original API. That is, existing program binaries should continue to operate when run on a system supporting the new API. In addition, existing applications that are re-compiled and run on a system supporting the new API should continue to operate. Simply put, the API changes for IPv6 should not break existing programs. - The changes to the API should be as small as possible in order to simplify the task of converting existing IPv4 applications to IPv6. - Where possible, applications should be able to use the extended API to interoperate with both IPv6 and IPv4 hosts. Applications should not need know which form of host they are communicating with. The IPv6 transition mechanisms [3] provide a way to represent addresses of IPv4 nodes as IPv6 addresses. If possible, this encoding should be used. - IPv6 addresses carried in data structures should be 64-bit aligned. This is necessary in order to obtain optimum performance on 64-bit machine architectures. 2.1. What needs to be changed The socket interface API consists of a few distinct components: - Core socket functions - Address data structures draft-ietf-ipv6-bsd-api-00.txt [Page 2] INTERNET-DRAFT IPv6 BSD API Spec October 1994 - Name-to-address translation functions - Address conversion functions The core socket functions -- those functions that deal with such things as setting up and tearing down TCP connections, and sending and receiving UDP packets -- were designed to be transport independent. Where protocol addresses are passed as function arguments, they are carried as opaque pointers. A protocol specific address data structure is defined for each protocol that the socket functions support. Applications must cast these protocol specific address structures into the generic "sockaddr" data type when using the socket functions. These functions need not change for IPv6, but a new IPv6 specific address data structure is needed. The "sockaddr_in" structure is the protocol specific data structure for IPv4. This data structure actually includes 8-bytes of unused space, and it is tempting to try to use this space to adapt the sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in structure is not large enough to hold the 16-byte IPv6 address as well as the other information (2-byte address family and 2-byte port number) that is needed. So a new address data structure must be defined for IPv6. The name-to-address translation functions in the socket interface are gethostbyname() and gethostbyaddr(). Gethostbyname() does not provide enough flexibility to accommodate more than one protocol family. To solve this problem, we introduced a new name-to-address translation function which is analogous to gethostbyname(), but supports addresses in both the IPv4 and IPv6 address families. Gethostbyaddr() does not, strictly speaking, need to be replaced since it carries an address family argument and can be extended to support both address families without introducing compatibility problems. However, we have chosen to introduce a new function to maintain symmetry with the replacement to gethostbyname(). The new functions both carry an address family parameter, so they can be extended to operate with other protocol families in addition to IPv4 and IPv6. The address conversion functions -- inet_ntoa() and inet_addr() -- convert IPv4 addresses between binary and printable form. These functions are quite specific to 32-bit IPv4 addresses. We have designed two analogous functions which convert both IPv4 and IPv6 addresses, and carry an address type parameter so that they can be extended to other protocol families as well. Finally, a few miscellaneous features are needed to support IPv6. A new interface is needed in order to support the IPv6 flow label. New interfaces are needed in order to receive IPv6 multicast packets and control the sending of multicast packets. And an interface is necessary in order to pass IPv6 source route information between the application draft-ietf-ipv6-bsd-api-00.txt [Page 3] INTERNET-DRAFT IPv6 BSD API Spec October 1994 and the system. 3. Implementation experience Prototype implementations of IPv6 exposed a few issues in designing a compatible application interface. First, since the IPv6 transition mechanisms provide a way for IPv4 addresses to be represented as IPv6 addresses, applications using the extended API can interoperate with IPv4 nodes. For example, a client application can open a TCP connection to an IPv4 server by giving the IPv6 address of the IPv4 server in the connect() call. Most applications do not even need to know whether the peer is an IPv4 or IPv6 node. Such applications can simply treat IPv6 addresses as opaque values; They need not understand the "structure" by which IPv4 addresses are encoded within IPv6 addresses. Yet the structure can be decoded by those applications that do need to know whether the peer is IPv6 or IPv4. This should prove to be a significant simplification since most applications will need to interoperate with both IPv4 and IPv6 nodes for some time to come. Second, to a limited degree, existing applications written to the IPv4 API can interoperate with IPv6 nodes. This is generally only possible if the application does not "look at" the peer address that is provided by the API. (e.g. the source address provided by the recvfrom() function when a UDP packet is received, or the client address returned by the accept() function.) Third, the common application practice of passing open socket descriptors between processes across an exec() call can cause problems. It is possible, for example, for an application using the extended API to pass an open socket to an older application using the original API. The old application could be confused if the socket functions return IPv6 address structures to it. The solution designed was to provide a mechanism by which applications could have explicit control over what form of addresses are returned. 4. Interface Specification 4.1. New Address Family We have defined a address family macro in : #define AF_INET6 24 /* Internet Protocol version 6 */ draft-ietf-ipv6-bsd-api-00.txt [Page 4] INTERNET-DRAFT IPv6 BSD API Spec October 1994 The AF_INET6 definition is used to distinguish between the original sockaddr_in address data structure, and the new sockaddr_in6 data structure. We have also defined a new protocol family macro in . Like most of the other protocol family macros, it is identical with the corresponding address family macro: #define PF_INET6 AF_INET6 The PF_INET6 is used in the first argument to the socket() function to indicate that an IPv6 socket is being created. 4.2. Socket Address Structure The sockaddr_in structure is used to pass IPv4 addresses between applications and the system in the socket functions. We have defined a new structure to carry IPv6 addresses: struct sockaddr_in6 { u_short sin6_family; /* AF_INET6 */ u_short sin6_port; /* Transport layer port # */ u_long sin6_flowlabel; /* IPv6 flow label */ u_long sin6_addr[4]; /* IPv6 address */ }; The sin6_family field is used to identify a buffer as a sockaddr_in6 structure. This field is designed to overlay the sa_family field when the buffer is cast to a sockaddr data structure. The value of this field must be AF_INET6. The sin6_port field is used to store the UDP or TCP port number. This field is used in the same way as the sin_port field of the sockaddr_in structure. The sin6_flowlabel is used to store the IPv6 flow label. The use of this field is explained in sec 4.8. The sin6_addr field is used to store the 128-bit IPv6 address. It is used in the same manner as the sin_addr field of the sockaddr_in structure. All fields of the sockaddr_in6 structure are stored in network byte order. The ordering of elements in this structure is specifically designed so that the sin6_addr field will be aligned on a 64-bit boundary. This is done for optimum performance on 64-bit architectures. draft-ietf-ipv6-bsd-api-00.txt [Page 5] INTERNET-DRAFT IPv6 BSD API Spec October 1994 4.3. The Socket Functions Applications use the socket() function to create a socket descriptor that represents a communication endpoint. The arguments to the socket() function tell the system which protocol to use, and what format address structure will be used in subsequent functions. For example, to create an IPv4/TCP socket, applications make the call: s = socket (PF_INET, SOCK_STREAM, 0); To create an IPv4/UDP socket, applications make the call: s = socket (PF_INET, SOCK_DGRAM, 0); Applications may create IPv6/TCP and IPv6/UDP sockets by simply using the constant PF_INET6 instead of PF_INET in the first argument. For example, to create an IPv6/TCP socket, applications make the call: s = socket (PF_INET6, SOCK_STREAM, 0); To create an IPv6/UDP socket, applications make the call: s = socket (PF_INET6, SOCK_DGRAM, 0); Once the application has created a PF_INET6 socket, it must use the sockaddr_in6 address structure when passing addresses in to the system. The functions which the application uses to pass addresses into the system are: bind() connect() sendto() The system will use the sockaddr_in6 address structure to return addresses to applications that are using PF_INET6 sockets. The functions that return an address from the system to an application are: accept() recvfrom() getpeername() getsockname() None of the core socket functions themselves need to be changed, since the all of the "address carrying" functions use an opaque address pointer, and carry an address length as a function argument. draft-ietf-ipv6-bsd-api-00.txt [Page 6] INTERNET-DRAFT IPv6 BSD API Spec October 1994 4.4. Compatibility with IPv4 Applications In order to support the large base of applications using the original API, system implementations must provide complete source and binary compatibility with the original API. This means that systems must continue to support PF_INET sockets and the sockaddr_in addresses structure. Applications must be able to create IPv4/TCP and IPv4/UDP sockets using the PF_INET constant in the socket() function, as described in the previous section. Applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets simultaneously within the same process. Applications using the original API should continue to operate as they did on systems supporting only IPv4. That is, they should continue to interoperate with IPv4 nodes. It is not clear, though, how, or even if, those IPv4 applications should interoperate with IPv6 nodes. The problem primarily has to do with the how these applications represent addresses of IPv6 nodes. What address should be returned to the application when an IPv6/UDP packet is received, or an IPv6/TCP connection is accepted? The peer's address could be any arbitrary 128-bit IPv6 address. But the application is only equipped to deal with 32-bit IPv4 addresses encoded in sockaddr_in data structures. We have not discovered any solution that provides complete transparent interoperability with IPv6 nodes for applications using the original IPv4 API. However, we did develop two techniques that partially solve the problem: 1) Prohibit communication between IPv4 applications and IPv6 nodes. Only UDP packets received from IPv4 nodes would be passed up to the application, and only TCP connections received from IPv4 nodes would be accepted. UDP packets from IPv6 nodes would be dropped, and TCP connections from IPv6 nodes would be refused. 2) The implementation could generate a local 32-bit cookie to represent the full 128-bit IPv6 address, and pass this value to the application. The implementation would maintain a mapping from cookie value into the 128-bit IPv6 address that it represents. When the application passed a cookie back into the system (for example, in a sendto() or connect() call) the implementation would use the 128-bit IPv6 address that the cookie represents. The cookie would have to be chosen so as to be an invalid IPv4 address (e.g. an address on net 127.0.0.0), and the implementation would have to make sure that these cookie values did not escape into the Internet as the source or destination addresses of IPv4 packets. draft-ietf-ipv6-bsd-api-00.txt [Page 7] INTERNET-DRAFT IPv6 BSD API Spec October 1994 Both of these techniques have drawbacks. System implementors may use one of these techniques or implement another solution. This is an area for further study. 4.5. Compatibility with IPv4 Nodes The API also provides a different type of compatibility: the ability for applications using the extended API to interoperate with IPv4 nodes. This feature is possible because it is possible to to represent IPv4 addresses as IPv6 addresses. The encoding of IPv4 addresses as IPv6 addresses is defined in the Simple IPv6 Transition (SIT) specifications [3]. This encoding places the 32-bit IPv4 address in the low-order 32-bits of a 128-bit IPv6 address, and sets the high-order 96-bits to zero. An IPv4 address encoded as an IPv6 address is written like this: 0:0:0:0:0:0: Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv6 address, and passing the resulting address within a sockaddr_in6 structure in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way. 4.6. Sockets Passed Across exec() Unix allows open sockets to be passed across an exec() call. It is a relatively common application practice to pass open sockets across exec() calls. Because of this, it is possible for an application using the original API to pass an open PF_INET socket to an application using the extended API that is expecting to receive a PF_INET6 socket. Similarly, it is possible for an application using the extended API to pass an open PF_INET6 socket to an application using the original API that is only equipped to deal with PF_INET sockets. Either of these cases could cause problems, because the application which is passed the open socket might not know how to decode the address structures returned in subsequent socket functions. To remedy this problems, we have defined a new setsockopt() option that allows an application to "transform" a PF_INET6 socket into a PF_INET socket and vice-versa. An IPv6 application that is passed an open socket from an unknown draft-ietf-ipv6-bsd-api-00.txt [Page 8] INTERNET-DRAFT IPv6 BSD API Spec October 1994 process may use the IP_ADDRFORM setsockopt() option to "convert" the socket to PF_INET6. Once that has been done, the system will return sockaddr_in6 address structures in subsequent socket functions. Similarly, an IPv6 application that is about to pass an open PF_INET6 socket to a program that may not be IPv6 capable may "downgrade" the socket to PF_INET before calling exec(). After that, the system will return sockaddr_in address structures to the application that was exec()'ed. The macro definition for this new option in is: #define IP_ADDRFORM 0x16 /* get/set form of returned addrs */ The IP_ADDRFORM option is at the IPPROTO_IP level. The only valid option values are PF_INET6 and PF_INET. For example, to convert a PF_INET6 socket to PF_INET, a program would call: int addrform = PF_INET; if (setsockopt(s, IPPROTO_IP, IP_ADDRFORM, (char *) &addrform, sizeof(addrform)) == -1) perror("setsockopt IP_ADDRFORM"); An application may use IP_ADDRFORM in the getsckopt() function to learn whether an open socket is a PF_INET of PF_INET6 socket. 4.7. Flow Label The IPv6 header has a 28-bit field to hold a "flow label". Applications have control over what flow label value is used in packets that they originate, and have access to the flow label value of packets that they send. The sin6_flowlabel field of the sockaddr_in6 structure is used to carry the flow label between the application and the system. An application may specify a flow label to use in the transmitted packets of an actively opened TCP connection by setting the sin6_flowlabel field of the sockaddr_in6 structure passed in the connect() function. An application may specify the flow label to use in transmitted UDP packets by setting the sin6_flowlabel field of the sockaddr_in6 structure passed in the sendto() function. If an application does not care what flow label is used, it should set the flowlabel value to zero. An application may specify the flow label to use in transmitted packets of a passively accepted TCP connection, by setting the sin6_flowlabel field of the address passed in the bind() function. draft-ietf-ipv6-bsd-api-00.txt [Page 9] INTERNET-DRAFT IPv6 BSD API Spec October 1994 The flow label that appeared in received UDP packets is passed up to the application in the sin6_flowlabel field of the sockaddr_in6 structure that is returned in the recvfrom() call. The flow label that appeared in the received SYN segment of a passively accepted TCP connection is returned to the application in the sin6_flowlabel field of the sockaddr_in6 structure that is passed in the accept() call. 4.8. Handling IPv6 Source Routes IPv6 makes more use of the source routing mechanism than IPv4. In order for source routing to operate properly, the node receiving a request packet that bears a source route must reverse that source route when sending the reply. In the case of TCP, the reversal can be done in the transport protocol implementation transparently to the application. But in the case of UDP, the application must perform the reversal. The transport protocol code can not perform the reversal for UDP packets because a UDP application may receive a number of requests and generate replies asynchronously. A "reply" sent by an application may not match the "request" most recently passed up to the application. The API for source routing has two components: providing a source route to be used with actively opened TCP connections being originated and UDP packets being sent, and receiving the source route that arrived with passively accepted TCP connections and received UDP packets. An application may always provide a source route with TCP connections being originated and UDP packets being sent. But to receive source routes, the application must enable an option. To provide a source route, an application simply provides an array of sockaddr_in6 data structures in the address argument of the sendto() function (when sending a UDP packet), or the connect() function (when actively opening a TCP connection). The length argument of the function is the total length, in bytes, of the array. The elements of the array represent the full source route, including both source and destination identifying address. The elements of the array are ordered from destination to source. That is, the first element of the array represents the destination identifying address, and the last element of the array represents the source identifying address. If the application provides a source route, the source identifying address can not be omitted. The sin6_addr field of the source identifying address may be set to zero, however, in which case the system will select an appropriate source address. The sin6_port field of the destination identifying address must be assigned. The sin_port field of the source identifying address may be set to zero, in which case the system will select an appropriate source port number. The sin6_port and sin6_flowid fields of the intermediate addresses must be set to zero. draft-ietf-ipv6-bsd-api-00.txt [Page 10] INTERNET-DRAFT IPv6 BSD API Spec October 1994 The arrangement of the address structures in the address buffer passed to connect() or sendto() is shown in the figure below: +--------------------+ | | | sockaddr_in6[0] | Destination Identifying Address | | +--------------------+ | | | sockaddr_in6[1] | Last Source-Route Hop Address | | +--------------------+ . . . . . . +--------------------+ | | | sockaddr_in6[N-1] | First Source-Route Hop Address | | +--------------------+ | | | sockaddr_in6[N] | Source Identifying Address | | +--------------------+ Address buffer when sending a source route The IP_RCVSRCRT setsockopt() option controls the reception of source routes. The option is disabled by default. Applications must explicitly enable the option using the setsockopt() function in order to receive source routes. The macro definition for this new option in is: #define IP_RCVSRCRT 0x17 /* Enable/Disable reception of IPv6 source routes */ The IP_RCVSRCRT option is at the IPPROTO_IP level. An example of how an application might use this option is: int on = 1; /* value == 1 means enable the option */ if (setsockopt(s, IPPROTO_IP, IP_RCVSRCRT, (char *) &on, sizeof(on)) == -1) perror("setsockopt IP_RCVSRCRT"); When the IP_RCVSRCRT option is disabled, only a single sockaddr_in6 address structure is returned to applications in the address argument draft-ietf-ipv6-bsd-api-00.txt [Page 11] INTERNET-DRAFT IPv6 BSD API Spec October 1994 of the recvfrom() and accept() functions. This address represents the source identifying address of the UDP packet received or the TCP connection accepted. When the IP_RCVSRCRT option is enabled, the address argument of the recvfrom() function (when receiving UDP packets) and the accept() functions (when passively accepting TCP connections) carry an array of sockaddr_in6 structures. The array will hold two elements -- source and destination address -- when the received UDP packet or TCP SYN packet does not carry a source route. The array will hold more than two elements when the received packet carries a source route. The addresses in the array are ordered from source to destination. That is, the first element of the array holds source identifying address of the received packet. Following this in the array are the intermediary hops. And the last element of the array holds the destination identifying address. Note that this is the opposite of the order specified for sending. This ordering was chosen so that the address array received in a recvfrom() call can be used in a subsequent sendto() call without requiring the application to re-order the addresses in the array. Similarly, the address array received in an accept() call can be used unchanged in a subsequent connect() call. The address length argument of the recvfrom() and accept() functions indicate the length, in bytes, of the full address array. This argument is a value-result parameter. The application sets the maximum size of the address buffer when it makes the call, and the system modifies the value to return the actual size of the buffer to the application. The sin6_port field of the first and last array elements (source and destination identifying address) will hold the source and destination UDP or TCP port number of the received packet. The sin6_port field of the intermediate elements of the array will be zero. The address buffer returned to the application in the recvfrom() or accept() functions when the IP_RCVSRCRT option is enabled is shown below: draft-ietf-ipv6-bsd-api-00.txt [Page 12] INTERNET-DRAFT IPv6 BSD API Spec October 1994 +--------------------+ | | | sockaddr_in6[0] | Source Identifying Address | | +--------------------+ | | | sockaddr_in6[1] | First Source-Route Hop Address | | +--------------------+ . . . . . . +--------------------+ | | | sockaddr_in6[N-1] | Last Source-Route Hop Address | | +--------------------+ | | | sockaddr_in6[N] | Destination Identifying Address | | +--------------------+ Address buffer when receiving a source route 4.9. Sending and Receiving Multicast Packets IPv6 applications may send UDP multicast packets by simply specifying an IPv6 multicast address in the address argument of the sendto() function. A few setsockopt options at the IPPROTO_IP layer are used to control some of the parameters of sending multicast packets. These options are optional: applications may send multicast packets without using these options. The setsockopt() options for controlling the sending of multicast packets are summarized below: IP_MULTICAST_IF Set the interface to use for outgoing multicast packets. IP_MULTICAST_TTL Set the hop count to use for outgoing multicast packets. (Note a separate option - IP_TTL - is provided to set the hop count to use for outgoing unicast packets.) IP_MULTICAST_LOOP Controls whether outgoing multicast packets sent should be delivered back to the local application. A toggle. draft-ietf-ipv6-bsd-api-00.txt [Page 13] INTERNET-DRAFT IPv6 BSD API Spec October 1994 The reception of multicast packets is controlled by the two setsockopt() options summarized below: IP_ADD_MEMBERSHIP Join a multicast group. Requests that multicast packets sent to a particular multicast address be delivered to this socket. IP_DROP_MEMBERSHIP Leave a multicast group. Requests that multicast packets sent to a particular multicast address no longer be delivered to this socket. Additional details of multicast part of the API will be added later. 4.10. Name-to-Address Translation Functions We have defined two new functions analogous to gethostbyname() and gethostbyaddr() which support addresses in both the IPv4 and IPv6 address families. The names of the new functions are hostname2addr() and addr2hostname(). These functions were designed to have semantics similar to gethostbyname() and gethostbyaddr(), so that existing IPv4 applications can be easily ported to IPv6. Hostname2addr() is defined similarly to gethostbyname(), but enables applications to specify the type of address to be looked up: struct hostent *hostname2addr(const char *name, int af); This new function looks up the given name in the name service and returns the completed hostent structure if the lookup succeeds, and NULL otherwise. The name argument is the domain name of the host to look up. The af argument specifies the type of the address -- IPv4 (AF_INET) or IPv6 (AF_INET6) -- to return to the caller in the h_addr_list field of the hostent structure. If the af argument is AF_INET, hostname2addr() queries the name service for IPv4 addresses and, if any are found, returns a hostent structure that includes an array of IPv4 addresses. Each IPv4 address is encoded in network byte order. If the af argument is AF_INET6, the processing is as follows: the hostname2addr() function first queries the name service for IPv6 addresses. If IPv6 addresses are found, they are returned in an array in the hostent structure. If no IPv6 addresses are found, the function queries the name service for IPv4 addresses. If IPv4 addresses are found, they are returned as 128-bit IPv6 addresses by prepending the 96-bit all-zeros prefix that indicates the address is for an IP-only draft-ietf-ipv6-bsd-api-00.txt [Page 14] INTERNET-DRAFT IPv6 BSD API Spec October 1994 host[2]. As in IPv4, each IPv6 address returned in struct hostent is encoded in network byte order. The second new function, called addr2hostname(), is defined in exactly the same way as the gethostbyaddr() function, except that it now supports both the IPv4 and IPv6 address families: struct hostent *addr2hostname(const void *addr, int len, int af); addr2hostname() performs an inverse lookup in the name service on the address specified, returning a completed hostent structure if the lookup succeeds, or NULL, if the lookup fails. This function supports both the AF_INET and AF_INET6 address families. If the af argument is AF_INET, then len must be specified to be 4 octets and addr must refer to an IPv4 address. If af is AF_INET6, then len must be specified as 16 octets and addr must refer to an IPv6 address. If the addr argument is an IPv4 address in IPv6 form (the high-order 96-bit prefix indicates this[2]), addr2hostname() performs an inverse lookup on the low-order 32 bits of the address only. A new name-to-address translation library function is now under development at Berkeley [4]. This new function, named getconninfo(), will subsume the functionality of gethostbyname(), hostname2addr(), as well as the getservbyname() and getservbyport() functions. The new function is specifically designed to be "transport independent", so it can be used by IPv6 applications. System implementations should provide the addr2hostname() and hostname2addr() functions in order to simplify the porting of existing IPv4 applications to IPv6. System implementations may also provide the getconninfo() function, once it is defined, so that newly written applications can be transport independent. The getconninfo() function is expected to be published as a separate specification document, not included in this spec. Implementations must retain the BSD gethostbyname() and gethostbyaddr() functions in order to provide source and binary compatibility for existing applications. 4.11. Address Conversion Functions BSD Unix provides two functions, inet_addr() and inet_ntoa(), to convert an IPv4 address between binary and printable form. IPv6 applications need similar functions. We have defined the following two functions to convert both IPv6 and IPv4 addresses: draft-ietf-ipv6-bsd-api-00.txt [Page 15] INTERNET-DRAFT IPv6 BSD API Spec October 1994 int ascii2addr(int af, const char *cp, void *ap); and char *addr2ascii(int af, const void *ap, char *cp); The first function converts an ascii string to an address in the address family specified by the af argument. Currently AF_INET and AF_INET6 address families are supported. The cp argument points to the ascii string being passed in. The ap argument points to a buffer that is to be used by the function to return the address. Ascii2addr() returns the length of the address in octets if the conversion succeeds, and -1 otherwise. The function does not modify the storage pointed to by ap if the conversion fails. The application must ensure that the buffer referred to by ap is large enough to hold the converted address. If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted decimal form: ddd.ddd.ddd.ddd where ddd is a one to three digit decimal number between 0 and 255. If the af argument is AF_INET6, then the function accepts a string in one of the two standard IPv6 printing forms[2]: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ddd.ddd.ddd.ddd or xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx where xxxx is a 1 to 4 digit hex value and ddd is a 1 to 3 digit decimal number between 0 and 255. The second function converts an address into a printable string. The af argument specifies the form of the address. This can be AF_INET or AF_INET6. The ap argument points to a buffer holding an IPv4 address if the af argument is AF_INET, and an IPv6 address if the af argument is AF_INET6. The cp argument points to a buffer that the function can use to store the ascii string. If the cp argument is NULL, the function uses its own private static buffer. If the application specifies a cp argument, it must be large enough to hold the ascii conversion of the address specified as an argument, including the terminating null byte. For IPv6 addresses, the buffer must be at least 40 bytes. For IPv4 addresses, the buffer must be at least 16 bytes. The addr2ascii() function returns a pointer to the buffer containing the draft-ietf-ipv6-bsd-api-00.txt [Page 16] INTERNET-DRAFT IPv6 BSD API Spec October 1994 ascii string if the conversion succeeds, and NULL otherwise. The function does not modify the storage pointed to by buf if the conversion fails. 5. Security Considerations Security issues are not discussed in this document. 6. Open Issues A few open issues for IPv6 socket interface API spec remain, including: - The multicast API needs to be flushed out some more. - Security. Should we do anything to support the security options? If so, what? - What should the system do if the application has enabled the IP_RCVSRCRT option, but the size of the buffer passed in to recvfrom() or accept() is not large enough to hold the full source route? The options include: fail the call; omit the "intermediate hops" but include both source and destination addresses; omit all addresses except the source. - 4.4 BSD sa_len compatibility. We need to write a section about how the sockaddr_in6 can be used on systems based on 4.4 BSD that include the sa_len field in the sockaddr struct. Acknowledgments Thanks to the many people who made suggestions and provided feedback to earlier revisions of this document. Comments were provided by: Richard Stevens, Dan McDonnald, Christian Huitema, Steve Deering, Andrew Cherenson, Charles Lynn, Ran Atkinson, Erik Nordmark, Glenn Trewitt, Fred Baker, Robert Elz, and Dean D. Throop. Craig Partridge suggested the addr2ascii() and ascii2addr() functions. Ramesh Govindan made a number of contributions and co-authored an earlier version of this paper. References [1] S. Deering, "IPv6 Protocol Specification", Internet Draft in progress. draft-ietf-ipv6-bsd-api-00.txt [Page 17] INTERNET-DRAFT IPv6 BSD API Spec October 1994 [2] S. Deering, P. Francis and R. Govindan, "IPv6 Routing and Addressing Overview", Internet Draft in progress. [3] R. Gilligan, "Simple IPv6 Transition (SIT) Overview", Internet Draft in progress. [4] K. Sklower, Private communication. Authors' Address Jim Bound Digital Equipment Corporation 110 Spitbrook Road ZK3-3/U14 Nashua, NH 03062-2698 Phone: +1 603 881 0400 Email: bound@zk3.dec.com Susan Thomson Bell Communications Research MRE 2P-343, 445 South Street Morristown, NJ 07960 Telephone: +1 201 829 4514 Email: set@thumper.bellcore.com Robert E. Gilligan Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop UMTV05-44 Mountain View, CA 94043-1100 Phone: +1 415 336 1012 Email: bob.gilligan@eng.sun.com draft-ietf-ipv6-bsd-api-00.txt [Page 18] ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 19:44:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06644; Wed, 5 Oct 94 19:44:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06638; Wed, 5 Oct 94 19:44:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09048; Wed, 5 Oct 94 19:40:46 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA25650; Wed, 5 Oct 94 19:40:17 PDT Subject: Re: (IPng) New IPv6 socket interface API spec To: ipng@sunroof.Eng.Sun.COM Date: Wed, 5 Oct 1994 22:40:16 -0500 (EST) From: Dan McDonald In-Reply-To: <9410052315.AA14340@kandinsky.Eng.Sun.COM> from "Bob Gilligan" at Oct 5, 94 04:15:20 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 107 Message-Id: <9410060340.aa08562@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'll be commenting on this more tomorrow, or at Boston. One thing, there's one 'n' in McDonald. :-P Dan ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 5 22:14:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06688; Wed, 5 Oct 94 22:14:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06682; Wed, 5 Oct 94 22:14:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19685; Wed, 5 Oct 94 22:10:50 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA21910; Wed, 5 Oct 94 22:10:28 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA22777; Wed, 5 Oct 94 22:08:29 -0700 Received: by xirtlu.zk3.dec.com; id AA04496; Thu, 6 Oct 1994 01:08:07 -0400 Message-Id: <9410060508.AA04496@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Fall Foilage in New England if your coming ... Date: Thu, 06 Oct 94 01:08:01 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM If your coming to the implementors meeting and want to see the Fall Foilage, figured I should send this out. Up North in New Hampshire is the best. There will be lots of people up North in New Hampshire its peaking in the White Mountains, but its worth it. There are also various October Festivals happening (good beer and food) up there too and Globe Newspaper or the Hotel should have where and when this weekend. >From Boston get to 93 North. You can get directions to 93 North from the Hotel. You can ask them for a Map too but you will be able to find that up North too at Info Centers. Stay on 93 North all the way to New Hampshire and to the White Mountains (this is pretty simple). Here are two options. In about 3 hours (driving about 65 avg - you can pick up speed in NH). You will see an exit for Lincoln Rt 112 known also as the Kancamagus Highway. Its very scenic and the only road through the White Mountains at that point. The White Mountains have entries and exits via Notches this is one of them and also Rt 112. Its very nice and the Swift River runs along the Highway and there are many places to stop and take pictures or a hike up a trail. You can stop at an INFO CENTER in Lincoln the town before entering the Kancamagus Highway (notch). This will take you to Rt 16 and you can go into Conway which has outlets but nothing you could not find in other outdoor stores. You can either take Rt 16 to Rt 302 towards the other part of the White Mountains or just go back out the Kancamagus. You need to have a map as you can see this will be clearer. See next directions for complete circle (you will see what I mean by this after seeing the next directions). The other option is to pass that exit on 93 North and take the exit which will say Franconia Notch. This exit has the best Information Center in the White Mountains and you will see a sign. Get maps of the various sites. Then head back on the road and get to Rt 3 to Rt 302. Take Rt 302 through the White Mountains which will bring you to Rt 16 and Conway and to the Kancamagus (Rt 112) and your back at where I stopped the directions above. These are the best two options and I think the second is the best. You can ask at the Franconia Notch Information Center about Hiking Trails. Clearly a whole day trip and different than other ranges in the U.S. Certainly not as grand as the Rockies or as Mystique as the Sierras but they are worth seeing. The colors will be good this weekend and you should get Sun. Right now from the Satellite I just checked on my cable and extended forecast, you should have a good days on Friday and Saturday, and potentially Sunday too. I would wear something that will break the wind and have a hat and pair of gloves in my sack. In the day it will not get above 55 F and at night it could go down to 35 F. On coming back to Boston just stay on 93 South. take care, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 01:12:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06740; Thu, 6 Oct 94 01:12:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06734; Thu, 6 Oct 94 01:12:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00549; Thu, 6 Oct 94 01:09:04 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA23860; Thu, 6 Oct 94 01:08:43 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA28191; Thu, 6 Oct 1994 01:08:41 -0700 Date: Thu, 6 Oct 1994 01:08:41 -0700 From: Tony Li Message-Id: <199410060808.BAA28191@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Wed, 05 Oct 1994 10:43:56 -0400 <9410051443.AA04967@snark.imsi.com> Subject: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, Now, this is grossly imperfect for all sorts of reasons -- it only does you good on a broadcast network, it burdens the routers, etc. My point is, however, that this is a pretty significant incremental improvement in failover. Compared to what? To RIP, sure. But what you describe is basically router discovery and that works today. Well within your 15s limit, BTW. The IPv6 model as its being discussed currently doesn't seem to be sufficiently flexible to support such things in the long term. In particular, it seems end hosts are being expected simply to find out about black holes from (fairly long) timeouts rather than by some sort of active mechanism. You can't ever learn about black holes by an active mechanism (that I know of). You learn about them because things just don't come back. That implies a timer. The timer needs to be at least 3X the normal response time. Even the routing protocols (OSPF, ISIS, EIGRP, etc...) discover dead routers using a timeout of HELLO packets. Now if you want to move to timeouts of much less than a second, it implies that we have to get the normal response time way down (i.e., faster silicon, more care in programming) and that the packet format has to allow for sub-second granularity. I believe that we're actually headed down a path that will give you all of the functionality that you need. I think that your continuing assumptions about timeouts are coloring your view. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 11:23:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07008; Thu, 6 Oct 94 11:23:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07002; Thu, 6 Oct 94 11:23:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03676; Thu, 6 Oct 94 11:19:32 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA29728; Thu, 6 Oct 94 11:17:00 PDT Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA24322; Thu, 6 Oct 1994 12:19:14 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA15274; Thu, 6 Oct 1994 12:19:10 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA03083; Thu, 6 Oct 1994 11:55:49 -0400 Message-Id: <9410061555.AA03083@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Fall Foilage in New England if your coming ... In-Reply-To: Your message of "Thu, 06 Oct 94 01:08:01 EDT." <9410060508.AA04496@xirtlu.zk3.dec.com> Date: Thu, 06 Oct 94 11:55:49 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM If your coming to the implementors meeting and want to see the Fall Foilage, figured I should send this out. There is certainly a lot more, and not far away. Not far away from Lincoln - about 30 minutes of driving North on the I-93 highway - is the Cannon Mountain Tramway, and Scenic View. Cannon Mt is quite spectacular, and is one of the NH favorite places for alpinism. The Tramway has a capacity of 20-30 people (if not more) and takes you to the top in 5-10 minutes, from where the view over New England can be quite impresive in a clear sky day, which in the fall is generally the norm. Near the departure station, there is a Museum where you can see one of the first Tramways built on the East Coast around 1938, if I am not mistaken. >From Conway, about 30 minutes of driving North is Mt Washington, which is the tallest peak in North New England - a Cog Train, and a road can bring you to the top. In a clear day, the view is the entire North New England, and those with eagle eyes can see Boston (-:. Note that is also the cold pole of North East United States. Also from Conway, about 30 minutes of driving North-West is Bretton Woods, a very nice resort, with a lot of tradition and history, and whith a splendid view to the White Mountains. The resort is somewhat significant to the world we are in, since it is the place where immediately after WW II, an international conference of finance and economy ministers decided to base the structure of the world's financial and trade system on the American $. Note: All information centers on I-93, have free maps and brochures of New Hampshire. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 11:23:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07015; Thu, 6 Oct 94 11:23:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07009; Thu, 6 Oct 94 11:23:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03744; Thu, 6 Oct 94 11:19:53 PDT Received: from BBN.COM ([128.89.0.122]) by Sun.COM (sun-barr.Sun.COM) id AA29920; Thu, 6 Oct 94 11:18:57 PDT Message-Id: <9410061818.AA29920@Sun.COM> From: John Day Subject: Re: (IPng) Fall Foilage in New England if your coming ... To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9410060508.AA04496@xirtlu.zk3.dec.com> Date: Thu, 6 Oct 94 12:44:17 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >If your coming to the implementors meeting and want to see the Fall >Foilage, figured I should send this out. > Relating to this and although it is a little late. There was a notice yesterday internal to BBN that because of fall foliage, various university events, and conventions hotel space is at a premium in Boston for the month of October. But then we all plan ahead and made hotel reservations weeks ago. Right. Take care John ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 11:43:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07047; Thu, 6 Oct 94 11:43:01 PDT Received: from damrak.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07041; Thu, 6 Oct 94 11:42:50 PDT Received: from damrak (localhost) by damrak.Eng.Sun.COM (5.x/SMI-SVR4) id AA14730; Thu, 6 Oct 1994 11:37:40 -0700 Message-Id: <9410061837.AA14730@damrak.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) The death of the 'ip-ng' nickname... (list administrivia) Date: Thu, 06 Oct 1994 11:37:39 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Currently 'ip-ng' is an alias to 'ipng'. Since people seem to mistakenly keep posting to both addresses, causing everyone mailbox bloat, we will drop the 'ip-ng' alias. Use only ipng@sunroof.eng.sun.com for submission to the list. People who mistaknely post to the "old" address will receive a mailer error instead. If you have comments about this change, or other administrivia send it to ipng-approval@sunroof.eng.sun.com. Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 11:54:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07126; Thu, 6 Oct 94 11:54:30 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07119; Thu, 6 Oct 94 11:54:15 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA17215; Thu, 6 Oct 1994 11:50:40 -0700 Date: Thu, 6 Oct 1994 11:50:40 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410061850.LAA17215@jurassic.Eng.Sun.COM> To: ipng@sunroof Cc: hinden@jurassic Subject: (IPng) New IPng Overview Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IPng-ers, I just posted an IPng Overview document to be an internet draft. Until it is installed in the internet draft directories it can be found by anonymously ftping to playground.sun.com it is in pub/hinden/ipng-overview.out Bob ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 15:50:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07642; Thu, 6 Oct 94 15:50:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07636; Thu, 6 Oct 94 15:50:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09868; Thu, 6 Oct 94 15:46:34 PDT Received: from newsun.Novell.COM by Sun.COM (sun-barr.Sun.COM) id AA21423; Thu, 6 Oct 94 15:46:11 PDT Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA08158; Thu, 6 Oct 94 15:46:09 PDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA19479; Thu, 6 Oct 94 15:46:06 PDT From: Tae_Kyong_Song@Novell.COM (Tae Kyong Song) Message-Id: <9410062246.AA19479@na.SJF.Novell.COM> Subject: Re: (IPng) New IPv6 socket interface API spec To: ipng@sunroof.Eng.Sun.COM Date: Thu, 6 Oct 1994 15:46:05 -0700 (PDT) In-Reply-To: <9410052315.AA14340@kandinsky.Eng.Sun.COM> from "Bob Gilligan" at Oct 5, 94 04:15:20 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 551 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hey bob, I have a question for you. > struct hostent *hostname2addr(const char *name, int af); > When user specifies the name for an address, how would you know if it is for AF_INET or AF_IN6 ? It seems that the application will have to call hostname2addr twice, for both AF_INET and AF_IN6. And, if the name is found in AF_INET domain, then it would end up returning ipv4 address even if the same name is defined in AF_IN6 domain. (ie, the value is dependent on the search order.) What do you think of that ? Tae. tae@novell.com ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 16:25:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07706; Thu, 6 Oct 94 16:25:02 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07700; Thu, 6 Oct 94 16:24:55 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id QAA01292; Thu, 6 Oct 1994 16:21:25 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA16775; Thu, 6 Oct 1994 16:21:50 +0800 Date: Thu, 6 Oct 1994 16:21:50 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9410062321.AA16775@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: Re: (IPng) New IPv6 socket interface API spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Hey bob, > I have a question for you. > > > struct hostent *hostname2addr(const char *name, int af); > > > > When user specifies the name for an address, how would you know if > it is for AF_INET or AF_IN6 ? It seems that the application will have > to call hostname2addr twice, for both AF_INET and AF_IN6. And, if the > name is found in AF_INET domain, then it would end up returning ipv4 > address even if the same name is defined in AF_IN6 domain. (ie, the > value is dependent on the search order.) What do you think of that ? New applications should use AF_INET6, not AF_INET. As the spec says, this causes the system to search the DNS for both IPv6 address records and IPv4 address records: > If the af argument is AF_INET6, the processing is as follows: the > hostname2addr() function first queries the name service for IPv6 > addresses. If IPv6 addresses are found, they are returned in an array in > the hostent structure. If no IPv6 addresses are found, the function > queries the name service for IPv4 addresses. If IPv4 addresses are > found, they are returned as 128-bit IPv6 addresses by prepending the > 96-bit all-zeros prefix that indicates the address is for an IP-only > host[2]. As in IPv4, each IPv6 address returned in struct hostent is > encoded in network byte order. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 16:38:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07727; Thu, 6 Oct 94 16:38:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07721; Thu, 6 Oct 94 16:38:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16133; Thu, 6 Oct 94 16:34:55 PDT Received: from databus.databus.com by Sun.COM (sun-barr.Sun.COM) id AA28967; Thu, 6 Oct 94 16:33:25 PDT Date: Thu, 6 Oct 94 19:30 EDT Message-Id: <9410061932.AA17057@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery Content-Length: 1806 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Wed, 05 Oct 1994 10:43:56 -0400 > From: "Perry E. Metzger" > > Let me propose a strawman. There are thirty or fourty things wrong > with it; just look at the principles. > > Imagine you have a bunch of hosts on a broadcast type lan with two > routers providing exit to the outside world. In a fairly heavy traffic > situation the routers should be sending packets most of the time. Now, > if each router keeps a deadman timer that goes off if it doesn't see > traffic at least every 10 seconds from the other router put out onto > the lan, and then proceeds to try to ping the other router if it seems > it might be down because the timer expired (routers run special > operating systems and can produce far better guarantees about whether > they will respond) and then declares the other router down by some > multicast protocol on the segment if it doesn't reply, we now have the > ability to to route around a problem within fifteen or twenty seconds > at most -- a real improvement! (I suggest the routers monitoring each > other because their specialized hardware can be rigged to do this sort > of thing cheaply where normal hosts would have to go promiscuous and > it could get rather ugly.) I think the principle is wrong. Why should I trust one router to tell me that another router is down? Aside from security issues, what about the chance that it's the router's receive leg which has failed, and the other router isn't really down? If a host needs second-scale switch-over, it needs to keep its own "last heard from" timers, and make its own decision. And if that means a few-second arp timeout, or rip timeout, so what, in that sort of environment? The "wasted" packets won't get off the wire, so are not a scaling problem. Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 6 22:25:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07972; Thu, 6 Oct 94 22:25:28 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07966; Thu, 6 Oct 94 22:25:12 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id WAA12516; Thu, 6 Oct 1994 22:21:40 -0700 Date: Thu, 6 Oct 1994 22:21:40 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410070521.WAA12516@jurassic.Eng.Sun.COM> To: ipng@sunroof Cc: hinden@jurassic Subject: (IPng) New IPng Specification Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IPng-ers, I just posted a new IPng specification document to be an internet draft. Until it is installed in the internet draft directories it can be found by anonymously ftping to playground.sun.com it is in pub/hinden/ipng-spec-00.out Bob ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 7 04:13:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08140; Fri, 7 Oct 94 04:13:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08134; Fri, 7 Oct 94 04:13:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06341; Fri, 7 Oct 94 04:09:44 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA23255; Fri, 7 Oct 94 04:09:20 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 7 Oct 1994 12:08:32 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Fri, 7 Oct 1994 11:12:12 +0100 Date: Fri, 7 Oct 1994 11:12:12 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003861] X400-Content-Type: P2-1984 (2) Content-Identifier: 3861 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3861*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Input from Alan Lloyd Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Just in case this didn't get posted. Jack ------------------------------ Start of forwarded message 1 Delivery-Date: Fri, 7 Oct 1994 03:05:48 +0100 X400-Content-Type: P2-1984 (2) X400-Originator: /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net Original-Encoded-Information-Types: ia5 text (2) X400-Recipients: j.houldsworth@ste0906.wins.icl.co.uk Date: Fri, 7 Oct 1994 02:00:20 +0100 From: /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net Message-ID: <"940923 07:26:12*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: j.houldsworth@ste0906.wins.icl.co.uk (Non Receipt Notification Requested), "X400@MIS@DCPMEL[C=AU;ADMD=TELEMEMO;PRMD=OZ.AU;O=AARN;D.RFC-822*OWNER-IPNG(A)SUNROOF2.ENG.SUN.COM;]":; (Non Receipt Notification Requested) Cc: "X400@MIS@DCPMEL[C=GB;A=GOLD 400;P=ICL;O=ICL;OU1=STE0906;I=J;S=HOULDSWORTH;]":; (Non Receipt Notification Requested), "X400@MIS@DCPMEL[C=AU;A=TELEMEMO;P=DATACRAFT;O=SMTP;S=IPNG(A)SUNROOF.ENG.SUN.COM;]":; (Non Receipt Notification Requested) Subject: RE: (IPNG) RE NSAP MAPS Forwarded to: x400@mis@dcpmel[c=gb;a=gold 400;p=icl;o=icl;ou1=ste0906;i=j;s=houldsworth;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: jack.. some other input already sent.. I seem to be ignored.. Where are we at? Regards -------------------------- [Original Message] ------------------------- gday.. scott, jack, everyone.. NSAPs I believe should be hop by hop because by making them end by end imposes the primary capability of the router to IP6 addressing.. I realise this could be the preference for IETF but the ability to build routers that do both addressing schemes in a balanced way (and also that of IPX) would make the products more universal.. The other point on this is that NSAPs must have a length field applied within their carriage method and some of the other proposals seem to have missed this off.. The next point is that having a distinct addressing extension option... seems to be strange when hop by hop was put there (i assume) for this very reason.. We seem to have hop by hop with no defined reasons (except padding) AND now we are defining options as distinct headers???! If it is violently resisted that other address forms use Hop by Hop then it is just as easy for routers to extract NSAPs from End by End... However.. the semantics of the option is violated... AND product suppliers can always give profiles to the options they support.. NSAPs or otherwise... I have copied this back to ipng list because I do seem to be getting posts through... I have already responed to this one..(sorry if it comes twice) (Our (Australias) brisbane gateway to the internet is suffering from melanomas (i think) some times it puts other mail fields into the addresses) Regards Alan@Oz ------------------------------ End of forwarded message 1 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 7 10:27:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08243; Fri, 7 Oct 94 10:27:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08236; Fri, 7 Oct 94 10:27:46 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04017; Fri, 7 Oct 94 10:24:14 PDT Received: from newsun.Novell.COM by Sun.COM (sun-barr.Sun.COM) id AA17652; Fri, 7 Oct 94 10:23:46 PDT Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA12861; Fri, 7 Oct 94 10:23:28 PDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA26585; Fri, 7 Oct 94 10:23:26 PDT From: Tae_Kyong_Song@Novell.COM (Tae Kyong Song) Message-Id: <9410071723.AA26585@na.SJF.Novell.COM> Subject: Re: (IPng) New IPv6 socket interface API spec To: ipng@sunroof.Eng.Sun.COM Date: Fri, 7 Oct 1994 10:23:25 -0700 (PDT) In-Reply-To: <9410062321.AA16775@kandinsky.Eng.Sun.COM> from "Bob Gilligan" at Oct 6, 94 04:21:50 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 614 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > New applications should use AF_INET6, not AF_INET. As the spec says, > this causes the system to search the DNS for both IPv6 address records > and IPv4 address records: > Ok thanks. I must've missed it, probably because I was thinking about it for families other than INET6. I was considering possibilty of using the suggested functions in your draft for IPX. But i'm not sure if it is reasonable to search INET names as well. Why was using good old gethostbyname, with h_addrtype returning proper value, unacceptable ? (Except that some old applications assumes AF_INET without checking it..) Tae. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 7 14:46:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08561; Fri, 7 Oct 94 14:46:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08555; Fri, 7 Oct 94 14:46:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28332; Fri, 7 Oct 94 14:43:06 PDT Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA02670; Fri, 7 Oct 94 14:41:45 PDT Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09494; Fri, 7 Oct 94 17:35:08 EDT Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA11458; Fri, 7 Oct 94 17:34:17 EDT Date: Fri, 7 Oct 94 17:34:17 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9410072134.AA11458@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Implementors Meeting Announcement and Logistics Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Well, I had a bit of trouble finding my copy of the directions for next week, so I decided that someone else might also have misplaced them. For your convenience a copy of the original announcement is below. Ross ----- Begin Included Message ----- From owner-ipng@sunroof2.Eng.Sun.COM Fri Sep 2 14:23:50 1994 Date: Fri, 2 Sep 94 13:54:13 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Implementors Meeting Announcement and Logistics Sender: owner-ipng@sunroof.Eng.Sun.COM Reply-To: ipng@sunroof.Eng.Sun.COM Content-Length: 8544 The IPng working group will hold an implementors meeting, hosted by Digital Equipment Corporation, from October 10-12. The implementation discussion will include the base IPv6 protocol, and also transition and autoconfiguration details. The particulars are: IPng Implementors meeting 9:00am Mon. Oct. 10 through 12:00 noon Wed Oct. 12. DEC, Cambridge Research Lab One Kendall Square Building 700, Second Floor Cambridge, MA 02139 Attendees should be WG chairs, document authors, or engineers who are, or will be building IPv6 products. Notes from the meeting will be published expeditiously. Please let Jim Bound (bound@zk3.dec.com) know if you are planning on attending (so that he can know how large a group to plan for). In order to keep attendance to a reasonable size, we are asking companies/organizations to limit their attendance to 3 engineers. (and no lawyers ;-). Ross --------------------------------------------------------------- A friendly warning to anyone planning to fly in and rent a car. Rush hour traffic leaving the airport can be legendary. Cab drivers are able to bypass most of this traffic and the subway works well (well OK, it works well enough) and stops very near the hotel. Logistics: IPng Implementors Meeting October 10-12. Please RSVP to Jim Bound bound@zk3.dec.com unless you already have done so. Meeting will end on October 12th at Noon. Hotel: Cambridge Marriot (617) 494-6600 Rate is $149.00 Standard. You can take a cab from Logan Airport for about $15.00. Location: Cambridge Research Lab Digital Equipment Corporation One Kendall Square Building 700, Second Floor Cambridge, MA 02139 The meeting will be held in the Sahara Conference Room. DIRECTIONS to: Digital Equipment Corporation ========== CAMBRIDGE RESEARCH LAB One Kendall Square, Building 700 Cambridge, Massachusetts 02139 Telephone: (617) 621-6600 Please be warned that the One Kendall Square complex is NOT in Kendall Square proper. One Kendall Square is a cluster of buildings located on the NORTH side of Technology Square at the JUNCTION of Hampshire Street and Broadway. WALKING Directions FROM Binney Street ======================================= 1. Cross back over Binney Street. Use walkway between Bank of New England [LEFT] and Building 1400 [RIGHT] into One Kendall Square complex. Enter Building 700 on your RIGHT. 2. Walk through Atrium to elevators and go up to 2nd floor. [CRL is UP TO your RIGHT as you ENTER atrium] WALKING directions FROM Hampshire Street ========================================== 1. Walk through MAIN courtyard of One Kendall Square, bear RIGHT up a set of stairs and around Building 200. A clothing store is on your immediate LEFT. 2. Enter doorway to LEFT of Quantum Books, go STRAIGHT down hall through another set of doors and into the five-story atrium, [lobby of Building 700]. 3. FOLLOW "Binney Street" step [2] above. WALKING directions FROM MBTA (Subway stop) ============================================ 1. Take the Red Line to Kendall Square Stop (MIT). 2. At street level, you will see the MIT Coop. 3. Facing the Coop, turn LEFT and walk to end of block. 4. Turn RIGHT (at Legal Seafoods). Walk one block and turn LEFT onto Broadway (toward Cambridge, not Boston). 5. Walk down Broadway. Cross railroad tracks. Walk underneath Draper Lab's pedestrian bridge. 6. When street splits, bear RIGHT onto Hampshire Street and into One Kendall Square Complex. 7. FOLLOW "Hampshire Street" directions. WALKING directions FROM Kendall Square Mariott ================================================ 1. Exit hotel onto Broadway and cross street. 2. Walk down Broadway (towards Cambridge, not Boston). Cross railroad tracks. Walk underneath Draper Lab's pedestrian bridge. 3. When street splits, bear RIGHT onto Hampshire Street and walk into One Kendall Square Complex. 4. FOLLOW "Hampshire Street" directions. Directions by car from ROUTE 2 ================================ 1. Follow Route 2 to Fresh Pond Parkway, Fresh Pond Parkway south to Memorial Drive, and Memorial Drive to the Hyatt Regency Hotel. 2. FOLLOW step [3] of "Directions from MASSACHUSETTS TURNPIKE". Directions by car from the MASSACHUSETTS TURNPIKE ================================================= If you are coming from the WEST on MASS PIKE ============================================== 1a. Exit the Mass Pike at Exit 18, Allston-Cambridge (LEFT exit) and take RIGHT fork to Cambridge. FOLLOW step [2] below. If you are coming from the EAST on MASS PIKE ============================================== 1b. Exit the Mass Pike at Exit 20, Allston-Cambridge , and take RIGHT fork to Cambridge. 2. Go straight, over bridge, and TURN RIGHT (immediately) at traffic light at FAR side of the bridge, onto Memorial Drive. 3. Stay in LEFT lane, and follow Memorial Drive (taking overpass) to first traffic light (JUST after the Hyatt Regency Hotel). 4. Turn LEFT at that light. 5. At end of block (a T-end), turn RIGHT onto Vassar Street. 6. Follow Vassar Street. At first light, cross Massachusetts Avenue. At second light cross Main Street, bearing LEFT. The third light is one block later. 7. At third light, turn LEFT onto Broadway. 8. Proceed across railroad tracks. 9. At fork of Broadway and Hampshire, stay to RIGHT. At first light take a RIGHT onto Cardinal Mederios. Take first RIGHT onto Binney Street. 10. PARKING - Binney Street Garage Directions by car from ROUTE 3 ================================ 1. Take Route 3 to Route 128 South to Route 2 East. FOLLOW ROUTE 2 directions . Alternate directions by car from ROUTE 3 ========================================== 1. Take Route 3 to Route 128 North to I-93 South. 2. Get off I-93 at Sullivan Square exit. Follow signs to Boston. This entails a sort of roller coaster getting off and on about three ramps. 3. Keep following "Boston" signs until you see Bunker Hill Community College on your RIGHT and first sign for Cambridge. Follow sign (i.e., turn RIGHT). This road becomes Commercial Avenue in Cambridge within a block. 4. Follow Commercial until it runs into Memorial Drive at a lift bridge. This is THE first RIGHT that is NOT at a traffic signal. Take RIGHT, which puts you onto Broadway. 5. Follow Broadway for three traffic lights and take RIGHT fork immediately past train tracks. 6. Please refer to "Directions from MASSACHUSETTS TURNPIKE", FOLLOW STEP [8] Directions by car from LOGAN AIRPORT ====================================== 1. Follow street signs to Mass Pike, and FOLLOW the MASSACHUSETTS TURNPIKE directions. Alternate directions from LOGAN AIRPORT ========================================= 1. Take Sumner Tunnel into Boston. Stay in LEFT lane. 2. As you exit tunnel, keep LEFT and go up entrance ramp to Central Artery. 3. Get into RIGHT lane and take 2nd exit to Storrow Drive. 4. Get into LEFT lane and stay LEFT. (This all happens quite fast!) 5. Go through a short tunnel, take LEFT exit ( sign says Government Center). 6. After exit take an immediate RIGHT onto Longfellow Bridge. 7. Come straight off bridge and down Broadway (through Kendall Square proper). 8. FOLLOW step [7] of "Directions from MASSACHUSETTS TURNPIKE". THE BINNEY STREET PARKING GARAGE ================================ PLEASE NOTE: If Parking Ticket is lost you will pay $14. If your ticket is not STAMPED by Digital, 0-1 hrs will cost $2.00. So don't forget to bring it with you!! RATES: 1 hour free with stamp by CRL 1-2 hrs $2.00; $1.00 for each additional hr; $7.00 max. HOURS: 6:00 a.m.-12:00 Midnight. CROSS BACK over Binney Street. Use walkway between Genzyme Bldg. [LEFT] and Building 1400 [RIGHT] into One Kendall Square complex. Enter Building 700, which is the 2nd building on your RIGHT. WALK THROUGH Atrium to elevators and go up to 2nd floor. [CRL is up to your RIGHT as you enter atrium] ----------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 8 14:01:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00277; Sat, 8 Oct 94 14:01:08 PDT Received: from damrak.eng.sun.com by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00271; Sat, 8 Oct 94 14:00:57 PDT Received: from damrak (localhost) by damrak.eng.sun.com (5.x/SMI-SVR4) id AA00316; Sat, 8 Oct 1994 13:55:43 -0700 Message-Id: <9410082055.AA00316@damrak.eng.sun.com> To: ipng@sunroof Subject: [Forwarded] Re: (IPng) Discovery Date: Sat, 08 Oct 1994 13:55:43 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM /* * List manager's note: This message, and three subsequent messages, were * delayed. They were bounced due to a server problem. I believe I have * prevented such a failure from happening again. I do not have a good * way of forwarding bounce messages of this sort, so please note these * headers are not "normal" * Sorry, * ~sparker */ ------- Forwarded Message Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00192; Sat, 8 Oct 94 12:16:45 PDT Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA26525; Sat, 8 Oct 94 14:12:47 CDT Date: Sat, 8 Oct 94 14:12:47 CDT Message-Id: <9410081912.AA26525@achilles.ctd.anl.gov> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery From: "Richard Carlson" Jim; >> IMHO, good vendors >>also won't ever automatically turn a host into a router with boot-time >>shell scripts (as DEC, Sun, SGI, and HP currently appear to do :-). >In fact I have never worked on a UNIX Host that booted as a router >unless some network admin person configured it that way and then I got >the machine to do some testing (which has only happened once). I'd say you never had the pleasure of working with Solaris .-) This is a fragment of the startup scripts Sun ships with with Solaris (after we have modified them). - ---------------------------- if [ -z "$defroute" ]; then # # Determine how many active interfaces there are and how many pt-pt # interfaces. Act as a router if there are more than 2 interfaces # (including the loopback interface) or one or more point-point # interface. Also act as a router if /etc/gateways exists. # # NO WAY NO HOW L. Winkler 7/12/94 #numifs=`ifconfig -au | grep inet | wc -l` #numptptifs=`ifconfig -au | grep inet | egrep -e '-->' | wc -l` numifs=0 numptptifs=0 if [ $numifs -gt 2 -o $numptptifs -gt 0 -o -f /etc/gateways ]; then # Machine is a router: turn on ip_forwarding, run routed, # and advertise ourselves as a router using router discovery. echo "machine is a router." ndd -set /dev/ip ip_forwarding 1 if [ -f /usr/sbin/in.routed ]; then /usr/sbin/in.routed -s fi if [ -f /usr/sbin/in.rdisc ]; then /usr/sbin/in.rdisc -r fi else # Machine is a host: if router discovery finds a router then # we rely on router discovery. If there are not routers # advertising themselves through router discovery # run routed in space-saving mode. # Turn off ip_forwarding ndd -set /dev/ip ip_forwarding 0 # if [ -f /usr/sbin/in.rdisc ] && /usr/sbin/in.rdisc -s; then # echo "starting router discovery." # elif [ -f /usr/sbin/in.routed ]; then # /usr/sbin/in.routed -q; # echo "starting routing daemon." # fi # # Just start gated in quite mode and ignore everything else.. RAC 8-11-94 if [ -f /etc/gated ]; then /etc/gated fi fi fi - ---------------------------- As shown, by default if there are more than 2 interfaces this node will become a router. That is it will broadcast routing information out it's interfaces onto the local cables. This behaviour should not be turned on automatically. The administrator should be required to manually turn this feature on. My experience with SGI's and RS6000's indicate that not all vendors make this mistake. (I am trying to install an ATM card in an alpha right now so I will see what DEC's OSF does in a little while.) But Sun certainly does and I for one would like to see it stopped. ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 8 14:03:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00289; Sat, 8 Oct 94 14:03:00 PDT Received: from damrak.eng.sun.com by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00283; Sat, 8 Oct 94 14:02:49 PDT Received: from damrak (localhost) by damrak.eng.sun.com (5.x/SMI-SVR4) id AA00335; Sat, 8 Oct 1994 13:57:35 -0700 Message-Id: <9410082057.AA00335@damrak.eng.sun.com> To: ipng@sunroof Subject: (IPng) I spoke too soon... Only one message needed resending. Date: Sat, 08 Oct 1994 13:57:35 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The other three were administrivia. Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 8 18:03:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00343; Sat, 8 Oct 94 18:03:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00337; Sat, 8 Oct 94 18:03:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18433; Sat, 8 Oct 94 18:00:11 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA12868; Sat, 8 Oct 94 17:59:47 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA20384; Sat, 8 Oct 94 20:55:41 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410090055.AA20384@pluto.dss.com> Subject: Re: [Forwarded] Re: (IPng) Discovery To: ipng@sunroof.Eng.Sun.COM Date: Sat, 8 Oct 1994 20:55:40 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9410082055.AA00316@damrak.eng.sun.com> from "Steve Parker" at Oct 8, 94 01:55:43 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3279 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I don't know why SUN and other vendors ship their units to come up by default as routers when there are more than one interface but I would guess the following. 1) SUN units by default listen on a routing protocol so that the workstation user who may know nothing about routing need not configure a default router. 2) Many customers put multiple interfaces on their SUN unit's specifically so they can be used as routers. (A multihomed SUN has historically often been the first router a corporation puts into service.) 3) Many IP implementer's believe that if a packet is received by multihomed hosts at an interface other than the one addressed, this packet should still be forwarded upstack. In many network layer implementations this requires turning on packet forwarding or routing. (The only network implementation which I am familiar to any great extent which took the alternative strict approach was the Prime 50 Series -- not a networking leader. I have read of DG and Xenix implementations which worked like the Prime.) 4) Many standard applications make no provision to select the best outgoing interface on a multihomed host which is not routing. Presumably, in a fully connected network, packets will make it to their destination albeit possibly following a far less than optimal path when the wrong interface on a non-routing multihomed host is chosen. 5) An N-interface multihomed host which does not act as a router may need to be treated as N separate end-hosts. (That approach is the only one which made much sense on the Prime.) Such an approach is administratively more complex. (The Prime also provided separate network layers and routing tables for each interface. In such a design, not running a multihome host as a router is practically forced. The SUN units by way of contrast have but one network layer and one routing table. In such a design running a multihome host as a router is very natural.) 6) The more links and nodes in a network topology, the more surviveable a network is against n cable or n router failures a network is. At one major Prime client, a major financial institution, they built a persistent fault tolerant network by running every SUN host as a multi-interface router. They also bought a huge number of stand-alone routers and configured their network so that preferred paths almost never ran through SUN hosts. From the standpoint of correctly building a fault tolerant network, they were probably incorrect in their design, but all the equipment necessary to build a fault tolerant network correctly does not seem to be available yet. And the network does seem to meet their needs and requirements. There are many reasons to ship a vanilla SUN unit configured to boot as a router when more than 1 interface are present. How to ship such a unit is purely a marketing decision and completely outside the purview of the IETF. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 8 18:27:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00377; Sat, 8 Oct 94 18:27:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00371; Sat, 8 Oct 94 18:27:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18877; Sat, 8 Oct 94 18:23:43 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA13675; Sat, 8 Oct 94 18:23:22 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id SAA18135; Sat, 8 Oct 1994 18:23:16 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 8 Oct 1994 18:23:21 -0700 To: ipng@sunroof.Eng.Sun.COM From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: (IPng) Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, et al, Well, I'm in my usual state of confusion. With the wide range of highly pressing problems to solve, I'd think that re-doing the ARP-realm of mechanisms would be very far from the IPng critical path, indeed. ARP works well. While there might be many ways to do better, problems with ARP have simply not been on the top of major hit lists. autoconfiguration (RARP, DHCP, ...) is another matter, of course. Are you suggesting merging these together? d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 09:17:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00491; Sun, 9 Oct 94 09:17:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00485; Sun, 9 Oct 94 09:17:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01172; Sun, 9 Oct 94 09:14:00 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA13552; Sun, 9 Oct 94 09:13:39 PDT To: dcrocker@mordor.stanford.edu Subject: (IPng) Re: ARP Cc: ipng@sunroof2.Eng.Sun.COM Date: Sun, 9 Oct 94 17:11:08 GMT From: Ran Atkinson Message-Id: <9410091711.aa11034@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, As noted earlier, I like the request/response model of ARP. I have a small number of reasons for preferring an ICMP message format to the existing ARP message format. Really the only window of opportunity to fix or change ARP is during the move to IPv6. Compatibility needs preclude attempts to change ARP at all other times. ARP works OK for 802-style LANs, but not all subnet technologies. We need a more general solution and moving to ICMP messages can help generalise the approach. 1) ARP uses broadcast when it really ought to use a well-known multicast address. By moving to ICMP, we use the IPv6 intra-link all-nodes multicast address. The mapping between that and the appropriate link multicast address is covered automatically as part of the "IP over foo-subnet-technology" specification (these generally exist). If we retain ARP, backwards compatibility will effectively preclude any attempt to move to multicast. ARP storms are not unheard of. Using multicast will clearly help contain and reduce the liklihood of such problems. 2) ARP is difficult to secure. If using ICMP or other upper layer protocols, we can now use IPv6 Authentication Header to authenticate replys in many cases. Since address spoofing is a well-known and widespread real security problem, it seems like we should try to reduce this risk while the opportunity is in front of us. Eastlake & Kaufman have a plausible method for putting signed host keys into the DNS and there is an IETF WG focused on Key Mgmt, so those related issues are being solved. It is the case that some replys are awkward to authenticate, but it is also the case that many replys are easily authenticated IF we use ICMP (or another upper-layer protocol's) messages. I believe in improving security whenever the chance appears rather than waiting for a "silver bullet" perfect solution to appear. 3) ARP for ATM has been a real issue. It might well not be so hard if it were ICMP-based and used intra-link multicast (ATM's multicast is clearly broken and won't scale, but for the intra-link case it seems to work). Other new technologies that aren't 802-like have similar problems. 4) Use of ICMP messages rather than ARP messages can make for cleaner IP implementations inside some systems. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 09:25:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00507; Sun, 9 Oct 94 09:25:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00501; Sun, 9 Oct 94 09:25:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01264; Sun, 9 Oct 94 09:22:02 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA13784; Sun, 9 Oct 94 09:21:41 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24022; Sun, 9 Oct 1994 17:21:39 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13756; Sun, 9 Oct 1994 17:21:38 +0100 Message-Id: <9410091621.AA13756@dxcoms.cern.ch> Subject: ARP (was: Re: (IPng) Discovery) To: ipng@sunroof.Eng.Sun.COM Date: Sun, 9 Oct 1994 17:21:38 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: from "Dave Crocker" at Oct 8, 94 06:23:21 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 879 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >--------- Text sent by Dave Crocker follows: ... > With the wide range of highly pressing problems to solve, I'd think that > re-doing the ARP-realm of mechanisms would be very far from the IPng > critical path, indeed. ARP works well. While there might be many ways to > do better, problems with ARP have simply not been on the top of major hit > lists. OK... those of us whose operational problems are DOMINATED by ARP- related broadcast storms NEED TO SHOUT, clearly. Just my current example: a network management package that, when monitoring 1000 objects, sends 1000 ARPs simultaneously, every 5 minutes. (yes, there are several pieces of bad implementation that lead to this situation, but it is fundamentally caused by using broadcast as a discovery mechnaism). Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 09:36:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00553; Sun, 9 Oct 94 09:36:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00547; Sun, 9 Oct 94 09:36:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01465; Sun, 9 Oct 94 09:33:15 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA14152; Sun, 9 Oct 94 09:32:53 PDT Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 9 Oct 1994 17:32:47 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: ARP (was: Re: (IPng) Discovery) In-Reply-To: Your message of "Sun, 09 Oct 94 17:21:38 BST." <9410091621.AA13756@dxcoms.cern.ch> Date: Sun, 09 Oct 94 17:32:47 +0100 Message-Id: <1299.781720367@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >OK... those of us whose operational problems are DOMINATED by ARP- >related broadcast storms NEED TO SHOUT, clearly. Just my current >example: a network management package that, when monitoring 1000 >objects, sends 1000 ARPs simultaneously, every 5 minutes. >(yes, there are several pieces of bad implementation that lead >to this situation, but it is fundamentally caused by using broadcast >as a discovery mechnaism). nope - fundmentally broken distributed system there's nothing wrong with a multicast for discovery i nthe absence of other knowledge - a network management system that uses it is severely broken...since it could well use other techniques...(backwards learned mappings etc...) - also, not having uniform random distributed inter-request for any scheme, be it addr resolution, name lookup, routing exchanges or whatever, is just bad engineering what you mean is that you want some protocol temporal semanatics mandated in *cast so yo ucan complain (withold money) on contracts for people who misuse it, surely? i mean, many mbone applications could do what your broken arp system is doing (in fact, many analog media access (e.g. tv&radio) could) - we don't mandate against them because they might, do we? jon ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 13:48:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00577; Sun, 9 Oct 94 13:48:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00571; Sun, 9 Oct 94 13:48:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06036; Sun, 9 Oct 94 13:45:03 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA21868; Sun, 9 Oct 94 13:44:40 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15039; Mon, 10 Oct 1994 06:22:42 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Cc: dcrocker@mordor.stanford.edu, Ran Atkinson Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Sun, 09 Oct 1994 17:11:08 GMT." <9410091711.aa11034@sundance.itd.nrl.navy.mil> Date: Mon, 10 Oct 1994 06:22:38 +1000 Message-Id: <8543.781734158@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sun, 9 Oct 94 17:11:08 GMT From: Ran Atkinson Message-ID: <9410091711.aa11034@sundance.itd.nrl.navy.mil> 1) ARP uses broadcast when it really ought to use a well-known multicast address. This I agree with, other than the "a well known". By moving to ICMP, we use the IPv6 intra-link all-nodes multicast address. But this I don't. There's no real point switching to multicast if you send the packets everywhere without need (so the IPX, decnet, and appletalk nodes might be able to skip them - big deal). Better to split the multicast address into a bunch of multicast addresses - unless you're going to invent a bunch of IPv6 multicast addresses for no better purpose than mapping into particular link level multicast addresses, I don't see the point. Much better to simply take a well known 40 bit prefix of a MAC multicast address, and append something based on the IPv6 address being sought - much as Bill Simpson's proposal does, though I suspect that assuming MAC addresses are commonly used in IPv6 addresses, the low octet is probably going to be fairly evenly distributed in any case, so rather than all the xor'ing (or whatever) Bill proposed, I think I'd simply stick in the low octet of the IPv6 address, and save the computation. If we retain ARP, backwards compatibility will effectively preclude any attempt to move to multicast. This is not true at all. IPv6 ARP can easily use multicast. Clearly IPv4 is not going to change (any way at all) at this stage. Appletalk (phase 2) ARP uses multicast just fine (though does insist on multicasting to everyone) - they switched from using broadcast ARP in phase 1 with no apparent difficulties. 2) ARP is difficult to secure. If using ICMP or other upper layer protocols, we can now use IPv6 Authentication Header to authenticate replys in many cases. I think comments on this have been made before. If you can't communicate until after you ARP, any kind of security is going to be very very difficult. You have no way to get keys (other than by manual configuration). No thanks. 3) ARP for ATM has been a real issue. It might well not be so hard if it were ICMP-based and used intra-link multicast I can't see how ICMP's use of multicast need be any different than what ARP over link layer would use. 4) Use of ICMP messages rather than ARP messages can make for cleaner IP implementations inside some systems. Huh? It would make most I've seen considerably dirtier. Whether ARP is needed or not (whether MAC addresses of some kind are needed or not) isn't known till you get under IP to the link layer (conceptually anyway, and if you're looking for cleanliness this is what matters). Having the driver call back up into the IP (ICMP) layer to send a packet is most certainly unclean. I suspect that most implementations would simply have the driver (privately, and independantly - though via a utility routine, as is used for ARP of course) build private IP and ICMP headers, quite independantly of the normal ICMP/IP path. I simply can't imagine why anyone would want ARP built out of ICMP. I'll also note that I have seen no replies at all to my request for any of the proponents of ICMP over UDP for all kinds of new uses being proposed to explain why ICMP. I have to assume that no-one actually has any reasons, and thus I'd propose that nothing be built out of ICMP that can as easily be built from UDP (which is almost everything that isn't an error message, and echo/echo-reply). Changing ARP code from using the MAC broadcast address, to using a 40 bit prefix, with 8 address dependant bits on the end, but otherwise remaining the same is about as trivial a change as its possible to make. IPv6 nodes are going to have to be able to receive multicast anyway - adding one more MAC level multicast address to receive is almost as trivial (routers might want to add all 256 if proxy arp is to remain). It would be nice to specify "rational behaviour" a little too, so implementations could be fixed to not believe that a MAC address is guaranteed valid as long as something continues to send packets to the associated IPv6 address - but all that is just fixing bugs in IPv4 ARP, and should be done anyway (should have been done years ago). kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 15:03:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00611; Sun, 9 Oct 94 15:03:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00605; Sun, 9 Oct 94 15:03:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07334; Sun, 9 Oct 94 15:00:11 PDT Received: from Mordor.Stanford.EDU by Sun.COM (sun-barr.Sun.COM) id AA24170; Sun, 9 Oct 94 14:59:51 PDT Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA19880; Sun, 9 Oct 1994 14:59:43 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Oct 1994 05:59:43 -0700 To: Ran Atkinson From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: (IPng) Re: ARP Cc: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, First, I'm certainly not claiming that ARP is ideal. For example, I can imagine that it would be cleaner to use an ICMP format, as your suggest. But much in the internet suite is not ideal. Yet it works quite well. My point is that I think we are under pressure to solve the serious problems and are time and resource constrained to achieve that. As to the matter of window of opportunity, it would be vastly better for tranisition if we made a point of re-using as much IPv4 infrastructure/support mechanisms as possible, for initial adoption, rather than requiring that we switch all the pieces at once. Since Arp works spiffy, we should re-use it and make any mods LATER. This is a directly contrary view to the timing view you espouse. My model for transition is to have as view critical dependencies as possible. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 15:18:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00631; Sun, 9 Oct 94 15:18:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00625; Sun, 9 Oct 94 15:18:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07592; Sun, 9 Oct 94 15:14:30 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA24669; Sun, 9 Oct 94 15:14:09 PDT From: Ran Atkinson Message-Id: <9410091809.ZM11294@sundance.itd.nrl.navy.mil> Date: Sun, 9 Oct 1994 18:09:32 -0500 In-Reply-To: Robert Elz "Re: (IPng) Re: ARP" (Oct 10, 6:22) References: <8543.781734158@munnari.OZ.AU> X-Mailer: Z-Mail (3.0.1 04apr94) To: Robert Elz Subject: Re: (IPng) Re: ARP Cc: ipng@sunroof2.Eng.Sun.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Oct 10, 6:22, Robert Elz wrote: By moving to ICMP, we use the IPv6 intra-link all-nodes multicast address. But this I don't. There's no real point switching to multicast if you send the packets everywhere without need (so the IPX, decnet, and appletalk nodes might be able to skip them - big deal). Better to split the multicast address into a bunch of multicast addresses - unless you're going to invent a bunch of IPv6 multicast addresses for no better purpose than mapping into particular link level multicast addresses, I don't see the point. Excuse me, but I _did_ say "intra-link all-nodes" multicast which is a far cry from "send the packets everywhere without need". I gather you haven't seen ARP broadcast storms recently on your networks. Much better to simply take a well known 40 bit prefix of a MAC multicast address, and append something based on the IPv6 address being sought - much as Bill Simpson's proposal does, though I suspect that assuming MAC addresses are commonly used in IPv6 addresses, the low octet is probably going to be fairly evenly distributed in any case, so rather than all the xor'ing (or whatever) Bill proposed, I think I'd simply stick in the low octet of the IPv6 address, and save the computation. This does NOT work unless one happens to have an IEEE 802-based LAN technology. For example, it does NOT work over my radio subnets, over CDPD, over ATM, or over CellularData subnets. I explicitly stated that a goal was to become _independent_ of IEEE 802 technology. If you have a better way that is subnet-technology independent, I'm all ears. 2) ARP is difficult to secure. If using ICMP or other upper layer protocols, we can now use IPv6 Authentication Header to authenticate replys in many cases. I think comments on this have been made before. If you can't communicate until after you ARP, any kind of security is going to be very very difficult. You have no way to get keys (other than by manual configuration). No thanks. Wrong. Most of the time, the host making the ARP request _already_ has made a DNS lookup to get the IP number for the hostname before it makes the ARP request. With Eastlake-Kaufman, this means that the host making the ARP request has the key for the system being ARP'd for and for other commonly communicated with systems (e.g. the router on that subnet). So MOST of the time, the ARP reply CAN be authenticated fully. % I can't see how ICMP's use of multicast need be any different than % what ARP over link layer would use. ARP is only for IEEE 802 technologies and uses IEEE addresses. This is hardly subnet-independent. 4) Use of ICMP messages rather than ARP messages can make for cleaner IP implementations inside some systems. Huh? It would make most I've seen considerably dirtier. Your mileage differs, but does not contradict my assertion. It _can_ make _some_ implementations cleaner. % I simply can't imagine why anyone would want ARP built out of % ICMP. I've given a number of concrete reasons. Your imagination should now be sufficient. I gatther you disagree, but the above is at best gratuitous. I look forward to your I-D describing a fixed ARP for IPv6. My goal is to have IPv6 work better than IPv4. I'm interested to hear in detail what changes you would make. Regards, Ran atkinson@itd.nrl.navy.mil }-- End of excerpt from Robert Elz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 18:45:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00710; Sun, 9 Oct 94 18:45:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00704; Sun, 9 Oct 94 18:44:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11431; Sun, 9 Oct 94 18:41:22 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02004; Sun, 9 Oct 94 18:41:01 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA03405; Sun, 9 Oct 94 18:35:35 -0700 Received: by xirtlu.zk3.dec.com; id AA23704; Sun, 9 Oct 1994 21:35:33 -0400 Message-Id: <9410100135.AA23704@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: dcrocker@mordor.stanford.edu Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Sun, 09 Oct 94 17:11:08 GMT." <9410091711.aa11034@sundance.itd.nrl.navy.mil> Date: Sun, 09 Oct 94 21:35:27 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Just as a comment from SIPP 8bytes. We did use ICMP messages as the only strategy at this time since SIPP is Bill's system discovery strategy. ARP has not been speced ever for SIP or SIPP. We have been down that path since Amsterdam IETF meeting for most prototype work. In addition to what Ran stated ARP did not solve the black-hole problem and has no present mechanism for Mobile except maybe a hack which I will not repeat here someone explained to me and I am not sure it would work. But I am with Ran and others that the request/response model is one that will continue as best I can tell at this point. But that does not mean ARP lives and it should not IMHO. But as several have pointed out we need to watch what we do with ICMP. Security - I am confused how ICMP will use the Authentication header? In discovery I am sitting at a point in the code base next to the IP layer and below or adjunct to it as ARP today and IPv6 discovery tomorrow. I did not think I would parse the options until I hit the IPv6 layer in the present model I am under. Then if I see a security packet then off I am to MD5 and then to wherever that header requires me. But this is not done in the icmp code mods. So where are we going with ICMP messages for Disscovery and if auth hdrs are there I need to think about that differently than present? Or are you saying during discovery the ICMP should pass it up to the option processing in that case? If so I am not sure this is optimal? But I think the disocvery spec needs some work and many details need to be ironed out before it will be "implementable as is". So there is a lot of work here and I think we need a much more thorough discussion of the design requirements bill sent out before we even undertake the algorithms/processing or formats. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 18:59:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00742; Sun, 9 Oct 94 18:59:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00736; Sun, 9 Oct 94 18:59:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11772; Sun, 9 Oct 94 18:56:06 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02807; Sun, 9 Oct 94 18:55:45 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA03902; Sun, 9 Oct 94 18:50:11 -0700 Received: by xirtlu.zk3.dec.com; id AA23842; Sun, 9 Oct 1994 21:50:10 -0400 Message-Id: <9410100150.AA23842@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Sun, 09 Oct 94 05:59:43 PDT." Date: Sun, 09 Oct 94 21:50:03 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, In the present specs these are the dependencies on the link layer technical strategy to discover nodes, addresses, routes, and services (which I think we are finding consensus to move over UDP [mabye I still have a few arguments pro dhcp/dns servers in media type packets]. Here is what has the dependencies: Direct: Transition spec +++> Transition is the nested ICMP spec dependency that is next (loop). Autoconfiguration spec Renumbering spec Advertisement/Solicitation Mobililty Route Disocovery Prefix Type / Changes (hence address plan/architecture) Indirect DHCPng BOOTPng Autoregistration When we figure this all out it will not look like ARP I assure you. I am not sure what it will look like as I cannot buy into Bill's specs 100% at this time. But to think we are OK cause we have ARP is not a sane engineering design center for IPv6. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 20:40:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00778; Sun, 9 Oct 94 20:40:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00772; Sun, 9 Oct 94 20:40:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13339; Sun, 9 Oct 94 20:36:25 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA08721; Sun, 9 Oct 94 20:35:19 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 10 Oct 94 12:27:53 +0859 From: Masataka Ohta Message-Id: <9410100328.AA15578@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Mon, 10 Oct 94 12:27:52 JST In-Reply-To: <9410091809.ZM11294@sundance.itd.nrl.navy.mil>; from "Ran Atkinson" at Oct 9, 94 6:09 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Excuse me, but I _did_ say "intra-link all-nodes" multicast which > is a far cry from "send the packets everywhere without need". > I gather you haven't seen ARP broadcast storms recently on your > networks. No. Sane network administrator won't have link with 1,000 hosts. > Much better to simply take a well known 40 bit prefix of a MAC > multicast address, and append something based on the IPv6 address > being sought - much as Bill Simpson's proposal does, though I > suspect that assuming MAC addresses are commonly used in IPv6 > addresses, the low octet is probably going to be fairly evenly > distributed in any case, so rather than all the xor'ing (or > whatever) Bill proposed, I think I'd simply stick in the low > octet of the IPv6 address, and save the computation. > > This does NOT work unless one happens to have an IEEE 802-based LAN > technology. For example, it does NOT work over my radio subnets, over > CDPD, over ATM, or over CellularData subnets. You might want to say that Simpson's proposal doesn't work over connection oriented link layer. But it does work over any link layer where point-to-multipoint communication is supported and it is supported. > I explicitly stated > that a goal was to become _independent_ of IEEE 802 technology. Supporting plain broadcast is even more easier than supporting point-to-multipoint. Radio technology is inherently broadcast and ATM works just fine with broadcast. Though some connection oriented link layer is poorly designed that it does not directly support broadcast, it is not difficult to re-construct broadcast as intra-link all-nodes multicat using point-to-multipoint mechanism. > If you have a better way that is subnet-technology independent, > I'm all ears. Nothing is wrong with subnet. > Wrong. Most of the time, the host making the ARP request _already_ > has made a DNS lookup to get the IP number for the hostname before it > makes the ARP request. Wrong. So, ALL the time, the forged ARP does not break security. > With Eastlake-Kaufman, this means that the > host making the ARP request has the key for the system being ARP'd for With any DNS based security architechture, key is given to host with specific hostname. What is relied is hostname. NOT IP NOR MAC addresses. IP or MAC addresses does not have to be, actually is not and practically can not be protected, which does not affect the total security. > So MOST of the time, the ARP reply CAN be authenticated > fully. You don't understand that weak security, security over secure IP address, is of no use with secure IPv6. Secure MAC addresses is a lot less useless. > % I can't see how ICMP's use of multicast need be any different than > % what ARP over link layer would use. > > ARP is only for IEEE 802 technologies and uses IEEE addresses. This > is hardly subnet-independent. IEEE addresses are the only practical way to assure reasonable uniqueness of MAC addresses in a link. IEEE addresses are link layer independent. Even ATM address has 6 byte room which is, as expected, used for IEEE address. Haven't you ever heard of ARP broadcast storm? Note that duplicated MAC addresses are equally harmful on both broadcasted and non-broadcasted media. So, practically, IEEE addresses are the only solution. > 4) Use of ICMP messages rather than ARP messages can make for cleaner > IP implementations inside some systems. > Your mileage differs, but does not contradict my assertion. It _can_ > make _some_ implementations cleaner. You haven't given any example. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 23:48:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00871; Sun, 9 Oct 94 23:48:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00859; Sun, 9 Oct 94 23:47:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16543; Sun, 9 Oct 94 23:44:18 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA19425; Sun, 9 Oct 94 23:43:55 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA11162; Sun, 9 Oct 1994 23:43:53 -0700 Date: Sun, 9 Oct 1994 23:43:53 -0700 From: Tony Li Message-Id: <199410100643.XAA11162@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: atkinson@sundance.itd.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: Dave Crocker's message of Sun, 9 Oct 1994 05:59:43 -0700 Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM My point is that I think we are under pressure to solve the serious problems and are time and resource constrained to achieve that. As to the matter of window of opportunity, it would be vastly better for tranisition if we made a point of re-using as much IPv4 infrastructure/support mechanisms as possible, for initial adoption, rather than requiring that we switch all the pieces at once. Since Arp works spiffy, we should re-use it and make any mods LATER. Are you willing to live with ARP for the next 20 years? This is the last chance you get to change the fundamentals in the hosts for that long. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 9 23:48:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00870; Sun, 9 Oct 94 23:48:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00858; Sun, 9 Oct 94 23:47:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16543; Sun, 9 Oct 94 23:44:18 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA19425; Sun, 9 Oct 94 23:43:55 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA11162; Sun, 9 Oct 1994 23:43:53 -0700 Date: Sun, 9 Oct 1994 23:43:53 -0700 From: Tony Li Message-Id: <199410100643.XAA11162@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: atkinson@sundance.itd.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM In-Reply-To: Dave Crocker's message of Sun, 9 Oct 1994 05:59:43 -0700 Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM My point is that I think we are under pressure to solve the serious problems and are time and resource constrained to achieve that. As to the matter of window of opportunity, it would be vastly better for tranisition if we made a point of re-using as much IPv4 infrastructure/support mechanisms as possible, for initial adoption, rather than requiring that we switch all the pieces at once. Since Arp works spiffy, we should re-use it and make any mods LATER. Are you willing to live with ARP for the next 20 years? This is the last chance you get to change the fundamentals in the hosts for that long. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 00:44:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00990; Mon, 10 Oct 94 00:44:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00984; Mon, 10 Oct 94 00:43:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17782; Mon, 10 Oct 94 00:40:23 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA01210; Mon, 10 Oct 94 00:40:02 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03365; Mon, 10 Oct 1994 08:39:58 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16556; Mon, 10 Oct 1994 08:39:56 +0100 Message-Id: <9410100739.AA16556@dxcoms.cern.ch> Subject: Re: ARP (was: Re: (IPng) Discovery) To: ipng@sunroof.Eng.Sun.COM Date: Mon, 10 Oct 1994 08:39:56 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <1299.781720367@cs.ucl.ac.uk> from "Jon Crowcroft" at Oct 9, 94 05:32:47 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2028 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jon, We've had this argument before and I think I have again failed to get across my point: in a multivendor world, the ARP broadcast model INEVITABLY leads to a fundmentally broken distributed system because real implementors are naive, inexperienced and careless. This is NOT a theoretical statement: it's an experimental result. Now, up until December 1994, is the window of opportunity to get rid of this problem. Brian >--------- Text sent by Jon Crowcroft follows: > > > > >OK... those of us whose operational problems are DOMINATED by ARP- > >related broadcast storms NEED TO SHOUT, clearly. Just my current > >example: a network management package that, when monitoring 1000 > >objects, sends 1000 ARPs simultaneously, every 5 minutes. > >(yes, there are several pieces of bad implementation that lead > >to this situation, but it is fundamentally caused by using broadcast > >as a discovery mechnaism). > > nope - fundmentally broken distributed system > > there's nothing wrong with a multicast for discovery i nthe absence of > other knowledge - a network management system that uses it is severely > broken...since it could well use other techniques...(backwards learned > mappings etc...) - also, not having uniform random distributed > inter-request for any scheme, be it addr resolution, name lookup, > routing exchanges or whatever, is just bad engineering > > what you mean is that you want some protocol temporal semanatics mandated in > *cast so yo ucan complain (withold money) on contracts for people who > misuse it, surely? > > i mean, many mbone applications could do what your broken arp system > is doing (in fact, many analog media access (e.g. tv&radio) could) - > we don't mandate against them because they might, do we? > > jon > > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 06:32:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01131; Mon, 10 Oct 94 06:32:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01125; Mon, 10 Oct 94 06:31:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24796; Mon, 10 Oct 94 06:28:20 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA04313; Mon, 10 Oct 94 06:27:59 PDT From: Ran Atkinson Message-Id: <9410100923.ZM11687@sundance.itd.nrl.navy.mil> Date: Mon, 10 Oct 1994 09:23:35 -0500 X-Mailer: Z-Mail (3.0.1 04apr94) To: bound@zk3.dec.com Subject: (IPng) Re: ARP, etc. Cc: ipng@sunroof2.Eng.Sun.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, Your points are all well-taken. I, too, do not buy into all of Bill Simpson's specs at this time. In particular, I would much prefer to reuse the recently developed Service Discovery protocol based on UDP instead of adding service discovery to ICMP as Bill proposed. The notion of running more services over UDP is appealling because it will reduce kernel bloat and give implementers more flexibility. Further, your point about the interaction between protocol processing and the Auth Header usage is important. We'll need to study that further. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 06:34:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01143; Mon, 10 Oct 94 06:34:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01137; Mon, 10 Oct 94 06:34:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24974; Mon, 10 Oct 94 06:31:07 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04662; Mon, 10 Oct 94 06:30:42 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14136; Mon, 10 Oct 1994 21:56:00 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: ARP (was: Re: (IPng) Discovery) In-Reply-To: Your message of "Mon, 10 Oct 1994 08:39:56 +0100." <9410100739.AA16556@dxcoms.cern.ch> Date: Mon, 10 Oct 1994 21:55:55 +1000 Message-Id: <8575.781790155@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 10 Oct 1994 08:39:56 +0100 (MET) From: "Brian Carpenter CERN-CN" Message-ID: <9410100739.AA16556@dxcoms.cern.ch> We've had this argument before and I think I have again failed to get across my point: in a multivendor world, the ARP broadcast model INEVITABLY leads to a fundmentally broken distributed system because real implementors are naive, inexperienced and careless. I understand that, and still agree with Jon. The problem is that I don't see that any of the proposed changes are in any way addressing the problem you concentrate on above. We have here a database lookup problem of a kind - we could do that by actually building a database server, and simply send it queries. That would resolve those problems, but raise large numbers of others, and I don't think that anyone is seriously suggsting handling the problem that way. All of the current proposals, in one way or another, broadcast (multicast) the lookup (query) to a large number of systems, and expect that the system that knows the answer will respond (or in Bill Simpson's draft, will process or forward the packet). That's the same basic model used by ARP. Careless implementations will continue to cause problems, especially in environments not well engineered for these kinds of uses. The only notable difference that I see is that ARP has been around for quite a while, its failures, and potential failures are well known, and work can continue making the implementations more robust. The counter proposals are new, will have new implementations, and undoubtably, lots of new crap implementations to accompany a few good ones. I see no evidence that this will improve anything at all. In fact I see nothing beyond blind faith that "anything must be better", which I simply don't accept. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 10:37:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01400; Mon, 10 Oct 94 10:37:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01369; Mon, 10 Oct 94 10:14:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12234; Mon, 10 Oct 94 10:10:45 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA09961; Mon, 10 Oct 94 10:08:32 PDT Received: from relay.imsi.com by wintermute.imsi.com id NAA19485 for ; Mon, 10 Oct 1994 13:08:29 -0400 Received: from lorax.imsi.com by relay.imsi.com id NAA08046 for ; Mon, 10 Oct 1994 13:08:28 -0400 Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA10346; Mon, 10 Oct 94 13:08:27 EDT Message-Id: <9410101708.AA10346@lorax.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: ARP (was: Re: (IPng) Discovery) In-Reply-To: Your message of "Sun, 09 Oct 1994 17:21:38 BST." <9410091621.AA13756@dxcoms.cern.ch> Date: Mon, 10 Oct 1994 13:08:26 -0400 From: Rens Troost Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >>>>> "Brian" == Brian Carpenter CERN-CN writes: >> --------- Text sent by Dave Crocker follows: Brian> ... >> With the wide range of highly pressing problems to solve, I'd >> think that re-doing the ARP-realm of mechanisms would be very far >> from the IPng critical path, indeed. ARP works well. While >> there might be many ways to do better, problems with ARP have >> simply not been on the top of major hit lists. Brian> OK... those of us whose operational problems are DOMINATED by Brian> ARP- related broadcast storms NEED TO SHOUT, clearly. Just my Brian> current example: a network management package that, when Brian> monitoring 1000 objects, sends 1000 ARPs simultaneously, Brian> every 5 minutes. (yes, there are several pieces of bad Brian> implementation that lead to this situation, but it is Brian> fundamentally caused by using broadcast as a discovery Brian> mechnaism). I've managed multi-thousand node networks for the last few years (a pursuit that I am thankfully taking a break from!) and it's been a REALLY LONG TIME since I've seen arp meltdowns. I don't think it's a common problem anymore. No amount of protocol engineering will protect you from kamikaze implementations, which sounds like what you have here. Will the situation be that much better sending out 1000 multicasts every 5 minutes? -Rens ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 14:53:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01580; Mon, 10 Oct 94 14:53:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01574; Mon, 10 Oct 94 14:52:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11380; Mon, 10 Oct 94 14:49:20 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA05068; Mon, 10 Oct 94 14:48:56 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01650; Tue, 11 Oct 1994 05:48:08 +1000 (from kre@munnari.OZ.AU) To: atkinson@itd.nrl.navy.mil Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Sun, 09 Oct 1994 18:09:32 EST." <9410091809.ZM11294@sundance.itd.nrl.navy.mil> Date: Tue, 11 Oct 1994 05:48:03 +1000 Message-Id: <8664.781818483@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sun, 9 Oct 1994 18:09:32 -0500 From: Ran Atkinson Message-ID: <9410091809.ZM11294@sundance.itd.nrl.navy.mil> Excuse me, but I _did_ say "intra-link all-nodes" multicast which is a far cry from "send the packets everywhere without need". "all nodes" is all nodes, "intra-link" is "everywhere" as far as MAC level broadcasts go. Having said that, I should also say that an "all nodes" multicast is almost certainly better than a MAC broadcast, (probably by a factor of two or three), its just that a "some nodes" multicast will probably be better still by a factor of a couple of hundred, which seems worth having to me. I gather you haven't seen ARP broadcast storms recently on your networks. No. I try to obtain code that contains ARP that works, and also attempt to engineer my network so that that kind of nonsense is unlikely even if a broken implementation does find its way in. I still fail to see why, even given ARP storms, an ARP broadcast storm is going to be inherantly any worse than an ICMP multicast storm - that you haven't seen the latter yet is probably merely because you have no appreciable ICMP multicast traffic. When I used to see broadcast storms (on a less well engineered net) they were much more often IP broadcast storms, not ARP (generated from routed, or rwhod, or similar) and due to poorly configured IP (along with poor implementations). Since ARP doesn't take much in the nature of configuration, that's one less thing to go wrong. At least we can hope that the implementors will gradually learn, and fix the broken stuff - there will always be inexperienced people doing configuration however (for whatever amount of configuration needs to be done). This does NOT work unless one happens to have an IEEE 802-based LAN technology. That's fine. I believe strongly that ARP is a link level technology solving a link level problem (to what link level address should I send this packet to get it to the network level's peer entity). As such, link dependant solutions are fine by me - even better than fine, that's what I think will work best. Its hard to imagine how the same mechanism can work well on all of PPP, Ethernet, and X.25. If you have a better way that is subnet-technology independent, I'm all ears. No, but I don't want any such thing. Wrong. Most of the time, the host making the ARP request _already_ has made a DNS lookup to get the IP number for the hostname before it makes the ARP request. Without getting into the "rest of the time", how does that first DNS query get made? Or are you going to rely on something insecure to get you your first "secure" answer? % I can't see how ICMP's use of multicast need be any different than % what ARP over link layer would use. ARP is only for IEEE 802 technologies and uses IEEE addresses. This is hardly subnet-independent. Yes - however the IPv6 multicast addresses need to be translated into something media dependant to work for any particular link level. If there is such a thing, then that link level's ARP equivalent can just use those media addresses directly, can't it? Why does it need the pretence of being told an IPv6 multicast address in order to generate whatever is the relevant media address? If some media happens to work directly using IPv6 addrs at the link level, then by all means allow that media to use IPv6 multicast addresses to do address resolution - but in link level packets, not IP packets (unless they are the same, in which case an ARP equivalent can't be needed at all - that's SLIP as one trivial example). Your mileage differs, but does not contradict my assertion. It _can_ make _some_ implementations cleaner. It doesn't contradict, just negates - it might make some cleaner, it will certainly make some uglier. Stand off - strike this. % I simply can't imagine why anyone would want ARP built out of % ICMP. I've given a number of concrete reasons. Other than security (which could be built into link level ARP, though I admit with more mechanisms) but which I am not at all sure is workable in any case for such a basic function, I fail to see any at all. I look forward to your I-D describing a fixed ARP for IPv6. Such a thing may appear, perhaps. Since it doesn't need to be very different than ARP for v4, it shouldn't be difficult. My goal is to have IPv6 work better than IPv4. Mine too. I'm interested to hear in detail what changes you would make. Basically only one (apart from trivia like a new address format and length to hold IPv6 instead of IPv4 addresses, however ARP is already designed with that in mind) - change the destination MAC address to which queries are broadcast away from FFFFFFFFFFFF to NNNNNNNNNNXX where NNNNNNNNNN is some well known multicast address prefix, and XX is computed from the IPv6 address being sought. That's all it should take. That's for IS 8802 type media of course. The others need more work - but still along the lines of whatever they need now for v4 (in most cases, probably unchanged). I don't see how saying "use multicast ICMP" solves the problem in general, it simply defers it (how does multicast ICMP, or multicast IP, work over an X.25 carrier?) kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 19:57:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01872; Mon, 10 Oct 94 19:57:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01866; Mon, 10 Oct 94 19:57:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09522; Mon, 10 Oct 94 19:54:13 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA24756; Mon, 10 Oct 94 19:53:50 PDT Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA15713; Mon, 10 Oct 1994 22:53:48 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA22742; Mon, 10 Oct 1994 22:53:46 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA04895; Mon, 10 Oct 1994 22:30:24 -0400 Message-Id: <9410110230.AA04895@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: kre@munnari.OZ.AU, conta@zk3.dec.com Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 11 Oct 94 05:48:03 +1000." <8664.781818483@munnari.OZ.AU> Date: Mon, 10 Oct 94 22:30:24 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One point worth mentioning perhaps - which I mentioned in private mail with Kre, and was reiterated today during the first day of the IPv6 Implementors Meeting in Cambridge - is that ARP processing is faster than ICMP processing, given that there is no intermediate IPv6 layer header processing. I would agree that a new ARP version could fix all previous problems. However, the new "things" that were introduced with ICMP for IPv6, if introduced in ARP, may bring with them the same "chance" factor of a bad versus good implementation. As a matter of fact, I can say from my own experience, that the ICMP based discovery that I implemented in the IPng (SIPP) prototype that runs on OSF/1 and OVMS for more than six months now, worked well. That is true in its several experimental incarnations of deviations from the specs - there is a significant disagreement that I have with using "unicast IPv6" combined with "link-layer all nodes multicast" for the first packet, as specified by Bill Simpson, as particularly dangerous. As an alternative to the "IP unicast/link-layer multicast", besides the old ARP model, which is queueing the IPv6 packet until a "reply" comes back to the "address resolution" "request", I played with a model, which I described today in the Implementors meeting consisting in: IPv6 src: the IPv6 address of the interface is sent dst: all-nodes IPv6 multicast address IPv6 hop by hop option extension header - "media address resolution request" which carries: - the destination IPv6 unicast address - the media address of the interface the packet goes out. ... Transport header User data. The recipient of the IPv6 "media address resolution request" hop by hop extension header, among other things, returns to the sender an ICMP message indicating the media address of the target IPv6 address, and then replaces the "all-nodes IPv6 multicast" address in the received IPv6 header, with the destination "IPv6 unicast" from the extension header and continues the procesing as if the packet were sent with a unicast address. This alternative provides a "media address resolution solicitation" piggy backed on the data packet, while it eliminates the separate "solicitation" ICMP packet - the previously two packet ICMP request/reply model is reduced to one packet ICMP reply. Additionally, what I feel it is more important is that while reducing the network load, and eliminating the "queueing of the data packet" latency, it eliminates the danger of unpredicted or faulty behavior that the "IP unicast/link-layer all nodes multicast" combination represents. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 20:55:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01901; Mon, 10 Oct 94 20:55:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01895; Mon, 10 Oct 94 20:55:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11933; Mon, 10 Oct 94 20:52:07 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA29284; Mon, 10 Oct 94 20:51:44 PDT Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA18368; Mon, 10 Oct 1994 23:51:41 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA23561; Mon, 10 Oct 1994 23:51:38 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA04956; Mon, 10 Oct 1994 23:28:16 -0400 Message-Id: <9410110328.AA04956@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com, atkinson@sundance.itd.nrl.navy.mil, conta@zk3.dec.com Subject: Re: (IPng) Re: ARP, etc. In-Reply-To: Your message of "Mon, 10 Oct 94 09:23:35 CDT." <9410100923.ZM11687@sundance.itd.nrl.navy.mil> Date: Mon, 10 Oct 94 23:28:16 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, Your points are all well-taken. I, too, do not buy into all of Bill Simpson's specs at this time. Besides some more minor issues around the documents clarity (processing in paarticular), I do have some major disagreements myself, which revolve around the header formats (information content) and processing: 1. - I do consider a big whole in the specs the fact that the information passed in the ICMP header is not sufficient (complete) without information from the IPv6 header. The ICMP header information should be complete, self contained and sufficient by itself - did I overstate it? (-:. The IPv6 header that is used to bring the packet to its destination should have only that role. i.e. to carry the ICMP packet, and no role in contributing with its fields to the "discovery information" carried by the ICMP header. This will avoid juggling around with the IPv6 header fields - source address in particular - to fit the needs of complementing the ICMP information. The similarity of some of the ICMP discovery header fields to IPv6 header fields, incidental or not, or the IPv6 header by itself, should be of no concern for the ICMP sublayer, in relationship to the discovery mechanism. This has a major implication, in that almost all discovery ICMP formats have to be reworked - I scatched what I think should be the correct formats but I am not going to overlaod this message. 2. - The processing model in which the first data packet of an unkown destination media address host is sent with a "IPv6 unicast/link-layer multicast" opens in my view the door to faulty or unexpected behavior. I prefer in its place the old model used by ARP, of queueing the data packet until the media address is resolved, or another model which I described in an earlier mail, which maps an IPv6 multicast address to link-layer multicast, but carries the IPv6 unicast destination address and the request for its media address as a "hop by hop option"(piggy back): IPv6 src: the IPv6 address of the interface is sent dst: all-nodes IPv6 multicast address IPv6 hop by hop option extension header - "media address resolution request" which carries: - the destination IPv6 unicast address - the media address of the interface the packet goes out. ... Transport header User data. The "hop by hop" "media address resolution request" option processing triggers an ICMP reply with the target media address, while the rest of the packet including data which piggy backed the request is processed as if it were IPv6 unicast. While eliminating the latency of queueing the data packet until the media address is resolved and reducing the number of packets required for address resolution to one, it is also eliminating the danger of using "ipv6 unicast mapped to a link-layer multicast". In particular, I would much prefer to reuse the recently developed Service Discovery protocol based on UDP instead of adding service discovery to ICMP as Bill proposed. The notion of running more services over UDP is appealling because it will reduce kernel bloat and give implementers more flexibility. It looks like there were more people agreeing on this than I thought. Yes, the Services discovery best place is not ICMP, but rather a more flexible mechanism, pretty much the style proposed by Jon Veizades & co, for IPv4. ICMP should be kept lean as much as possible, and not as a "pseudo-transport" mechanism to replace UDP, for things that UDP is better suited for. Further, your point about the interaction between protocol processing and the Auth Header usage is important. We'll need to study that further. I thought we were clear on this - the ICMP header being the last header, it is processed after the processing of the preceeding IPv6 header and extension headers, including the "authentication" completes, i.e. if an IPv6 "authentication" extension header is present then the ICMP header information is authenticated. Is that correct? Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 10 23:18:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01977; Mon, 10 Oct 94 23:18:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01971; Mon, 10 Oct 94 23:18:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15742; Mon, 10 Oct 94 23:14:47 PDT Received: from databus.databus.com by Sun.COM (sun-barr.Sun.COM) id AA09117; Mon, 10 Oct 94 23:14:24 PDT Date: Tue, 11 Oct 94 02:14 EDT Message-Id: <9410110214.AA28676@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. Content-Length: 2060 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Mon, 10 Oct 94 23:28:16 -0400 > From: conta@zk3.dec.com > > - The processing model in which the first data packet of an unkown > destination media address host is sent with a "IPv6 unicast/link-layer > multicast" opens in my view the door to faulty or unexpected behavior. Without agreeing or disagreeing, may I ask for specifics on this? Are you afraid that some implementation will think it's supposed to forward the packet? But this is such a basic and common condition that surely such a bug would not survive the first day of testing - I think. The same is true of the concern Bill mentions in the draft - that the combo of multicast-link and unicast-IP will confuse some drivers. One can hardly do any testing at all without getting the "first-packet" code right. If a dumb link-level driver mistakenly hands packets to IP multicast code rather than to unicast, can't the multicast code, which will after all be new for v6, fix up the problem? While I think of the draft, why isn't General Solicitation a bit in the IP header? Another way of asking this is: What is in the GS which makes it worth sending a separate packet, from the point of view of the dest and from the point of view of other hosts who will see and have to discard the multicast/broadcast? This is taking place on a single link, or set of virtual links, so the dest presumably has seen the same stuff fly by as the source. In the case that the dest is a mobile host newly on the link, it can transmit a solicitation at the same 1-packet cost as the proposed source-sends scheme. Finally, under what circumstances would a host with a frame-relay or X.25 interface have virtual circuits with unknown peers? Why didn't it find out who's there as each VC came up, rather than duplicating a packet and sending it on every VC without a known peer address? Is this a sort of trick to get the packet sent on an SVC that I just created, because I know somehow what link-level destination address corresponds to the dest IP address? Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 00:37:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02036; Tue, 11 Oct 94 00:37:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02029; Tue, 11 Oct 94 00:37:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17967; Tue, 11 Oct 94 00:33:59 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA18315; Tue, 11 Oct 94 00:33:26 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26267; Tue, 11 Oct 1994 08:33:23 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07407; Tue, 11 Oct 1994 08:33:20 +0100 Message-Id: <9410110733.AA07407@dxcoms.cern.ch> Subject: Re: ARP (was: Re: (IPng) Discovery) To: ipng@sunroof.Eng.Sun.COM Date: Tue, 11 Oct 1994 08:33:19 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410101708.AA10346@lorax.imsi.com> from "Rens Troost" at Oct 10, 94 01:08:26 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1467 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Rens, There are still plenty of kamikaze implementations out here. (I agree, most broadcast storms are non-ARP storms these days, but they are mostly caused by discovery protocols inspired by ARP.) And when the next generation of programmers get their hands dirty on the IPv6 specs, there will be a next generation of kamikaze implementations. Murphy's law works. So we need a basic design that is reasonably robust even when sloppy implementations appear. The best design principle I can see is to minimise the use of multicast for discovery. You can actually eliminate it (cf RFC 1577) which I would prefer personally, but I realise that is a lost battle. I quite like Alex Conta's piggyback proposal. Brian >--------- Text sent by Rens Troost follows: ... > I've managed multi-thousand node networks for the last few years (a > pursuit that I am thankfully taking a break from!) and it's been a > REALLY LONG TIME since I've seen arp meltdowns. I don't think it's a > common problem anymore. No amount of protocol engineering will protect > you from kamikaze implementations, which sounds like what you have > here. Will the situation be that much better sending out 1000 > multicasts every 5 minutes? > > -Rens > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 02:22:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02111; Tue, 11 Oct 94 02:22:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02101; Tue, 11 Oct 94 02:15:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20544; Tue, 11 Oct 94 02:11:55 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA23722; Tue, 11 Oct 94 02:11:33 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA01273; Tue, 11 Oct 94 05:07:22 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410110907.AA01273@pluto.dss.com> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Tue, 11 Oct 1994 05:07:20 -0400 (EDT) Cc: dcrocker@mordor.stanford.edu In-Reply-To: <9410091711.aa11034@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Oct 9, 94 05:11:08 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3995 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Dave, > As noted earlier, I like the request/response model of ARP. I have > a small number of reasons for preferring an ICMP message format to the > existing ARP message format. Really the only window of opportunity to > fix or change ARP is during the move to IPv6. Compatibility needs > preclude attempts to change ARP at all other times. ARP works OK for > 802-style LANs, but not all subnet technologies. So? ARP is medium specific and lives in the interface drive. It is not supposed to work for all subnet technologies. > We need a more > general solution and moving to ICMP messages can help generalise > the approach. Such ICMP messages will still be medium specific. > 1) ARP uses broadcast when it really ought to use a well-known multicast > address. By moving to ICMP, we use the IPv6 intra-link all-nodes > multicast address. The mapping between that and the appropriate > link multicast address is covered automatically as part of the > "IP over foo-subnet-technology" specification (these generally exist). > If we retain ARP, backwards compatibility will effectively preclude > any attempt to move to multicast. Why do you believe this? > ARP storms are not unheard of. > Using multicast will clearly help contain and reduce the liklihood > of such problems. Is a multicast storm somehow less bad than a broadcast storm? > 2) ARP is difficult to secure. If using ICMP or other upper layer > protocols, we can now use IPv6 Authentication Header to authenticate > replys in many cases. Since address spoofing is a well-known and > widespread real security problem, it seems like we should try to > reduce this risk while the opportunity is in front of us. I assume this means that we are supposed to authenticate link layer address resolution on each hop on a multihop path between two hosts so that the two end hosts can then authenticate each other. Out side of avoiding an intruder which returns a bogus arp response to an ARP request, I am not sure what has been achieved. And multiple different responses to a single ARP request can certainly be detected, while if only the intruder replies, end-to-end authentication would catch the intruder even when ARP is not authenticated. > Eastlake > & Kaufman have a plausible method for putting signed host keys into > the DNS and there is an IETF WG focused on Key Mgmt, so those related > issues are being solved. It is the case that some replys are awkward > to authenticate, but it is also the case that many replys are easily > authenticated IF we use ICMP (or another upper-layer protocol's) > messages. I believe in improving security whenever the chance appears > rather than waiting for a "silver bullet" perfect solution to appear. But why waste effort in pointless authentication? > 3) ARP for ATM has been a real issue. It might well not be so hard if > it were ICMP-based and used intra-link multicast (ATM's multicast > is clearly broken and won't scale, but for the intra-link case it > seems to work). Other new technologies that aren't 802-like have > similar problems. So what? > 4) Use of ICMP messages rather than ARP messages can make for cleaner > IP implementations inside some systems. All you have done is unpartition two separate problems (internet control [medium independent] and address resolution [medium dependent]) which were previously reasonably partitioned. There are no obvious benefits, and the approach probably represents bad engineering. > Ran > atkinson@itd.nrl.navy.mil Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 05:08:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02255; Tue, 11 Oct 94 05:08:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02249; Tue, 11 Oct 94 05:08:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24997; Tue, 11 Oct 94 05:05:05 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA07199; Tue, 11 Oct 94 05:04:44 PDT From: Ran Atkinson Message-Id: <9410110804.ZM12372@sundance.itd.nrl.navy.mil> Date: Tue, 11 Oct 1994 08:04:02 -0500 In-Reply-To: conta@zk3.dec.com "Re: (IPng) Re: ARP, etc." (Oct 10, 23:28) References: <9410110328.AA04956@brigit.zk3.dec.com> X-Mailer: Z-Mail (3.0.1 04apr94) To: conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. Cc: bound@zk3.dec.com, atkinson@sundance.itd.nrl.navy.mil Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Oct 10, 23:28, conta@zk3.dec.com wrote: % 1. - I do consider a big whole in the specs the fact that the % information passed in the ICMP header is not sufficient (complete) % without information from the IPv6 header. % % The ICMP header information should be complete, self contained and % sufficient by itself - did I overstate it? (-:. This is reasonable and logical. [stuff deleted here for brevity] % The similarity of some of the ICMP discovery header fields to IPv6 % header fields, incidental or not, or the IPv6 header by itself, should % be of no concern for the ICMP sublayer, in relationship to the discovery % mechanism. % This has a major implication, in that almost all discovery ICMP formats % have to be reworked - I scatched what I think should be the correct formats % but I am not going to overlaod this message. I don't object to reworking the discovery formats to remove the need for the ICMP sublayer to parse out discovery data from the IPv6 base header. I'm hoping that the formats will be sorted out at the Implementer's Meeting today or tomorrow, so that everyone can start implementing and we can find all of the implementation issues before we go into RFC form. I think Dan McD had at least started on Discovery before the meeting, so he can comment more intelligently than I can (this is often true :-). % 2. - The processing model in which the first data packet of an unkown % destination media address host is sent with a "IPv6 unicast/link-layer % multicast" opens in my view the door to faulty or unexpected behavior. % % I prefer in its place the old model used by ARP, of queueing the data % packet until the media address is resolved, or another model which I % described in an earlier mail, which ... I prefer to stick with the tried and true ARP model. % I thought we were clear on this - the ICMP header being the last header, % it is processed after the processing of the preceeding IPv6 header and % extension headers, including the "authentication" completes, i.e. if an % IPv6 "authentication" extension header is present then the ICMP header % information is authenticated. Is that correct? %-- End of excerpt from conta@zk3.dec.com The above is what I intended to say in the specs. I was concerned that (a) Jim Bound had run into some implementation difficulty or that (b) the current specs are unclear or broken and need fixes. I like the original approach quoted above, but if the spec isn't implementable in a reasonable manner then we need to reconsider and try to fix any dain-bramage that is discovered. I'm quite keen on getting the security specs clear and in sufficient detail to be interoperable. I suspect there are at least unclear points in the current specs and I'm hoping more people will read the security specs and send me (or the list) comments, corrections, and clarifications. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 07:06:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02424; Tue, 11 Oct 94 07:06:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02412; Tue, 11 Oct 94 07:05:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29362; Tue, 11 Oct 94 07:02:20 PDT Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA18835; Tue, 11 Oct 94 07:01:58 PDT Received: from ftp.com by ftp.com ; Tue, 11 Oct 1994 09:59:08 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 11 Oct 1994 09:59:08 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA20982; Tue, 11 Oct 94 09:55:49 EDT Date: Tue, 11 Oct 94 09:55:49 EDT Message-Id: <9410111355.AA20982@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP From: kasten@ftp.com (Frank Kastenholz) Cc: kre@munnari.OZ.AU, atkinson@sundance.itd.nrl.navy.mil Content-Length: 1314 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 2) ARP is difficult to secure. If using ICMP or other upper layer > protocols, we can now use IPv6 Authentication Header to authenticate > replys in many cases. > > I think comments on this have been made before. If you can't > communicate until after you ARP, any kind of security is going to > be very very difficult. You have no way to get keys (other than > by manual configuration). No thanks. > > Wrong. Most of the time, the host making the ARP request _already_ > has made a DNS lookup to get the IP number for the hostname before it > makes the ARP request. With Eastlake-Kaufman, this means that the > host making the ARP request has the key for the system being ARP'd for > and for other commonly communicated with systems (e.g. the router on > that subnet). So MOST of the time, the ARP reply CAN be authenticated > fully. how do you secure the arp for the dns server? > % I can't see how ICMP's use of multicast need be any different than > % what ARP over link layer would use. > > ARP is only for IEEE 802 technologies and uses IEEE addresses. This > is hardly subnet-independent. not quite. looking over rfc1340 i see pronet, chaos, arcnet, hyperchannel, smds, frame relay, localtalk, localnet, ultralink, ax.25. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 07:21:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02468; Tue, 11 Oct 94 07:21:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02462; Tue, 11 Oct 94 07:21:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00411; Tue, 11 Oct 94 07:17:48 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA20862; Tue, 11 Oct 94 07:17:24 PDT From: Ran Atkinson Message-Id: <9410111013.ZM12543@sundance.itd.nrl.navy.mil> Date: Tue, 11 Oct 1994 10:13:15 -0500 In-Reply-To: kasten@ftp.com (Frank Kastenholz) "Re: (IPng) Re: ARP" (Oct 11, 9:55) References: <9410111355.AA20982@mailserv-D.ftp.com> X-Mailer: Z-Mail (3.0.1 04apr94) To: kasten@ftp.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP Cc: kre@munnari.OZ.AU, atkinson@sundance.itd.nrl.navy.mil Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Oct 11, 9:55, Frank Kastenholz wrote: } Subject: Re: (IPng) Re: ARP % how do you secure the arp for the dns server? The trust in the DNS data comes from the DNS data itself, which can be authenticated using techniques being developed elsewhere within the IETF. Hence, even if the address resolution is bogon for the DNS server location, the worst case is bogon DNS data is fed back and detected as bogon (i.e. a denial of service attack against DNS service). Address masquerading attacks are detectable in this scheme, hence one can keep them from succeeding in many cases. Denial of service attacks are generally impossible to entirely preclude [Voydock & Kent 83], but they can usually be _detected_ if one designs carefully. The goal here is NOT perfect security, but rather significant reduction in risk. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 08:09:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02493; Tue, 11 Oct 94 08:09:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02487; Tue, 11 Oct 94 08:09:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03680; Tue, 11 Oct 94 08:06:10 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA28284; Tue, 11 Oct 94 08:05:23 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 11 Oct 94 23:57:43 +0900 From: Masataka Ohta Message-Id: <9410111457.AA18172@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Tue, 11 Oct 94 23:57:41 JST In-Reply-To: <9410111013.ZM12543@sundance.itd.nrl.navy.mil>; from "Ran Atkinson" at Oct 11, 94 10:13 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > % how do you secure the arp for the dns server? > > The trust in the DNS data comes from the DNS data itself, > which can be authenticated using techniques being developed elsewhere > within the IETF. If you give enough static configuration parameters, yes. > Hence, even if the address resolution is bogon for > the DNS server location, the worst case is bogon DNS data is fed back > and detected as bogon (i.e. a denial of service attack against DNS > service). Address masquerading attacks are detectable in this scheme, > hence one can keep them from succeeding in many cases. With secure DNS, address masquerading is no harmful (save DoS attack) and detectable without secure ARP. > Denial of service attacks are generally impossible to entirely > preclude [Voydock & Kent 83], but they can usually be _detected_ if > one designs carefully. The goal here is NOT perfect security, but > rather significant reduction in risk. The goal is already reached. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 09:03:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02551; Tue, 11 Oct 94 09:03:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02545; Tue, 11 Oct 94 09:03:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07877; Tue, 11 Oct 94 09:00:10 PDT Received: from uu9.psi.com by Sun.COM (sun-barr.Sun.COM) id AA08421; Tue, 11 Oct 94 08:59:36 PDT Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14756 for ipng@sunroof.eng.sun.com; Tue, 11 Oct 94 12:03:42 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA06025; Tue, 11 Oct 1994 08:57:00 -0700 Message-Id: <199410111557.IAA06025@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of Sun, 09 Oct 94 23:43:53 -0700. <199410100643.XAA11162@lager.cisco.com> From: Craig Partridge Date: Tue, 11 Oct 94 08:56:52 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Are you willing to live with ARP for the next 20 years? This is the last chance you get to change the fundamentals in the hosts for that long. Tony: Allow me to take this comment and make a larger point with it. While I'm still ambivalent about the specific ARP issues, I think it is generally true that if we have technology that "basically works" we should keep it in IPv6 and resist fiddling too much. If we go back and try to fix all the nuisances in the IPv4 and ancillary protocols in IPv6 we will: (a) take 20 more years to complete the job; (b) end up fixing the new stuff (we'll introduce new failure cases) (c) be guilty of second system syndrome At some level, we have to accept that some imperfect but usable features of IPv4 will be in IPv6. Craig PS: Talking about ARP -- ARP is a media specific address resolution protocol. There's nothing to stop us from using something other than ARP on new media -- for instance, while ATM and FR call their address resolution protocol "ARP" it is not ARP as we all know it and we could just have well have called it something else. It uses different packet formats, and does not broadcast. So we could adopt a view that says we'll retain ARP on current media and work towards something better on new media. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 13:31:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02829; Tue, 11 Oct 94 13:31:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02699; Tue, 11 Oct 94 12:03:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28961; Tue, 11 Oct 94 11:59:43 PDT Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA09060; Tue, 11 Oct 94 11:59:19 PDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06029; 11 Oct 94 14:57 EDT To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: IESG Secretary Subject: (IPng) Last Call: The Recommendation for the IP Next Generation Protocol to Proposed Standard Date: Tue, 11 Oct 94 14:56:58 -0400 Message-Id: <9410111457.aa06029@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The IESG has received a request to consider "The Recommendation for the IP Next Generation Protocol" as a Proposed Standard. This is a product of the IPng Area of the IETF. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by 11 November. IESG Secretary ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 11 23:17:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03047; Tue, 11 Oct 94 23:17:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03041; Tue, 11 Oct 94 23:16:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15013; Tue, 11 Oct 94 23:13:10 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA10765; Tue, 11 Oct 94 23:12:43 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA27258; Tue, 11 Oct 1994 23:12:42 -0700 Date: Tue, 11 Oct 1994 23:12:42 -0700 From: Tony Li Message-Id: <199410120612.XAA27258@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Craig Partridge's message of Tue, 11 Oct 94 08:56:52 -0700 <199410111557.IAA06025@aland.bbn.com> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, You _can_ just say "Yes". ;-) ARP (and more importantly the entire subnet model) is one of the _more_ broken things in the protocol suite. Not less. I certainly wouldn't be able to wake up and look at myself in the morning if it were up to me and we didn't fix this problem. Now I do sympathize with all of your points -- but I also have the courage to try to provide another carrot through a protocol that serves users needs better. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 00:24:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03080; Wed, 12 Oct 94 00:24:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03074; Wed, 12 Oct 94 00:24:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17293; Wed, 12 Oct 94 00:20:29 PDT Received: from cthnet.chalmers.se ([129.16.1.2]) by Sun.COM (sun-barr.Sun.COM) id AA24643; Wed, 12 Oct 94 00:20:05 PDT Date: Wed, 12 Oct 94 08:18 +0100 From: CBORGH@astra.se To: ipng@sunroof.Eng.Sun.COM X-Vms-To: PSI%DATAPAK.CTHNET::"ipng@sunroof.Eng.Sun.com" Message-Id: <1994Oct12.081852.74.00004898@astra.se> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM get ipng draft-ipng-recommendation-00.txt ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 03:05:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03181; Wed, 12 Oct 94 03:05:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03175; Wed, 12 Oct 94 03:05:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21404; Wed, 12 Oct 94 03:02:11 PDT Received: from relay1.pipex.net ([158.43.128.4]) by Sun.COM (sun-barr.Sun.COM) id AA15979; Wed, 12 Oct 94 03:01:23 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 12 Oct 1994 11:00:51 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Wed, 12 Oct 1994 10:59:31 +0100 Date: Wed, 12 Oct 1994 10:59:31 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003900] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3900 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3900*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Forwarded message Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Jack Houldsworth for Alan Lloyd ------------------------------ Start of body part 2 Forwarded to: x400@mis@dcpmel[c=gb;a=gold 400;p=icl;o=icl;ou1=ste0906;i=j;s =houldsworth;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: jack.. I sent this in but I think some of my stuff does not get there.. can you forward this.. thanks alan -------------------------- [Original Message] ------------------------- gday, just a brief comment on this doc ipng-addr-00.txt section 2.3.3 NSAPs (what else I hear you say!) Is it possible to just say that NSAPs are supported until the format is final.. Jack h is submitting some text for this for the SIPP doc.. My preference is to just say. 2.3.3 NSAP Addresses NSAPs are supported in the IP6 addressing scheme. The format of the NSAP as carried is fully defined in [NSAP]. NSAPs are usually Unicast but can be Multicast if used for discovery or announcement purposes (eg ISH). (If the proposal is accepted for HbH Options for NSAP address extension the following text can be added).. The general format for the NSAP in the IP6 header is: 0000001/g + Length + 14 bytes of address Where the total length of the NSAP exceeds the basic form (14 bytes), the NSAP address extension option in the Hop By Hop Options can be used. The use of this option is indicated by the value in the NSAP Length field. The other comments on the document really relate to the use of terms "domain", "providor" and "subscriber" which I have covered in another post.. Thanks and Regards Alan@Oz ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 03:07:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03193; Wed, 12 Oct 94 03:07:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03187; Wed, 12 Oct 94 03:07:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21446; Wed, 12 Oct 94 03:03:52 PDT Received: from relay1.pipex.net ([158.43.128.4]) by Sun.COM (sun-barr.Sun.COM) id AA18101; Wed, 12 Oct 94 03:02:53 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 12 Oct 1994 11:02:26 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; Relayed; Wed, 12 Oct 1994 11:00:25 +0100 Date: Wed, 12 Oct 1994 11:00:25 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003901] X400-Content-Type: P2-1984 (2) Content-Identifier: 3901 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3901*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Forwarded Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 Jack for Alan Lloyd ------------------------------ Start of forwarded message 1 Delivery-Date: Wed, 12 Oct 1994 05:53:30 +0100 X400-Content-Type: P2-1984 (2) X400-Originator: /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net Original-Encoded-Information-Types: ia5 text (2) X400-Recipients: j.houldsworth@ste0906.wins.icl.co.uk Date: Wed, 12 Oct 1994 04:13:40 +0100 From: /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net Message-ID: <"941011 08:54:09*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: j.houldsworth@ste0906.wins.icl.co.uk (Non Receipt Notification Requested), "X400@MIS@DCPMEL[C=AU;A=TELEMEMO;P=DATACRAFT;O=SMTP;S=IPNG(A)SUNROOF.ENG.SUN.COM;]":; (Non Receipt Notification Requested) Subject: ADDRESSING ARCH.. COMMENTS Forwarded to: x400@mis@dcpmel[c=gb;a=gold 400;p=icl;o=icl;ou1=ste0906;i=j;s=houldsworth;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: jack.. ditto with this one... I do not seem to get my messages back? please send to the list.. ta regards alan -------------------------- [Original Message] ------------------------- gday, some comments on Unicast Address allocation ipng-IPv6-addr-01.txt I have some overall views about the terminology used, but I am sure this has been discussed at length and is set in concrete.. However, perhaps others have the same view and would like the terms clarified.. INTRO The terms Domain, Providor, Subscriber are used within the IT industry and have well understood semanitics. Network Addresses dictate where things are in either a logical or geographic manner. Domain - That which one has dominion over, estate, -defines boundaries of ownership, authority or function.. Subscribe - to provide signature, to pay for or promise payment, etc. Provide - to supply, to furnish, etc. COMMENTS I feel that applying the Provider, Subscriber terms to network addresses implies operational characteristics to something which is just a routing scheme. The terms also get explained as "those with backbones" and "sites".. Therefore, the term's usage in the context of network address structure also implies network topology and bandwidth capability. Such implied meaning to address forms certainly complicates matters with network design and understanding. So implying such characteristics from an address form I feel is wrong. My preference is to see that an address form is aligned in some way between its registration hierarchy and its routing hierarchy (logical and/or geographic). This is because one cannot dictate or imply network topologies (as implemented) or communications capacities - from an address form. These choices are taken on commercial (and technical) grounds. The best approach to addressing i feel is to determine the Registration Authorities and the Sub RA and the Sub-Sub RAs etc.. on a geographic and logical basis and then slice (allocate) the addresses accordingly. The major point here is.. it is not the number of address bits which is the driving force.. It is the way in which it can be pragmatically managed over the planet which is important. The issue of TRDS, quantity of routing information, optimal routes, redundant paths, etc will sort themselves out as the network evolves.. I think that task is impossible to dictate from address field definition.. However, the address field if organised correctly will imply authority/regions, organisations, routing domains, subnets and nodes. Specifically the text in para 2 of Scope " Domains that share..." should be reworded and also " routing domain" should be used explicitly. This is because "Domain" may also be used in related documents to bound network functions such as "Management Domain", Administrative Domain", Security Domain" etc. Section 6. This section also tries to relate addresses with topologies and national boundaries.. again this reinforces the issues of address admin. Finally... the doc does expose the issues with global addressing and network architectures .. which is good.. How is it progressed from here..?? eg. are Providor/Subscriber terms now concrete? Is there any work being done on RAs and procedures for address management? Regards Alan@Oz ------------------------------ End of forwarded message 1 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 05:17:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03366; Wed, 12 Oct 94 05:17:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03360; Wed, 12 Oct 94 05:16:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24383; Wed, 12 Oct 94 05:13:17 PDT Received: from ceres.fokus.gmd.de ([192.35.149.15]) by Sun.COM (sun-barr.Sun.COM) id AA06691; Wed, 12 Oct 94 05:12:46 PDT Message-Id: <9410121212.AA06691@Sun.COM> Received: from fokus.gmd.de by ceres.fokus.gmd.de id <21190-0@ceres.fokus.gmd.de>; Wed, 12 Oct 1994 13:15:29 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng Implementation Project Date: Wed, 12 Oct 1994 13:15:29 +0100 From: Lutz Henckel Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dear Colleagues, GMD FOKUS is planning an BERKOM project to design and implement a so-called Multimedia Transport System / Next Generation (MMT/NG) which will be close to the IETF activities (ipng, sipp, ngtrans, avt, rsvp) in this area. The global protocol architecture is shown in the following picture: +------------+ | RTP&RTCP | +------------+-----------+-----------+ | UDP | TCP |Reliable MC| +--------+------------+-----------+-----------+ | |+-----------+ +----------+| | Q.2931 || ICMP&IGMP | IPv4:SIPP | RSVP || | |+-----------+ +----------+| +--------+------------+-----------+-----------+ | SAAL | AAL5 | | | +--------+------------+ N-ISDN | LAN | | ATM | | | +---------------------+-----------+-----------+ The project will start at the end of this year. The implementation will be done for Sun SPARCstations under Solaris 2.x. For us and hopefully also for other implementators it is not possible and reasonable to implement all these protocols by ourself. So we look for other implementor groups which go in the same direction we can cooperate with. We would like to know who is implementing which protocols for wich workstations (and routers) under which operating systems and if the software is available for us as well as the conditions to get it. We are able and willing to implement the supplementary protocols and will make this available for you. Henning Schulzrinne will coordinate the implementation of RTP and me the implementation of IPng etc. We are grateful to get any hints about your implementation plans. If there is not a collection of this information yet available I will do this via our WWW server. Thank you in advance ___________________________________________________________________ Lutz Henckel Address : Research Institute for Open Communication Systems GMD FOKUS, Hardenbergplatz 2, D-10623 Berlin, Germany Phone : ++49 / (0)30 / 254 99 - 237 Fax : ++49 / (0)30 / 254 99 - 202 X.400 : G=lutz;S=henckel;OU=fokus;OU=berlin;P=gmd;A=d400;C=de Internet : lutz.henckel@fokus.gmd.de WWW : http://www.fokus.gmd.de/htbin/info/nthp/hel ___________________________________________________________________ ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 06:05:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03398; Wed, 12 Oct 94 06:05:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03392; Wed, 12 Oct 94 06:05:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25722; Wed, 12 Oct 94 06:01:53 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA13925; Wed, 12 Oct 94 06:01:32 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA01225; Wed, 12 Oct 1994 14:01:26 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA07319; Wed, 12 Oct 1994 14:01:21 +0100 Message-Id: <9410121301.AA07319@dxcoms.cern.ch> Subject: Re: (IPng) Forwarded message To: ipng@sunroof.Eng.Sun.COM Date: Wed, 12 Oct 1994 14:01:21 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <"3900*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> from "J.Houldsworth@ste0906.wins.icl.co.uk" at Oct 12, 94 10:59:31 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 501 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan > > section 2.3.3 NSAPs (what else I hear you say!) > There is a BOF on this whole area at San Jose. There will be a discussion draft for this BOF posted as an Internet Draft imminently. I think that wordsmithing has to be left till after that meeting. For now, I would actually prefer that the text say only "For further study". We surely do not have consensus on what it should say. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 07:19:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03428; Wed, 12 Oct 94 07:19:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03422; Wed, 12 Oct 94 07:19:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28993; Wed, 12 Oct 94 07:15:23 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA27855; Wed, 12 Oct 94 07:14:58 PDT Received: from relay.imsi.com by wintermute.imsi.com id KAA24600 for ; Wed, 12 Oct 1994 10:12:30 -0400 Received: from snark.imsi.com by relay.imsi.com id KAA24149 for ; Wed, 12 Oct 1994 10:12:19 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02433; Wed, 12 Oct 94 10:12:18 EDT Message-Id: <9410121412.AA02433@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 11 Oct 1994 23:12:42 PDT." <199410120612.XAA27258@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Wed, 12 Oct 1994 10:12:18 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > ARP (and more importantly the entire subnet model) is one of the _more_ > broken things in the protocol suite. Not less. > > I certainly wouldn't be able to wake up and look at myself in the morning > if it were up to me and we didn't fix this problem. Now I do > sympathize with all of your points -- but I also have the courage to > try to provide another carrot through a protocol that serves users > needs better. Pardon my intrusion. I'm just a user. My area of expertise is security. I generally just observe here and try to point things out. This, however, has my interest piqued. What, exactly, is so broken about ARP and the subnet model? I mean, they WORK, ever day, and well. I haven't seen a broadcast storm on a properly configured network since 1989. My clients depend on their IP networks every day, for lots of extraordinarily important work, and everything functions nicely. None of the other networking technologies my clients deploy function properly. The IPv6 effort is here to fix certain pressing problems: the expansion of the address space (easily done in the sense that we just needed more bits) and the problem of scaling routing for the forseeable future (which is way beyond my area of expertise and I leave to the routing gurus). A few other things have come up like security (which is sort of orthogonal and which we seem to have a reasonable handle on right now.) There are some secondary issues that would be nice to fix but won't break us (the 64kbyte size limitation on packets, for example, which when networks get REALLY fast in a decade will come back to bite us.) However, they aren't neck-breakers. The fact that everyone is taking time to clean up certain defects at while we have the chance seems nice, but I must admit I'm far more concerned about things like 64kbyte/packet size limitations going forward than I am about, say, ARP. Maybe ARP isn't aesthetic to some people, but it functions very well. The only problems I see on client networks these days come from attempts to route Novell and IP traffic on the same segment, with Novell usually breaking functioning IP networks. I don't see these ARP broadcast storms every day, and haven't at many, many sites. Could someone please explain what is so horrible about ARP? In particular, what is so broken that we have to worry so much about it? I've heard lots of worrysome things about the new IP -- things like the possibility that my TCP connections which I keep up for months these days might be brought down prematurely to handle renumbering, or that no one is thinking of pro-active ways to inform end nodes of routing changes. However, ARP has never disturbed me. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 07:21:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03440; Wed, 12 Oct 94 07:21:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03434; Wed, 12 Oct 94 07:21:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29183; Wed, 12 Oct 94 07:17:54 PDT Received: from BBN.COM ([128.89.0.122]) by Sun.COM (sun-barr.Sun.COM) id AA28470; Wed, 12 Oct 94 07:17:23 PDT Message-Id: <9410121417.AA28470@Sun.COM> From: John Day To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <1994Oct12.081852.74.00004898@astra.se> Date: Wed, 12 Oct 94 10:13:22 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM get ipng draft-ipng-recommendation-00.txt ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 08:07:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03499; Wed, 12 Oct 94 08:07:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03493; Wed, 12 Oct 94 08:07:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02945; Wed, 12 Oct 94 08:03:26 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA09650; Wed, 12 Oct 94 08:03:01 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24127; Wed, 12 Oct 1994 16:02:48 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15348; Wed, 12 Oct 1994 16:02:46 +0100 Message-Id: <9410121502.AA15348@dxcoms.cern.ch> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Wed, 12 Oct 1994 16:02:45 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410121412.AA02433@snark.imsi.com> from "Perry E. Metzger" at Oct 12, 94 10:12:18 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 528 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, Many sites don't have ARP storms, according to you. Many sites do have ARP storms, according to me. We are both correct. ARP causes storms on a large number of sites, including of course sites with insufficient monitoring, so that they are unaware of the storms except for their effect on response time. Yes, a network in which all implementations are correct, and all configurations are correct, has no ARP storms, but not all networks can be in this happy situation. Tony Li is 150% correct on this one. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 08:41:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03544; Wed, 12 Oct 94 08:41:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03538; Wed, 12 Oct 94 08:41:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06269; Wed, 12 Oct 94 08:37:55 PDT Received: from atlas.xylogics.com ([132.245.33.7]) by Sun.COM (sun-barr.Sun.COM) id AA18995; Wed, 12 Oct 94 08:37:24 PDT Received: by atlas.xylogics.com id AA28072 (5.65c/UK-2.1-940401); Wed, 12 Oct 1994 11:38:22 -0400 From: Gary Scott Malkin Date: Wed, 12 Oct 1994 11:38:22 -0400 Message-Id: <28072.199410121538@atlas.xylogics.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Brian Carpenter CERN-CN"'s message of Wed, 12 Oct 1994 16:02:45 +0100 (MET) <9410121502.AA15348@dxcoms.cern.ch> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Yes, a network in which all implementations are correct, > and all configurations are correct, has no ARP storms, > but not all networks can be in this happy situation. Just because some vendors screwed up their implementations, and some administrators don't know how to use what they have, correctly is no reason to crucify the underlying protocol. I don't think there is any protocol in existence which cannot be made to appear bad through misimplementation and misconfiguration. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two! ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 09:21:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03568; Wed, 12 Oct 94 09:21:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03562; Wed, 12 Oct 94 09:21:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10522; Wed, 12 Oct 94 09:17:58 PDT Received: from ski.utah.edu ([128.110.124.10]) by Sun.COM (sun-barr.Sun.COM) id AB28838; Wed, 12 Oct 94 09:17:28 PDT Received: (from haas@localhost) by ski.utah.edu (8.6.9/8.6.9) id KAA18073; Wed, 12 Oct 1994 10:22:52 -0600 From: Tired of the Information Superhype Message-Id: <199410121622.KAA18073@ski.utah.edu> Date: Wed, 12 Oct 94 10:22:52 MDT Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM In-Reply-To: ipng@sunroof.Eng.Sun.COM, Wed, 12 Oct 1994 10:12:18 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > ARP (and more importantly the entire subnet model) is one of the _more_ > broken things in the protocol suite. Not less. > > I certainly wouldn't be able to wake up and look at myself in the morning > if it were up to me and we didn't fix this problem. Now I do > sympathize with all of your points -- but I also have the courage to > try to provide another carrot through a protocol that serves users > needs better. and Perry Metzger replies: >This, however, has my interest piqued. What, exactly, is so >broken about ARP and the subnet model? I mean, they WORK, ever day, >and well... I agree. Subnets do require some administration, but they also partition the network into cells, most of which can continue to function reliably when some portion of the network is disrupted. Furthermore we consistently see that most network traffic is local, so unless there's a drastic change in traffic patterns I don't think we'd gain much by eliminating subnetting. Don't forget that, although we have to pay a labor cost to break the network into cells, we also have to pay a cost when network failures propagate outside the immediate area of the failure. If subnetting were eliminated we'd have to invent another method to partition the network for reliability. -- Walt ------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 09:34:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03584; Wed, 12 Oct 94 09:34:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03578; Wed, 12 Oct 94 09:33:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11783; Wed, 12 Oct 94 09:30:13 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA01347; Wed, 12 Oct 94 09:29:36 PDT Received: from relay.imsi.com by wintermute.imsi.com id MAA25117 for ; Wed, 12 Oct 1994 12:26:17 -0400 Received: from snark.imsi.com by relay.imsi.com id MAA24993 for ; Wed, 12 Oct 1994 12:26:06 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02661; Wed, 12 Oct 94 12:26:06 EDT Message-Id: <9410121626.AA02661@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Wed, 12 Oct 1994 16:02:45 BST." <9410121502.AA15348@dxcoms.cern.ch> X-Reposting-Policy: redistribute only with permission Date: Wed, 12 Oct 1994 12:26:05 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Brian Carpenter CERN-CN" says: > Perry, > > Many sites don't have ARP storms, according to you. > Many sites do have ARP storms, according to me. > > We are both correct. Okay. What aspects of the causes of these storms will not continue to be a problem under the multicasted icmp discovery model. This is an honest question. Not having seen such storms in a very long time, I no longer have any idea of what could be causing them, and no one thus far has made it clear how the multicast ICMP model would avoid them. (One wonders, of course, if the multicast ICMP model might not have other gotchas that we don't yet know about. I wonder what might happen to implementations that accidently forward such packets, for example...) Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 09:35:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03596; Wed, 12 Oct 94 09:35:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03590; Wed, 12 Oct 94 09:35:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11996; Wed, 12 Oct 94 09:32:01 PDT Received: from uu2.psi.com ([128.145.228.2]) by Sun.COM (sun-barr.Sun.COM) id AA01409; Wed, 12 Oct 94 09:30:52 PDT Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15955 for ipng@sunroof.eng.sun.com; Wed, 12 Oct 94 12:28:36 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA07230; Wed, 12 Oct 1994 09:27:23 -0700 Message-Id: <199410121627.JAA07230@aland.bbn.com> To: Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of Wed, 12 Oct 94 16:02:45 +0100. <9410121502.AA15348@dxcoms.cern.ch> From: Craig Partridge Date: Wed, 12 Oct 94 09:27:22 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian: Based on your note, if one had to summarize the requirements for replacing ARP would they simply be: Retain these ARP features: * fault tolerance (i.e. if bridge fails, folks on the same side of the bridge can still communicate) * work on networks without routers (generally considered a nice feature) But add this feature * sharply reduce chance of broadcast (or multicast) storms Have I got this right? Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 11:56:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03889; Wed, 12 Oct 94 11:56:25 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03883; Wed, 12 Oct 94 11:56:15 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA20207; Wed, 12 Oct 1994 11:52:37 -0700 Date: Wed, 12 Oct 1994 11:52:37 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410121852.LAA20207@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9410121417.AA28470@Sun.COM> Subject: (IPng) re: [get ipng draft-ipng-recommendation-00.txt] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John Day writes: > get ipng draft-ipng-recommendation-00.txt Currently there are no documents available for retrieval on the IPng list. If there were the request should be sent to majordomo@sunroof.eng.sun.com, not to the list itself. Internet drafts are available from the usual ID directories. List management instructions are attached. Bob IPng List Instructions _________________________________________________________________________ >>>> info ipng To post a message to the list, send it to ipng@sunroof.eng.sun.com. This list is an open, automatically maintained mailing list. You may subscribe by sending a message which contains in the message body: subscribe ipng to the address majordomo@sunroof.eng.sun.com. This will subscribe the address from which you sent the request to the mailing list. If you expect to be sending contributions to the list from multiple addresses, please notify ipng-approval@sunroof.eng.sun.com of *all* addresses you expect to post from. Only postings from known subscribers are re-distributed to the list without human intervention. (This is to prevent mail loops.) You may unsubscribe by sending a message with the body: unsubscribe ipng to majordomo@sunroof.eng.sun.com. >>> DO NOT SEND ADMINISTRATIVE QUERIES ABOUT THE LIST TO ipng. All routine queries should be sent to majordomo@sunroof.eng.sun.com. This includes adding, removing, or changing any subscriber(s) e-mail address. If you need human intervention, send to ipng-approval@sunroof.eng.sun.com. >>>> help This is Brent Chapman's "Majordomo" mailing list manager, version 1.92. In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. It understands the following commands: subscribe [
] Subscribe yourself (or
if specified) to the named . unsubscribe [
] Unsubscribe yourself (or
if specified) from the named . get Get a file related to . index Return an index of files you can "get" for . which [
] Find out which lists you (or
if specified) are on. who Find out who is on the named . info Retrieve the general introductory information for the named . lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo@sunroof.eng.sun.com". Commands in the "Subject:" line NOT processed. If you have any questions or problems, please contact "Majordomo-Owner@sunroof.eng.sun.com". ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 11:57:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03901; Wed, 12 Oct 94 11:57:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03895; Wed, 12 Oct 94 11:57:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26999; Wed, 12 Oct 94 11:53:53 PDT Received: from Arizona.EDU ([128.196.128.233]) by Sun.COM (sun-barr.Sun.COM) id AA01234; Wed, 12 Oct 94 11:53:25 PDT Received: from Arizona.EDU by Arizona.EDU (PMDF V4.3-10 #2381) id <01HI6RTB1LAUBCB9YQ@Arizona.EDU>; Wed, 12 Oct 1994 11:46:27 -0700 (MST) Date: Wed, 12 Oct 1994 11:46:27 -0700 (MST) From: Aaron Leonard Subject: (IPng) Against ARP To: ipng@sunroof.Eng.Sun.COM Message-Id: <01HI6RTB1UY0BCB9YQ@Arizona.EDU> X-Vms-To: IN%"ipng@sunroof.Eng.Sun.COM" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Although ARP has served us well for many years, it seems to me that we should be able to do better as we build a protocol that will last into the middle of the next century. My view is that ARP has several critical limitations, all of which are well addressed by the new ideas in Mr. Simpson's "Neighbor Discovery" draft. My views are driven, in large part, by a strong preference for the "smart router/dumb ES" model. Where feasible, routing information should be centralized, in order to provide for better manageability and autoconfigurability. Information that must be known by n ESes is costly in terms of ES implementations and human management/troubleshooting. It's much better to have that information handled centrally by n/100 (or whatever) ISes that are built and run at some known level of competence. I wanted to come up with a Letterman-like Top 10 list of reasons of why ARP is inadequate, but I couldn't quite manage that many ... so here are my top four reasons, in ascending order of significance, why ARP isn't quite good enough. 4. ARP uses the link-layer broadcast address. This wastes cycles on link-attached systems that are only interested in other network-layer protocols. I don't know ARP didn't use link-layer multicast in the first place - laziness, I assume - but not to do so is unacceptably antisocial. (Saying "who cares" about IPX/AppleTalk/DECnet/OSI/IPv4 nodes strikes me as an irresponsible approach.) 3. ARP wastes at least one round-trip time in setting up a path. In many observable cases, it's much worse than that, as an initial IP packet aimed at an unknown MAC-layer address will be discarded during the ARP process, requiring a layer-4 timeout and retransmission. This waste may be no big deal on a large, long session, but an application that requires many extremely small, extremely sporadic transactions will definitely suffer. 2. ARP does not have any sensible way of handling mapping lifetimes. At present, the cache lifetime policy is managed independently by each ES. RFC-1122 has some extremely vague guidelines on how to age out ARP cache entries, and I doubt that there is any coherence as to how the various implementations out there handle this. Determining the lifetime of a media address mapping entry is properly the responsibility of the address owner (the destination address) or the manager of the addresses (the "smart router".) (This is analogous to the way in which a DNS server, not the client, specifies how long RRs are to be cached.) It is the destination and/or the "smart router" who will have some idea how long the mapping is likely to be valid. The source ES has no basis for determining such a lifetime - the best it can do is to come up with an across-the-board lifetime, which is bound to provide a mediocre compromise. We must *ensure* that connections be able easily to ride out changes in media address (as will happen if, say, the destination board is swapped, or if the application moves from system to system, or if DECnetIV is started on the destination.) 1. ARP requires that each ES (I *hate* the term "host" - a CSU/DSU with an SNMP stack is *not* a "host") assume knowledge of the hierarchical structure of layer-3 addresses. (That is, the ES must know what its subnet mask is.) Aside from the manageability issue - how do we tell all these myriad ESes what their subnet masks are? And how do we find out what their masks are, when something's misbehaving? - I don't believe that this will work AT ALL well in a world that moves from physical, slowly-changing LANs to dynamically changing "virtual LANs". Right now, I'd like to be able to grab a cable and swing a segment from one "subnet" to another, or to plug several such segments together to form a "super subnet", etc., without significantly impacting any live sessions' network connectivity. In the future, I should be able to do this under software control. I might even expect to see my switching fabric handle this process: it could meter traffic levels and monitor traffic patterns, and dynamically move stations and segments into different virtual "subnets" as demand dictates. I don't see how ARP can handle this scenario. If people require a real-world example of how ARP fails to meet our needs today, they need look no further than to our proliferating CIDR-addressed LANs. In cases where a physical LAN addressed from a CIDR block uses a prefix smaller than an old class C, most ESes on that LAN are unable directly to communicate with each other, because they "know" what their prefix is, and that it can't be any smaller than 24 bits. This is just a ridiculous situation, and rectifiying it requires going around to the dozens or hundreds of vendors involved and getting them to change their kernels. Feh! I'm quite confident that it will be many, many years before IPv6 is more widespread than IPv4. We should not fear that we lack the time to get things right - because if we don't get them right, it'll be a long, long while till as good a chance appears again. Aaron Aaron Leonard (AL104), University of Arizona Network Operations, Tucson AZ 85721 \ Don't lock yourself into open systems. / ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 16:37:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04100; Wed, 12 Oct 94 16:37:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04094; Wed, 12 Oct 94 16:37:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29285; Wed, 12 Oct 94 16:33:54 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA27305; Wed, 12 Oct 94 16:33:33 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA02866; Wed, 12 Oct 1994 16:33:32 -0700 Date: Wed, 12 Oct 1994 16:33:32 -0700 From: Tony Li Message-Id: <199410122333.QAA02866@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Wed, 12 Oct 1994 10:12:18 -0400 <9410121412.AA02433@snark.imsi.com> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry writes: What, exactly, is so broken about ARP and the subnet model? Sounds like an invitation to rant. ;-) Ever tried to deal with multiple subnets on the same wire? Ever been burned by proxy arp? Walt is absolutely correct -- we must have some mechanism to partition the network and provide abstraction. However, the current model of one subnet per wire is incredibly restrictive. [No, I'm not arguing for ISIS area routing -- the design space is even bigger than that.] Consider what happens right now if I have Host A, Host B and Router C on the same subnet where A and B are not in the same subnet. To exchange packets, you either have to do warped configuration (tell A that it can route directly to B and vice versa) OR the two hosts talk via the router, with everything taking two hops on the LAN. This is a clear case where the inflexibility in the model results in a horrible result. The way that ARP gets used is another manifestation of the problem. Proxy ARP is simply telling lies. Why? Because there's no reasonable mechanism in the protocol for doing first hop/last hop routing. What would be better? Well, we need a more flexible partitioning and abstraction model. Some things that I'd put forth as requirements: - Hosts don't need to know which partition they're in. - Hosts don't need to know which partition the destination is in. - Hosts can be in multiple partitions simultaneously. - Partitions can overlap, and not necessarily nest. - Partitions can be discontigous. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 19:01:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04213; Wed, 12 Oct 94 19:01:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04207; Wed, 12 Oct 94 19:01:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10776; Wed, 12 Oct 94 18:57:59 PDT Received: from watson.ibm.com ([129.34.139.4]) by Sun.COM (sun-barr.Sun.COM) id AA21948; Wed, 12 Oct 94 18:57:29 PDT Message-Id: <9410130157.AA21948@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8959; Wed, 12 Oct 94 21:57:35 EDT Date: Wed, 12 Oct 94 21:56:26 EDT From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Cc: tli@cisco.com Subject: (IPng) ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony, How about adding the following to your requirements: - A pair of entities connected to a common Data Link subnetwork should be able to communicate directly with each other, without intervening routers. This should not depend on a particular way IP addresses are assigned to the entities. It shouldn't require any entity to maintain information about all the other entities connected to a common Data Link subnetwork. - It should be possible to constrain the number of entities that involved into IP to MAC address mapping to a number which is significantly less than the total number of entities attached to the Data Link subnetwork - Local/remote decision should be adaptive enough (adaptability should be at least comparable to the adaptability of routing protocols) when a host changes its location in a network. The adaptability applies to both the mobile host and to all the other hosts that communicate with the mobile host. Yakov ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 20:00:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04248; Wed, 12 Oct 94 20:00:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04242; Wed, 12 Oct 94 19:59:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13527; Wed, 12 Oct 94 19:56:15 PDT Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA27068; Wed, 12 Oct 94 19:55:54 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA16148; Wed, 12 Oct 94 19:50:56 -0700 Received: by xirtlu.zk3.dec.com; id AA01096; Wed, 12 Oct 1994 22:50:47 -0400 Message-Id: <9410130250.AA01096@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ARP In-Reply-To: Your message of "Wed, 12 Oct 94 21:56:26 EDT." <9410130157.AA21948@Sun.COM> Date: Wed, 12 Oct 94 22:50:41 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hosts and what they need to know and have knowledge of was discussed at the implementors meeting at length. Minutes will be sent to convey that discussion to the mail list which will further this discussion. As for me no comment for now but I don't support what I have heard so far as a host implementor just getting back to mail regarding what hosts need to know. This should not be new as I have been very focal on this pre-IPng decision too. I suggest that IPng build standards and let the market decide what systems do with network technology standards and not try to be all seeing and all knowing for the future because it will be wrong no matter what we do and implementors will have to make it work. So work on the basics and not rule sets. Give the market choices not mandates. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 20:19:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04284; Wed, 12 Oct 94 20:19:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04278; Wed, 12 Oct 94 20:18:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14746; Wed, 12 Oct 94 20:15:13 PDT Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA28571; Wed, 12 Oct 94 20:14:32 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 13 Oct 94 12:06:23 +0900 From: Masataka Ohta Message-Id: <9410130306.AA27887@necom830.cc.titech.ac.jp> Subject: Re: (IPng) ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 94 12:06:21 JST In-Reply-To: <9410130157.AA21948@Sun.COM>; from "yakov@watson.ibm.com" at Oct 12, 94 9:56 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Tony, > > How about adding the following to your requirements: > - It should be possible to constrain the number of entities > that involved into IP to MAC address mapping to > a number which is significantly less than the total number of entities > attached to the Data Link subnetwork Isn't it better to say: - The number of entities attached to a single Data Link subnetwork should be small. Large subnets are unmanageable in various ways. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 20:25:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04300; Wed, 12 Oct 94 20:25:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04294; Wed, 12 Oct 94 20:25:37 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15422; Wed, 12 Oct 94 20:21:57 PDT Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA29538; Wed, 12 Oct 94 20:21:36 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA17202; Wed, 12 Oct 94 20:15:18 -0700 Received: by xirtlu.zk3.dec.com; id AA02931; Wed, 12 Oct 1994 23:15:09 -0400 Message-Id: <9410130315.AA02931@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Wed, 12 Oct 94 11:38:22 EDT." <28072.199410121538@atlas.xylogics.com> Date: Wed, 12 Oct 94 23:15:03 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Just because some vendors screwed up their implementations, and some >administrators don't know how to use what they have, correctly is no >reason to crucify the underlying protocol. I don't think there is any >protocol in existence which cannot be made to appear bad through >misimplementation and misconfiguration. I am finding that I have to agree with this statement. So far I think all arguments against ARP have been defeated technically including mine. If you make a list of whats wrong with ARP technically most items appear to be on the list of bad implementations. Some (me included) from SIP (one P) had this sense/vision that what ARP does as a function would enjoy greater independence for future functions if moved to be processed at the ICMP layer. But maybe that vision was wrong and misguided. Or maybe it has not been explained well enough yet???? I am not sure which it is tonight? I think the sense/vision was: 1) to continue to support the request/reply model of ARP. 2) add data during that communications about the network (lifetime, preference, prefix (type, size, changes), etc.) 3) support multicast 4) permit solicitation/advertisement (hosts and routers I believe) 5) use ICMP to implement the sense/vision so it is more extensible and could support authentication if required for that packet. I don't think this kills the ARP model. I don't think this is radical. I don't think this is a major change in the model anymore than other technical evolutions we must accomdate in the IETF. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 22:12:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04322; Wed, 12 Oct 94 22:12:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04316; Wed, 12 Oct 94 22:12:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18636; Wed, 12 Oct 94 22:08:54 PDT Received: from clix.aarnet.edu.au ([130.102.128.59]) by Sun.COM (sun-barr.Sun.COM) id AA07364; Wed, 12 Oct 94 22:08:33 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 13 Oct 1994 15:03:41 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 13 Oct 1994 15:06:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 13 Oct 1994 15:07:11 +1000 Date: Thu, 13 Oct 1994 15:07:11 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Oct 13 15:07:10 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 100715131094 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <100715131094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Tony, >> >> How about adding the following to your requirements: >> - It should be possible to constrain the number of entities >> that involved into IP to MAC address mapping to >> a number which is significantly less than the total number of entities >> attached to the Data Link subnetwork >Isn't it better to say: > - The number of entities attached to a single Data Link subnetwork > should be small. By small, how small do you imagine? Is that 200-300 or 2,000 to 3,000? >Large subnets are unmanageable in various ways. Agreed but the size usually is a cost/effectiveness tradeoff. Architectural limitations tend to nark implementers if there is not a physical reason for the limitation. > Masataka Ohta Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 22:37:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04342; Wed, 12 Oct 94 22:37:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04336; Wed, 12 Oct 94 22:37:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19278; Wed, 12 Oct 94 22:33:37 PDT Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA09005; Wed, 12 Oct 94 22:33:07 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 13 Oct 94 14:25:46 +0859 From: Masataka Ohta Message-Id: <9410130526.AA28646@necom830.cc.titech.ac.jp> Subject: Re: (IPng) ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 94 14:25:45 JST In-Reply-To: <100715131094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS>; from "Jeff.Latimer@FINANCE.ausgovfinance.telememo.au" at Oct 13, 94 3:07 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >Isn't it better to say: > > > - The number of entities attached to a single Data Link subnetwork > > should be small. > > By small, how small do you imagine? Is that 200-300 or 2,000 to 3,000? 62 or, at most, 254. I think CERN is demonstrating that a bridge-connected subnet of 1,000 hosts is unmanageable. > >Large subnets are unmanageable in various ways. > > Agreed but the size usually is a cost/effectiveness tradeoff. Architectural > limitations tend to nark implementers if there is not a physical reason for the > limitation. It might be a good idea to enforce small subnet by protocol specification, such as forcing the subnet boundary at the last octet. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 12 22:51:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04358; Wed, 12 Oct 94 22:51:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04352; Wed, 12 Oct 94 22:51:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19672; Wed, 12 Oct 94 22:47:48 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA09968; Wed, 12 Oct 94 22:47:28 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA16432; Wed, 12 Oct 1994 22:47:28 -0700 Date: Wed, 12 Oct 1994 22:47:28 -0700 From: Tony Li Message-Id: <199410130547.WAA16432@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Masataka Ohta's message of Thu, 13 Oct 94 12:06:21 JST <9410130306.AA27887@necom830.cc.titech.ac.jp> Subject: (IPng) ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > How about adding the following to your requirements: > - It should be possible to constrain the number of entities > that involved into IP to MAC address mapping to > a number which is significantly less than the total number of entities > attached to the Data Link subnetwork Isn't it better to say: - The number of entities attached to a single Data Link subnetwork should be small. Large subnets are unmanageable in various ways. First, please note that your two statements are NOT identical. I would certainly agree that a large network layer subnet is unmanageable. However, a large scale data link subnetwork (e.g., X.25, FR, SMDS, ATM) clearly IS manageable on the large scale. The terminology is confused. The model is confused. Is it any wonder the results are confused? Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 00:33:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04414; Thu, 13 Oct 94 00:33:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04408; Thu, 13 Oct 94 00:33:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22457; Thu, 13 Oct 94 00:30:07 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA20728; Thu, 13 Oct 94 00:29:46 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10252; Thu, 13 Oct 1994 08:29:44 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19299; Thu, 13 Oct 1994 08:29:42 +0100 Message-Id: <9410130729.AA19299@dxcoms.cern.ch> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 08:29:42 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199410121627.JAA07230@aland.bbn.com> from "Craig Partridge" at Oct 12, 94 09:27:22 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 823 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, You're correct IMO. Brian >--------- Text sent by Craig Partridge follows: > > > Brian: > > Based on your note, if one had to summarize the requirements for replacing > ARP would they simply be: > > Retain these ARP features: > > * fault tolerance (i.e. if bridge fails, folks on the same side of the > bridge can still communicate) > > * work on networks without routers (generally considered a nice feature) > > But add this feature > > * sharply reduce chance of broadcast (or multicast) storms > > Have I got this right? > > Craig > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 00:42:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04426; Thu, 13 Oct 94 00:42:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04420; Thu, 13 Oct 94 00:42:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22719; Thu, 13 Oct 94 00:38:26 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA21219; Thu, 13 Oct 94 00:38:05 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11171; Thu, 13 Oct 1994 08:38:02 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19713; Thu, 13 Oct 1994 08:38:00 +0100 Message-Id: <9410130738.AA19713@dxcoms.cern.ch> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 08:38:00 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410121626.AA02661@snark.imsi.com> from "Perry E. Metzger" at Oct 12, 94 12:26:05 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1315 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, > > "Brian Carpenter CERN-CN" says: > > Perry, > > > > Many sites don't have ARP storms, according to you. > > Many sites do have ARP storms, according to me. > > > > We are both correct. > > Okay. What aspects of the causes of these storms will not continue to > be a problem under the multicasted icmp discovery model. This is an > honest question. Not having seen such storms in a very long time, I no > longer have any idea of what could be causing them, and no one thus > far has made it clear how the multicast ICMP model would avoid them. Very good question. If a box running the multicast icmp code generates icmp multicasts when it shouldn't, then I see no reason why we would not get multicast storms. It's difficult to construct precise scenarios (when we see storms they are usually due to interaction between TWO slightly broken implementations and very complex to understand). > > (One wonders, of course, if the multicast ICMP model might not have > other gotchas that we don't yet know about. I wonder what might happen > to implementations that accidently forward such packets, for example...) Exactly. My take on this is that ANY solution based on multicast has potential risks; I am a fan of ARP servers and ES/IS type solutions, but I realise that puts me in a minority. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 00:58:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04456; Thu, 13 Oct 94 00:58:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04450; Thu, 13 Oct 94 00:58:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23109; Thu, 13 Oct 94 00:55:09 PDT Received: from clix.aarnet.edu.au ([130.102.128.59]) by Sun.COM (sun-barr.Sun.COM) id AA22087; Thu, 13 Oct 94 00:54:40 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 13 Oct 1994 17:50:04 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 13 Oct 1994 17:53:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 13 Oct 1994 17:55:10 +1000 Date: Thu, 13 Oct 1994 17:55:10 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Oct 13 17:55:10 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 105517131094 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <105517131094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> >Isn't it better to say: >> >> > - The number of entities attached to a single Data Link subnetwork >> > should be small. >> >> By small, how small do you imagine? Is that 200-300 or 2,000 to 3,000? >62 or, at most, 254. >I think CERN is demonstrating that a bridge-connected subnet of 1,000 >hosts is unmanageable. I have a 1,000 netbios nodes on bridged token rings with maybe 150-200 nodes on a segment. It has its management problems on occasion but the business drivers make this the config for the task at hand. I am looking to add IP as well as the netbios stack. I would not take too kindly to being told that my topology needed to change to add a stack. >> >Large subnets are unmanageable in various ways. >> >> Agreed but the size usually is a cost/effectiveness tradeoff. Architectural >> limitations tend to nark implementers if there is not a physical reason for the >> limitation. >It might be a good idea to enforce small subnet by protocol specification, >such as forcing the subnet boundary at the last octet. I think that this is really an implementers problem not an architectural one. At some later date larger networks will be able to be managed more effectively and we would not like to have architected against it. Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 03:04:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04630; Thu, 13 Oct 94 03:04:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04624; Thu, 13 Oct 94 03:04:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26408; Thu, 13 Oct 94 03:00:41 PDT Received: from spatula.csv.warwick.ac.uk ([137.205.193.200]) by Sun.COM (sun-barr.Sun.COM) id AA01089; Thu, 13 Oct 94 03:00:18 PDT Date: Thu, 13 Oct 1994 11:00:08 +0100 From: Ian Dickinson Message-Id: <1555.199410131000@spatula.csv.warwick.ac.uk> Received: by spatula.csv.warwick.ac.uk id LAA01555; Thu, 13 Oct 1994 11:00:08 +0100 In-Reply-To: Masataka Ohta "Re: (IPng) ARP" (Oct 13, 2:25pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ARP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Oct 13, 2:25pm, Masataka Ohta wrote: } Subject: Re: (IPng) ARP > > >Isn't it better to say: > > > - The number of entities attached to a single Data Link subnetwork > > > should be small. > > By small, how small do you imagine? Is that 200-300 or 2,000 to 3,000? > 62 or, at most, 254. > I think CERN is demonstrating that a bridge-connected subnet of 1,000 > hosts is unmanageable. We don't have ARP problems with our 2,500 host bridged network. > It might be a good idea to enforce small subnet by protocol specification, > such as forcing the subnet boundary at the last octet. Oh great - here I was looking forward to an IPng which gets round some of the problems we're having (address space, autoconfig et al), and you force me to change to routing in one fell swoop - that costs big money - because I bet a bridged IPv4 network won't coexist nicely with routed IPv6. Cheers, -- Ian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 04:17:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04649; Thu, 13 Oct 94 04:17:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04643; Thu, 13 Oct 94 04:17:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28155; Thu, 13 Oct 94 04:13:55 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA09333; Thu, 13 Oct 94 04:13:33 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA27577; Thu, 13 Oct 94 07:09:25 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410131109.AA27577@pluto.dss.com> Subject: Re: (IPng) ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 07:09:23 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <1555.199410131000@spatula.csv.warwick.ac.uk> from "Ian Dickinson" at Oct 13, 94 11:00:08 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1172 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM We are only discussing ARP rather than issues associated with a new IP because Bill Simpson and some others believe that if ARP functionality is moved into a higher protocol layer, somehow this functionality will become medium independent. Such a viewpoint can only be considered delusional. The appropriate way to handle ARP functionality within the specification of the new IP is not to deal with it at all but rather leave this functionality to separate medium dependent specifications relating to new IP address resolution over various media (ass similar functionality was handled for current IP). And by the way, whatever tactics of intimidation Bill Simpson may use, he is not going to be able to provide a medium indepent mechanism which will handle both X.25 and IEE802 LANs. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 04:32:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04661; Thu, 13 Oct 94 04:32:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04655; Thu, 13 Oct 94 04:32:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28568; Thu, 13 Oct 94 04:28:42 PDT Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA10218; Thu, 13 Oct 94 04:28:15 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 13 Oct 94 20:20:53 +0859 From: Masataka Ohta Message-Id: <9410131121.AA00504@necom830.cc.titech.ac.jp> Subject: Re: (IPng) ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 94 20:20:51 JST In-Reply-To: <1555.199410131000@spatula.csv.warwick.ac.uk>; from "Ian Dickinson" at Oct 13, 94 11:00 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > We don't have ARP problems with our 2,500 host bridged network. Then, I think we should conclude ARP is perfectly OK. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 05:15:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04674; Thu, 13 Oct 94 05:15:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04668; Thu, 13 Oct 94 05:15:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29533; Thu, 13 Oct 94 05:11:43 PDT Received: from rodan.UU.NET ([153.39.128.10]) by Sun.COM (sun-barr.Sun.COM) id AA12848; Thu, 13 Oct 94 05:11:21 PDT Received: by rodan.UU.NET id QQxlky03273; Thu, 13 Oct 1994 08:11:20 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) change the topology???? Date: Thu, 13 Oct 1994 08:11:20 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM One rule for IP6 is that existing IP4 networks must continue to work. And without thinking very hard, a corollary is that a network topology which WOULD work under IP4 must also work under IP6, regardless of the wisdom of such a deployment. Ergo, huge, purely-bridged networks must work under IP6 because they can be made to work with IP4. Again, we might be *very* thankful that it isn't our network to run, but it isn't our decision, either. yours for bigger and better bugs, -Mike O'Dell ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 05:32:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04697; Thu, 13 Oct 94 05:32:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04691; Thu, 13 Oct 94 05:31:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00177; Thu, 13 Oct 94 05:28:12 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA14111; Thu, 13 Oct 94 05:27:21 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13164; Thu, 13 Oct 1994 22:07:56 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Wed, 12 Oct 1994 16:33:32 MST." <199410122333.QAA02866@lager.cisco.com> Date: Thu, 13 Oct 1994 22:07:45 +1000 Message-Id: <9018.782050065@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 12 Oct 1994 16:33:32 -0700 From: Tony Li Message-ID: <199410122333.QAA02866@lager.cisco.com> Perry writes: What, exactly, is so broken about ARP and the subnet model? And Tony replies... Sounds like an invitation to rant. ;-) and then goes on to list a bunch of current problems, all related to the subnet model, and none related to ARP, with the possible exception of the comments on proxy arp. We do need to be more flexible in the way we handle subnetting, because if we don't, people will simply find ways to bend the "rules" (assumptions), with less than ideal results. On the other hand, ARP itself has nothing whatever to do with any of this - ARP starts to apply only at the point that we have decided that we have a destination IP (v4 or v6) address that is to be found on the local medium, and all we need to know is the link level address to use to get to that IP address. The higher level decision that has been made here is not a function of ARP, has nothing whatever to do with ARP, and its incorrect to burden ARP with problems that are of another making. Whatever mechanism was used to translate IP addresses to the corresponding media address would have the exact same problems with the subnet model - similarly, any fixed subnet model can still use ARP for link level address resolution on IEEE 802 networks. Proxy arp may be a problem, sometimes, but its also a fact of life. Its simply a case of people pushing the model beyond its original design. Unless the final model for V6 is so complex that it covers everything imaginable, and is thus incomprehensible, there will be people who will want to go outside whatever it anticipates... Those people will find some way to bend the rules, whatever the rules are. Something as ugly as proxy arp (which is not actually very ugly, comparatively, so this won't be hard to meet) is going to exist in any model. kre ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 06:02:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04727; Thu, 13 Oct 94 06:02:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04721; Thu, 13 Oct 94 06:02:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01108; Thu, 13 Oct 94 05:59:01 PDT Received: from inet-gw-2.pa.dec.com ([16.1.0.23]) by Sun.COM (sun-barr.Sun.COM) id AA16698; Thu, 13 Oct 94 05:58:40 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA14394; Thu, 13 Oct 94 05:51:59 -0700 Received: by xirtlu.zk3.dec.com; id AA21861; Thu, 13 Oct 1994 08:51:49 -0400 Message-Id: <9410131251.AA21861@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ARP In-Reply-To: Your message of "Thu, 13 Oct 94 12:06:21 +0200." <9410130306.AA27887@necom830.cc.titech.ac.jp> Date: Thu, 13 Oct 94 08:51:38 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ************************************* > > How about adding the following to your requirements: > - It should be possible to constrain the number of entities > that involved into IP to MAC address mapping to > a number which is significantly less than the total number of entities > attached to the Data Link subnetwork Isn't it better to say: - The number of entities attached to a single Data Link subnetwork should be small. Large subnets are unmanageable in various ways. ************************************ None of this is valid. Lets build a system discovery protocol iron out and discuss our technical views, and get some consensus. Lets not try to pick how many nodes can exist on an IPv6 subnet. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 06:28:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04753; Thu, 13 Oct 94 06:28:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04747; Thu, 13 Oct 94 06:28:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02201; Thu, 13 Oct 94 06:24:23 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA19425; Thu, 13 Oct 94 06:23:48 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA27378 for ; Thu, 13 Oct 1994 09:21:25 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA02086 for ; Thu, 13 Oct 1994 09:21:15 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04384; Thu, 13 Oct 94 09:21:14 EDT Message-Id: <9410131321.AA04384@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Wed, 12 Oct 1994 16:33:32 PDT." <199410122333.QAA02866@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Thu, 13 Oct 1994 09:21:13 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > What, exactly, is so broken about ARP and the subnet model? > > Sounds like an invitation to rant. ;-) > > Ever tried to deal with multiple subnets on the same wire? I must admit not to having done this, since these days I'm lucky if I can get two dozen hosts running on the same net without pinning the wire (or being forced to buy switching hubs and the like). Given this, I've never run out of network numbers on a single wire, and I have trouble seeing what other reason one might have to use multiple subnets on one line. > Walt is absolutely correct -- we must have some mechanism to partition > the network and provide abstraction. However, the current model of > one subnet per wire is incredibly restrictive. Why, precisely? In any case, I can imagine an easy way around this. A routing information protocol could simply inform the hosts that they could reach all the given subnets directly. (Yet another reason for wanting smart end hosts instead of the lobotomized ones everyone seems to want.) I still wonder, however, *why* one would want to run multiple subnets on one wire. I've been involved in the mangement of HUGE sites (thousands of hosts in multiple continents) and its never even occured to me that there was a problem that I could solve by putting multiple subnets on one wire. > The way that ARP gets used is another manifestation of the problem. > Proxy ARP is simply telling lies. It seems to work pretty well under the conditions where I've been forced to use it. Really. No joke. I'm not, you understand, saying that there aren't people out there who might not have a legitimate use for multiple subnets on one wire, or a legitimate problem with ARP storms, or a legitimate set of problems with Proxy ARP, etc. I'm just not getting a full picture here. Now, I'm not one of the inner core of V6 implementors. I'm just a user. However, I speak for the future of your network -- my users are people operating real businesses with *real money* (meaning billions) on the line depending on these networks. Look at it from my point of view. I'm a user with very nasty responsibilities. Market data systems DONT GO DOWN. If they do, you get your balls handed to you. I have existing, well shaken down protocols that I depend on -- my IPv4 networks work like champs day after day. I can easily make them fully redundant, self recovering, self monitoring, etc. Installations I work with routinely have staffs of dozens of overworked people worrying about their Novell crap which is used for nothing but office automation and a tiny staff managing a far more reliable IP network that the firm absolutely and completely depends on. Here is my quandry. People are complaining about all sorts of things. Well, I rely on all these mechanisms that everyone is telling me are bad, even though they have never given me any trouble. Those include running routed on my end hosts so they can route around network failures, ARP, and all the rest. I'm told that all sorts of new mechanisms no one has ANY operational experience with are going to be much better than these mechanisms. This *really* scares me to death. I have this sinking feeling that what is happening is that a good thing is getting destroyed by the second systems effect and I'm going to be forced to take giant steps backward in the reliability of my networks. I'd like to see a document out there outlining down to the last detail why the old mechanisms are bad. Its not my place to demand such a document, but I'll tell you that you aren't going to get consensus out of me until I feel comfortable that my clients aren't going to get destroyed by these newfangled mechanisms to fix problems no one has sufficiently well explained to me. Maybe they are intuitive to *you*, but they aren't to me. I'm just a user of this stuff, but I'm not stupid -- I understand this protocol stack pretty well, and it shouldn't take more than a single clear explanation to make me understand what the problems being solved are. I very easily understand the routing problem getting out of control. I very easily understand the IP numbering space problem. I understand the security problem (and I'm involved in IPSEC). There are all these other problems being solved here that I don't understand and that I was unaware were in the charter. If people can clearly articulate them, I'll shut up and go away. However, you are going to have to articulate them or I'm not going to shut up and go away. Too much of my client's money rides on this stuff, and too much of my money rides on being able to deliver for those clients -- when you have money riding on something, you become astonishingly careful and concerned. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 06:52:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04793; Thu, 13 Oct 94 06:52:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04787; Thu, 13 Oct 94 06:52:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03118; Thu, 13 Oct 94 06:48:44 PDT Received: from rodan.UU.NET ([153.39.128.10]) by Sun.COM (sun-barr.Sun.COM) id AA22179; Thu, 13 Oct 94 06:48:23 PDT Received: by rodan.UU.NET id QQxllf09822; Thu, 13 Oct 1994 09:48:22 -0400 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 09:48:21 -0400 (EDT) In-Reply-To: <9410131321.AA04384@snark.imsi.com> from "Perry E. Metzger" at Oct 13, 94 09:21:13 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1600 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >I must admit not to having done this, since these days I'm lucky if I >can get two dozen hosts running on the same net without pinning the >wire (or being forced to buy switching hubs and the like). Given this, >I've never run out of network numbers on a single wire, and I have >trouble seeing what other reason one might have to use multiple >subnets on one line. If you are renumbering your net, but there is a host that is very hard to re-number you can end up with more then one subnet on a single cable. Before you claim that IPv6 makes re-numbering "easy", think about interactions with DNS. It isn't easy to re-number a nameserver, not when it's IP address is hardcoded into thousands of hosts (and if 1000s of hosts doesn't ring true, just a "mere" 800 is a pain... in fact just finding the current techinical contact at 5 or 6 sites and getting them to make named config changes isn't all that plesent...). There are places where IP addresses are hardcoded (other then DNS which may be the only place there is a really rock solid techinical reason to do it), and while it may be nice to hope that will stop, many people won't trust DNS to allways work. That's going to make it hard for "well-known" hosts to re-number, which does create some demand for multiple subnets on a single cable. Even if you ignore re-numbering nameservers, IPv6 will need to deal with more then one subnet on a cable when it re-numbers a net (I seem to recall the spec saying the normal case of re-numbering adds a new IP address to each node, and the old address is allowed to linger for a while). ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 07:21:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04818; Thu, 13 Oct 94 07:21:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04812; Thu, 13 Oct 94 07:21:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04629; Thu, 13 Oct 94 07:17:50 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA25954; Thu, 13 Oct 94 07:17:27 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20344; Thu, 13 Oct 1994 15:17:22 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10671; Thu, 13 Oct 1994 15:17:18 +0100 Message-Id: <9410131417.AA10671@dxcoms.cern.ch> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 15:17:18 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410131321.AA04384@snark.imsi.com> from "Perry E. Metzger" at Oct 13, 94 09:21:13 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1225 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, I'm hard to shut up on this issue too. In the last month we have logged 37 instances of a system on our main bridged network being automatically blocked in the bridges for exceeding what we regard as the acceptable rate of single-source broadcasts. I can't assert that all these occurrences (and the vastly greater number of storms below the threshold) were ARP side-effects, but it gives an idea of the scale of the problem. The threshold is set at a level where users notice response time problems. The actual size of our bridged network is above 6000 active MAC addresses, and we see at least 68 different Ethernet manufacturer codes. We are not particularly happy about either of these numbers, but there are good reasons for both of them. Of course this is a research lab, not a bank, so the cost/performance/reliability tradeoffs are different from yours. My allergy to the ARP paradigm comes from this experience. Our experience with ES-IS is much more reassuring (although much more limited). You are of course 100% correct that we users (I'm a user too) cannot be expected to switch our operational networks to a new paradigm with unproven scaling properties. Theoretical elegance is not enough. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 08:10:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04851; Thu, 13 Oct 94 08:10:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04845; Thu, 13 Oct 94 08:10:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08090; Thu, 13 Oct 94 08:07:00 PDT Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by Sun.COM (sun-barr.Sun.COM) id AA03689; Thu, 13 Oct 94 08:06:38 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA03108; Thu, 13 Oct 94 07:58:36 -0700 Received: by xirtlu.zk3.dec.com; id AA29937; Thu, 13 Oct 1994 10:58:33 -0400 Message-Id: <9410131458.AA29937@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Thu, 13 Oct 94 09:21:13 EDT." <9410131321.AA04384@snark.imsi.com> Date: Thu, 13 Oct 94 10:58:27 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I think Perry's request is very reasonable regarding such a document. I too feel as an implementor and as one who uses subnets, arp, et al every day of my life that much of the arguments stating Ipv4 is broke are perceived arguments as opposed to real ones. If I am wrong thats OK but I am not hearing real technical details of why we should risk moving to something that is not broke. In fact I would like to see the code that all find bad or explain the details of the design center in Ipv4 that they think is broken. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 08:35:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04871; Thu, 13 Oct 94 08:35:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04865; Thu, 13 Oct 94 08:35:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09965; Thu, 13 Oct 94 08:31:20 PDT Received: from venera.isi.edu ([128.9.0.32]) by Sun.COM (sun-barr.Sun.COM) id AA07965; Thu, 13 Oct 94 08:30:59 PDT Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Thu, 13 Oct 1994 08:30:58 -0700 From: bmanning@ISI.EDU Posted-Date: Thu, 13 Oct 1994 08:30:09 -0700 (PDT) Message-Id: <199410131530.AA04454@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 13 Oct 1994 08:30:09 -0700 Subject: Re: (IPng) ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 08:30:09 -0700 (PDT) In-Reply-To: <9410130526.AA28646@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Oct 13, 94 02:25:45 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 498 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ohta-san, In a prior life, I managed a bridged network of 12,000 nodes. It was tough, but doable. The problem space was/is different though, since there was -no- routing in this network. In some sense, bridged nets have fewer problems than routed nets. A combination, like Brian has @ CERN brings the worst and the best of both environments to light. > > 62 or, at most, 254. > > I think CERN is demonstrating that a bridge-connected subnet of 1,000 > hosts is unmanageable. > --bill ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 09:17:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04895; Thu, 13 Oct 94 09:17:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04889; Thu, 13 Oct 94 09:17:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13875; Thu, 13 Oct 94 09:14:03 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA16374; Thu, 13 Oct 94 09:13:20 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA00501; Thu, 13 Oct 94 12:07:05 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410131607.AA00501@pluto.dss.com> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 12:07:04 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9410131417.AA10671@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Oct 13, 94 03:17:18 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3341 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Perry, > I'm hard to shut up on this issue too. In the last month we have > logged 37 instances of a system on our main bridged > network being automatically blocked in the bridges for exceeding > what we regard as the acceptable rate of single-source broadcasts. > I can't assert that all these occurrences (and the vastly greater > number of storms below the threshold) were ARP side-effects, > but it gives an idea of the scale of the problem. The threshold > is set at a level where users notice response time problems. If you would fax me a network trace of one of these high broadcast periods, I would be happy to tell you what is going on. Also a topological diagram identifying bridges and routers (and their manufacturers) would be useful. FYI. If you are using spanning tree bridges which are not fully powered, you should expect to see occasional topological anomalies which may result in broadcast storms or black holes. Running routers which bridge what they don't route can be expected to cause topological anomalies which may result in broadcast storms or black holes. Incorrect allocation of memory resources to receivers versus transmitters in a packet switch (bridge or router) with number of interfaces > 2 can also cause serious problems. Few commonly available packet switches (either bridges or routers) with more than 2 interfaces handle the problem of memory resource allocation correctly. Problems related to misallocated memory resources can also lead to broadcast storms and black holes. > The actual size of our bridged network is above 6000 active MAC addresses, > and we see at least 68 different Ethernet manufacturer codes. We are not > particularly happy about either of these numbers, but there are > good reasons for both of them. Of course this is a research lab, not > a bank, so the cost/performance/reliability tradeoffs are different > from yours. > My allergy to the ARP paradigm comes from this experience. Our experience > with ES-IS is much more reassuring (although much more limited). Anyway, without a smoking gun there is no reason to blame arp for your problems nor is there any reason to assume ES-IS will alleviate your problem especially when you have never scaled ES-IS up to the same size as your IP network. I would note that DECNETs built with a heterogeneous (with respect to manufacturer) collection of DECNET level 1 and DECNET level 2 routers have tremendously more background noise (lots of multicasts often very large) than comparably sized and comparably topologically complex IP networks. And DECNET network addresses are directly mapped to MAC addresses without the mediation of some MAC layer address resolution protocol even on 802.2 type networks. > You are of course 100% correct that we users (I'm a user too) cannot > be expected to switch our operational networks to a new paradigm > with unproven scaling properties. Theoretical elegance is not > enough. > Brian Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 09:41:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04907; Thu, 13 Oct 94 09:41:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04901; Thu, 13 Oct 94 09:41:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16608; Thu, 13 Oct 94 09:37:31 PDT Received: from uu2.psi.com ([128.145.228.2]) by Sun.COM (sun-barr.Sun.COM) id AA21589; Thu, 13 Oct 94 09:36:50 PDT Received: from port36.santa-clara.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06108 for ipng@sunroof.eng.sun.com; Thu, 13 Oct 94 12:36:04 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA07935; Thu, 13 Oct 1994 09:34:50 -0700 Message-Id: <199410131634.JAA07935@aland.bbn.com> To: "Perry E. Metzger" Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of Thu, 13 Oct 94 09:21:13 -0400. <9410131321.AA04384@snark.imsi.com> From: Craig Partridge Date: Thu, 13 Oct 94 09:34:49 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'd like to see a document out there outlining down to the last detail why the old mechanisms are bad. Its not my place to demand such a document, but I'll tell you that you aren't going to get consensus out of me until I feel comfortable that my clients aren't going to get destroyed by these newfangled mechanisms to fix problems no one has sufficiently well explained to me. Maybe they are intuitive to *you*, but they aren't to me. I'm just a user of this stuff, but I'm not stupid -- I understand this protocol stack pretty well, and it shouldn't take more than a single clear explanation to make me understand what the problems being solved are. Perry: I'm with you on this point. If we're going to replace ARP we'd better be very clear about what problems we want to solve, and how the new proposal (even after we account for a variety of implementation errors) both solves those problems and is more robust than ARP today. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 09:43:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04919; Thu, 13 Oct 94 09:43:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04913; Thu, 13 Oct 94 09:43:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17066; Thu, 13 Oct 94 09:39:35 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA22153; Thu, 13 Oct 94 09:39:01 PDT Received: from relay.imsi.com by wintermute.imsi.com id MAA27718 for ; Thu, 13 Oct 1994 12:36:28 -0400 Received: from snark.imsi.com by relay.imsi.com id MAA03150 for ; Thu, 13 Oct 1994 12:36:17 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA04719; Thu, 13 Oct 94 12:36:16 EDT Message-Id: <9410131636.AA04719@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ARP In-Reply-To: Your message of "Thu, 13 Oct 1994 17:55:10 +1000." <105517131094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> X-Reposting-Policy: redistribute only with permission Date: Thu, 13 Oct 1994 12:36:16 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jeff.Latimer@FINANCE.ausgovfinance.telememo.au says: > I have a 1,000 netbios nodes on bridged token rings with maybe 150-200 > nodes on a segment. It has its management problems on occasion but > the business drivers make this the config for the task at hand. I am > looking to add IP as well as the netbios stack. I would not take too kindly > to being told that my topology needed to change to add a stack. You wouldn't. Modern routers can be told to bridge certain protocols and route others. I've made use of this on several occasions where I needed to bridge some braindead protocol but I didn't want it to hurt IP traffic overly much. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 10:47:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05022; Thu, 13 Oct 94 10:47:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04680; Thu, 13 Oct 94 05:24:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29863; Thu, 13 Oct 94 05:20:31 PDT Received: from rodan.UU.NET ([153.39.128.10]) by Sun.COM (sun-barr.Sun.COM) id AA13596; Thu, 13 Oct 94 05:20:10 PDT Received: by rodan.UU.NET id QQxlkz03830; Thu, 13 Oct 1994 08:20:09 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) on the dirth of broadcast storms Date: Thu, 13 Oct 1994 08:20:08 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I strongly believe that one of the biggest causes of broadcast storms was the incredibly bad decision to change the IP broadcast address after there was code already fielded using a different one. The net result (ouch!) of that decision is that TWO address (all ones and all zeros) are verboten for assignment. Also, lots of IP implementations got a lot smarter about sanity checking "broadcast" packets. "Never assign EITHER, in spite of whether you think you know the IP broadcast address" has, I think, dramatically reduced the problem on many networks. Telling your routers to have NO broadcast address on their interfaces helps as well (but at a cost, clearly). I'm not about to say there aren't still numerous causes of first-rate melt-downs - Brian says he still sees 'em from time to time and I believe him (and that I saw one recently because of a busted interface), but the frequency and severity are markedly reduced from "the good ol' days." Also, the use of Ethernet switching with intelligent bridging between legs (assuming your switch isn't a major cause in its own right) has also contributed to at least damage control. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 11:15:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05052; Thu, 13 Oct 94 11:15:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05046; Thu, 13 Oct 94 11:15:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27105; Thu, 13 Oct 94 11:11:46 PDT Received: from watson.ibm.com ([129.34.139.4]) by Sun.COM (sun-barr.Sun.COM) id AA08739; Thu, 13 Oct 94 11:11:02 PDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0211; Thu, 13 Oct 94 14:10:42 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 0563; Thu, 13 Oct 1994 14:10:42 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Thu, 13 Oct 94 14:10:42 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA38678; Thu, 13 Oct 1994 14:10:35 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9410131810.AA38678@hawpub1.watson.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: (Your message of Thu, 13 Oct 94 10:58:27 D.) <9410131458.AA29937@xirtlu.zk3.dec.com> Date: Thu, 13 Oct 94 14:10:35 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM While at the implementor's meeting, a model for resolving IPv6 addresses was described, which basically involves using a router if one is available. Then (if the router is available) for hosts on the same subnet, the sender would get a local redirect, which could be made to have the MAC address in it. As I remember, the objections to this model is that it tends to overload routers, and routers often are considered budget items to try to save money on. Plus, it is said, routers are so busy routing packets on their fast track, that adding other responsibilities would have a disproportionate overall impact on the throughput of the router. And, finally, if there aren't any routers then hosts will have to use some ARP-style protocol anyway. As long as redirects DID inform the sending host of the MAC address of the destination, I think both models could co-exist. People who like ARP, would use hosts that use ARP. People who would rather avoid broadcasts and place the extra burden on their routers could get rid of ARP. I personally think that eliminating the host knowledge of prefixes, and eliminating the usual need for broadcast, and thereby eliminating the usual need to wake up possibly sleeping hosts, make the non-ARP model a big win. Moreover, if the local router forwards the packet, the latency of data transfers to hosts whose MAC addresses are initially unknown is eliminated. Much of the objection to using routers would be eliminated if the non-ARP model becomes popular (market-driven :-) and router vendors make non-ARP features efficient. It seems to me that by using just a little care in the design we could satisfy the needs of those in both camps. Charlie P. PS. I don't care what protocol level the local redirect is used to deliver the redirect. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 11:18:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05067; Thu, 13 Oct 94 11:18:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05061; Thu, 13 Oct 94 11:18:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27561; Thu, 13 Oct 94 11:15:04 PDT Received: from ski.utah.edu ([128.110.124.10]) by Sun.COM (sun-barr.Sun.COM) id AA09272; Thu, 13 Oct 94 11:14:29 PDT Received: (from haas@localhost) by ski.utah.edu (8.6.9/8.6.9) id LAA28983; Thu, 13 Oct 1994 11:23:50 -0600 From: Tired of the Information Superhype Message-Id: <199410131723.LAA28983@ski.utah.edu> Date: Thu, 13 Oct 94 11:23:49 MDT Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM In-Reply-To: ipng@sunroof.Eng.Sun.COM, Thu, 13 Oct 1994 09:21:13 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry Metzger wrote: >I've never run out of network numbers on a single wire, and I have >trouble seeing what other reason one might have to use multiple >subnets on one line. We do this as a proactive method of dealing with future growth. When we have several independent departments sharing one line but the expectation that growth will cause a future requirement for independent lines, we try to get ahead of the game by assigning each department their own subnet number at the beginning, then splitting them off onto their own wires as necessary. You might not need to do this if you don't work for a state university :-). A good automatic address configuration algorithm would accomplish many of the same goals. >[Proxy ARP] seems to work pretty well under the conditions where I've been >forced to use it. Really. No joke. We've had good results too. I'm inclined to take this good experience with proxy ARP as one of the best forms of autoconfiguration by a router that I've seen. So far, proxy ARP hasn't generated any of the broadcast storm problems that we've had with protocols like Novell NETBIOS, for example. On the whole I've become a big fan of the proxy ARP approach. >Look at it from my point of view. I'm a user with very nasty >responsibilities. Market data systems DONT GO DOWN. If they do, you >get your balls handed to you. Funny, the University of Utah has a similar management environment, even though you would think there's much less money involved :-) >I have existing, well shaken down >protocols that I depend on -- my IPv4 networks work like champs day >after day. I can easily make them fully redundant, self recovering, >self monitoring, etc. Installations I work with routinely have staffs >of dozens of overworked people worrying about their Novell crap which >is used for nothing but office automation and a tiny staff managing a >far more reliable IP network that the firm absolutely and completely >depends on. Hm, exactly our experience with the two protocols. >Here is my quandry. People are complaining about all sorts of things. >Well, I rely on all these mechanisms that everyone is telling me are >bad, even though they have never given me any trouble. Those include >running routed on my end hosts so they can route around network >failures, ARP, and all the rest. I'm told that all sorts of new >mechanisms no one has ANY operational experience with are going to be >much better than these mechanisms. > >This *really* scares me to death. I have this sinking feeling that >what is happening is that a good thing is getting destroyed by the >second systems effect and I'm going to be forced to take giant steps >backward in the reliability of my networks. I have the same fears. I think the people who are impressed with the market penetration of, say, Novell, might want to look closely at exactly what it's being used for, and why people with the really serious applications migrate away from it in spite of its undoubted plug-and-play convenience. Point of information... one of the hurdles we had to overcome in building a campus Novell network with many thousands of nodes was the fact that Novell doesn't have subnetting. This fact in turn creates a large management problem, because there is no simple set of rules by which one can choose a Novell network number for each server port. At first there was a tendency for everyone to use the default, which didn't work very well ;-) Then there was an attempt to use campus building numbers, which died because some buildings have many Novell networks. We finally solved the problem permanently... the way we did it is as follows: for each wire, we start by using the normal IP address administration to assign a subnet from our class B to that wire. Then we convert that number to hex and call it the Novell network number. This system has served us well, getting efficiently around the problems with Novell's lack of subnetting. Any attempt to do address autoconfiguration in IP6 needs to at least meet this standard of service. -- Walt ------- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 11:24:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05097; Thu, 13 Oct 94 11:24:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05091; Thu, 13 Oct 94 11:24:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28356; Thu, 13 Oct 94 11:20:35 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA29368; Thu, 13 Oct 94 10:21:11 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA21207; Thu, 13 Oct 1994 17:52:31 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17804; Thu, 13 Oct 1994 17:52:30 +0100 Message-Id: <9410131652.AA17804@dxcoms.cern.ch> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 17:52:29 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410131607.AA00501@pluto.dss.com> from "Joachim Martillo" at Oct 13, 94 12:07:04 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 483 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, Oh, we have plenty of smoking guns, but I don't want to be sued for libel by several major vendors (they know who they are). We run Network General sniffers, LANalyzers and quite a lot of home-made monitoring software all the time. We know all about asymmetric routes, black holes of many kinds, believe me we eat and drink this stuff. We got the DECnet multicast overhead under control about 7 years ago. And I don't think we are especially incompetent either. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 13:37:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05152; Thu, 13 Oct 94 13:37:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05146; Thu, 13 Oct 94 13:37:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12285; Thu, 13 Oct 94 13:34:03 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA03868; Thu, 13 Oct 94 13:30:19 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA02809; Thu, 13 Oct 94 16:25:23 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410132025.AA02809@pluto.dss.com> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 13 Oct 1994 16:25:22 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9410131652.AA17804@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Oct 13, 94 05:52:29 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1823 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Joachim, > Oh, we have plenty of smoking guns, but I don't want to be > sued for libel by several major vendors (they know who they > are). We run Network General sniffers, LANalyzers and > quite a lot of home-made monitoring software all the time. > We know all about asymmetric routes, black holes of many > kinds, believe me we eat and drink this stuff. But how can we evaluate claims about the evil of arp without seeing some raw data. > We got the DECnet multicast overhead under control about > 7 years ago. > And I don't think we are especially incompetent either. I never said you were. And by the way, I was not asking you to libel any vendor. Outside of specific beta agreements, vendors have to assume that information about problems associated with their equipment will become public (which is a good reason for vendors to work hard to get the bugs out). Lots of Cisco bugs are described in gory detail on the Cisco mailing list. But it does not seem to have hurt Cisco, and the list seems generally useful. So many vendors have pointed fingers at the Constellation Series (almost invariably without justification over the years -- the best was the frame relay split-horizon terrorism which many routers except for the Constellation Series committed) that Tony Bono and I (and M.L.Lee lately) have gotten very good at figuring out what most other routers, bridges and computer system drivers are doing. > Brian Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 15:12:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05191; Thu, 13 Oct 94 15:12:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05185; Thu, 13 Oct 94 15:11:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21343; Thu, 13 Oct 94 15:08:17 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA19698; Thu, 13 Oct 94 15:07:36 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA09758; Thu, 13 Oct 1994 18:05:49 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA14155; Thu, 13 Oct 1994 18:05:47 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA06367; Thu, 13 Oct 1994 17:42:23 -0400 Message-Id: <9410132142.AA06367@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, tli@cisco.com Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Wed, 12 Oct 94 16:33:32 PDT." <199410122333.QAA02866@lager.cisco.com> Date: Thu, 13 Oct 94 17:42:23 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry writes: What, exactly, is so broken about ARP and the subnet model? Sounds like an invitation to rant. ;-) Ever tried to deal with multiple subnets on the same wire? Ever been burned by proxy arp? Walt is absolutely correct -- we must have some mechanism to partition the network and provide abstraction. However, the current model of one subnet per wire is incredibly restrictive. [No, I'm not arguing for ISIS area routing -- the design space is even bigger than that.] Consider what happens right now if I have Host A, Host B and Router C on the same subnet where A and B are not in the same subnet. To exchange packets, you either have to do warped configuration (tell A that it can route directly to B and vice versa) OR the two hosts talk via the router, with everything taking two hops on the LAN. This is a clear case where the inflexibility in the model results in a horrible result. The "one subnet per wire" limitation is an implementation rather than protocol limitation - I know implementations that do not allow more than one IP address per link adapter (which is the case you mentioned), but I also know ones that do - in which case host A, and B may have address A1, A2 and B1, B2 which will make them part of the two subnets 1, and 2, that are on the same wire. IPv6 allows multiple IPv6 addresses per interface (link adapter) therefore this problem would not exist with correct IPv6 implementations, and network managers that know how to set things up - actually IPv6 auto-configuration and discovery should do a lerge proportion if not all of the work in this case: router C, would advertize on both subnet 1, and 2, with a prefix 1, and 2, and so hosts A, and B, would pick up addresses for both subnets, i.e. A1, A2, respectively B1, B2. The way that ARP gets used is another manifestation of the problem. Proxy ARP is simply telling lies. If impersonation is a solution for a particular problem on a particular network, I would say that a "controlled telling lies" is rather a "feature". To go a little further, I have a problem with any address resolution (discovery) mechanism that does not allow the implementation of address resolution servers - ARP does allow this - i.e. a designated device to answer on behalph of other devices. ... What would be better? Well, we need a more flexible partitioning and abstraction model. Some things that I'd put forth as requirements: 1. - Hosts don't need to know which partition they're in. 2. - Hosts don't need to know which partition the destination is in. 3. - Hosts can be in multiple partitions simultaneously. 4. - Partitions can overlap, and not necessarily nest. 5. - Partitions can be discontigous. I - disagree strongly with - 1., and 2., To qualify, a host should know whether the destination is in the same partition or not. - agree with - 3., and 4., - disagree with - 5. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 16:10:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05228; Thu, 13 Oct 94 16:10:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05222; Thu, 13 Oct 94 16:10:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB27229; Thu, 13 Oct 94 16:06:20 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA00707; Thu, 13 Oct 94 16:05:50 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA11537; Thu, 13 Oct 1994 19:05:44 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA15583; Thu, 13 Oct 1994 19:05:41 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA06431; Thu, 13 Oct 1994 18:42:16 -0400 Message-Id: <9410132242.AA06431@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, barney@databus.com Subject: Re: (IPng) Re: ARP, etc. In-Reply-To: Your message of "Tue, 11 Oct 94 02:14:00 EDT." <9410110214.AA28676@databus.databus.com> Date: Thu, 13 Oct 94 18:42:16 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Mon, 10 Oct 94 23:28:16 -0400 > From: conta@zk3.dec.com > > - The processing model in which the first data packet of an unkown > destination media address host is sent with a "IPv6 unicast/link-layer > multicast" opens in my view the door to faulty or unexpected behavior. Without agreeing or disagreeing, may I ask for specifics on this? Are you afraid that some implementation will think it's supposed to forward the packet? Yes. There are many variations of this type of failure, which multiply with the type of media that become available. Philosophycally, it is the "robustness" principle. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 16:38:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05262; Thu, 13 Oct 94 16:38:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05256; Thu, 13 Oct 94 16:38:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29898; Thu, 13 Oct 94 16:34:49 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA05476; Thu, 13 Oct 94 16:32:29 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08393; Fri, 14 Oct 1994 09:32:04 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00812; Fri, 14 Oct 94 09:05:16 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00723; Fri, 14 Oct 1994 09:05:16 EST Date: 13 Oct 94 08:57:04 +1100 To: ipng@sunroof.Eng.Sun.COM, majordomo@sunroof.Eng.Sun.COM Ua-Content-Id: 941013 08:55:46 P1-Recipient: ipng@sunroof.eng.sun.com, majordomo@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941013 08:55:46 052 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941013085704+1100 deferred 941013085704+1100 action Relayed Message-Id: <"941013 08:55:46"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM get ipng draft-ipng-recommendation-00.txt ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 16:39:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05277; Thu, 13 Oct 94 16:39:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05264; Thu, 13 Oct 94 16:38:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29924; Thu, 13 Oct 94 16:35:07 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA05247; Thu, 13 Oct 94 16:31:27 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08346; Fri, 14 Oct 1994 09:30:42 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00774; Fri, 14 Oct 94 09:01:59 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00723; Fri, 14 Oct 1994 09:01:58 EST Date: 13 Oct 94 08:42:54 +1100 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) TO SPARKER @ SUNROOF Ua-Content-Id: 941013 08:40:35 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941013 08:40:35 051 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941013084254+1100 deferred 941013084254+1100 action Relayed Message-Id: <"941013 08:40:35"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM sparker, gday.. I get the impression my mail is not getting to the list... is it being held up anywhere.. In fact did you get this... Is any one there? Hello Me.. Doh! MMMMMM.. Burger! Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 16:44:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05307; Thu, 13 Oct 94 16:44:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05301; Thu, 13 Oct 94 16:43:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00369; Thu, 13 Oct 94 16:40:12 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AB06415; Thu, 13 Oct 94 16:36:21 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08497; Fri, 14 Oct 1994 09:35:04 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00833; Fri, 14 Oct 94 09:06:01 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00723; Fri, 14 Oct 1994 09:06:01 EST Date: 11 Oct 94 09:50:42 +1100 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ADDRESSING ARCH.. COMMENTS Ua-Content-Id: 941011 08:54:09 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941011 08:54:09 007 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941011095042+1100 deferred 941011095042+1100 action Relayed Message-Id: <"941011 08:54:09"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, some comments on Unicast Address allocation ipng-IPv6-addr-01.txt I have some overall views about the terminology used, but I am sure this has been discussed at length and is set in concrete.. However, perhaps others have the same view and would like the terms clarified.. INTRO The terms Domain, Providor, Subscriber are used within the IT industry and have well understood semanitics. Network Addresses dictate where things are in either a logical or geographic manner. Domain - That which one has dominion over, estate, -defines boundaries of ownership, authority or function.. Subscribe - to provide signature, to pay for or promise payment, etc. Provide - to supply, to furnish, etc. COMMENTS I feel that applying the Provider, Subscriber terms to network addresses implies operational characteristics to something which is just a routing scheme. The terms also get explained as "those with backbones" and "sites".. Therefore, the term's usage in the context of network address structure also implies network topology and bandwidth capability. Such implied meaning to address forms certainly complicates matters with network design and understanding. So implying such characteristics from an address form I feel is wrong. My preference is to see that an address form is aligned in some way between its registration hierarchy and its routing hierarchy (logical and/or geographic). This is because one cannot dictate or imply network topologies (as implemented) or communications capacities - from an address form. These choices are taken on commercial (and technical) grounds. The best approach to addressing i feel is to determine the Registration Authorities and the Sub RA and the Sub-Sub RAs etc.. on a geographic and logical basis and then slice (allocate) the addresses accordingly. The major point here is.. it is not the number of address bits which is the driving force.. It is the way in which it can be pragmatically managed over the planet which is important. The issue of TRDS, quantity of routing information, optimal routes, redundant paths, etc will sort themselves out as the network evolves.. I think that task is impossible to dictate from address field definition.. However, the address field if organised correctly will imply authority/regions, organisations, routing domains, subnets and nodes. Specifically the text in para 2 of Scope " Domains that share..." should be reworded and also " routing domain" should be used explicitly. This is because "Domain" may also be used in related documents to bound network functions such as "Management Domain", Administrative Domain", Security Domain" etc. Section 6. This section also tries to relate addresses with topologies and national boundaries.. again this reinforces the issues of address admin. Finally... the doc does expose the issues with global addressing and network architectures .. which is good.. How is it progressed from here..?? eg. are Providor/Subscriber terms now concrete? Is there any work being done on RAs and procedures for address management? Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 17:02:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05324; Thu, 13 Oct 94 17:02:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05318; Thu, 13 Oct 94 17:01:59 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01842; Thu, 13 Oct 94 16:58:18 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA09169; Thu, 13 Oct 94 16:55:08 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA16961; Thu, 13 Oct 1994 16:41:28 -0700 Date: Thu, 13 Oct 1994 16:41:28 -0700 From: Tony Li Message-Id: <199410132341.QAA16961@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com, tli@cisco.com In-Reply-To: conta@zk3.dec.com's message of Thu, 13 Oct 94 17:42:23 -0400 <9410132142.AA06367@brigit.zk3.dec.com> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The "one subnet per wire" limitation is an implementation rather than protocol limitation - I know implementations that do not allow more than one IP address per link adapter (which is the case you mentioned), but I also know ones that do - in which case host A, and B may have address A1, A2 and B1, B2 which will make them part of the two subnets 1, and 2, that are on the same wire. Yes, I know of lots of implementations which allow it. But because this is not adequately defined in the model, I don't know of _any_ two implementations that are consistent with each other. If impersonation is a solution for a particular problem on a particular network, I would say that a "controlled telling lies" is rather a "feature". The key word here is "controlled". Generally, it isn't. To go a little further, I have a problem with any address resolution (discovery) mechanism that does not allow the implementation of address resolution servers - ARP does allow this - i.e. a designated device to answer on behalph of other devices. No argument here. What would be better? Well, we need a more flexible partitioning and abstraction model. Some things that I'd put forth as requirements: 1. - Hosts don't need to know which partition they're in. 2. - Hosts don't need to know which partition the destination is in. 3. - Hosts can be in multiple partitions simultaneously. 4. - Partitions can overlap, and not necessarily nest. 5. - Partitions can be discontigous. I - disagree strongly with - 1., and 2., To qualify, a host should know whether the destination is in the same partition or not. Why? A host should clearly learn whether or not it's on the same media or not. What does it matter if I'm in the same partition or some other partition? It's just a namespace and I should _not_ have to know the organization of that namespace. - agree with - 3., and 4., - disagree with - 5. Well, then you condemn partitioned (sigh terminology overlap) media to instant failure. We already know how to deal with area partitioning in ISIS. One would hope that in the next 20 years we might do SOMETHING better about partition repair for individual subnets. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 17:22:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05351; Thu, 13 Oct 94 17:22:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05345; Thu, 13 Oct 94 17:22:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03252; Thu, 13 Oct 94 17:18:42 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA12717; Thu, 13 Oct 94 17:17:26 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA20838; Thu, 13 Oct 1994 17:17:08 -0700 Date: Thu, 13 Oct 1994 17:17:08 -0700 From: Tony Li Message-Id: <199410140017.RAA20838@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Thu, 13 Oct 1994 09:21:13 -0400 <9410131321.AA04384@snark.imsi.com> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Perry, > Walt is absolutely correct -- we must have some mechanism to partition > the network and provide abstraction. However, the current model of > one subnet per wire is incredibly restrictive. Why, precisely? I assume that you're asking this question about the second sentence. ;-) The address space can be seen as a hierarchically assigned namespace. The current model of one subnet per wire establishes a one-to-one correspondence between this namespace and the topology. Yet, for a large variety applications, you don't want a one-to-one mapping. Consider anycast, where you would like to have anycast to a variety of servers distributed throughout the topology. This is a case of one name, but you want multiple topological correspondences, so it's one to many. The case of multiple subnets per wire results from the hierarchical allocation being depleted or inappropriate for routing while the physical topology suffices. This is the many-to-one mapping. I hesitate to say what a many-to-many application would be, but I'm certain there will be one. I doubt it will take 20 years to find it. ;-) In any case, I can imagine an easy way around this. A routing information protocol could simply inform the hosts that they could reach all the given subnets directly. (Yet another reason for wanting smart end hosts instead of the lobotomized ones everyone seems to want.) Thus making proxy ARP a fundamental part of the protocol stack and eliminating any possibility for further optimzation of the first and last hops. No thanks. However, I speak for the future of your network -- my users are people operating real businesses with *real money* (meaning billions) on the line depending on these networks. If it helps, I speak for myself -- a person with *real money* (meaning millions, hopefully ;-) to make in providing a working solution. Look at it from my point of view. I'm a user with very nasty responsibilities. Market data systems DONT GO DOWN. If they do, you get your balls handed to you. I have existing, well shaken down protocols that I depend on -- my IPv4 networks work like champs day after day. I can easily make them fully redundant, self recovering, self monitoring, etc. Installations I work with routinely have staffs of dozens of overworked people worrying about their Novell crap which is used for nothing but office automation and a tiny staff managing a far more reliable IP network that the firm absolutely and completely depends on. Yes, and I'm probably one of the guys whose code is running your network. [Sorry, just a statistical comment -- no idea who you buy from.] We do have a vested interest in providing you with a reliable solution. I understand your position, but I don't understand your perspective in thinking that your desires are not taken into consideration. You _are_ the folks with money. ;-) I'm told that all sorts of new mechanisms no one has ANY operational experience with are going to be much better than these mechanisms. The existing mechanisms at one point had no operational experience and were a "new mechanism". We gained operational experience and discarded things that didn't work. I see no reason to do otherwise with IPv6. This *really* scares me to death. I have this sinking feeling that what is happening is that a good thing is getting destroyed by the second systems effect and I'm going to be forced to take giant steps backward in the reliability of my networks. Do you ever deploy new entities in your network? What do you do to insure yourself that something is working? I would hope that you test it. And if it doesn't work, you don't install it. If it doesn't work as part of IPv6, it doesn't become standard. Hell, that goes for IPv6, too. ;-) Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 17:27:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05363; Thu, 13 Oct 94 17:27:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05357; Thu, 13 Oct 94 17:26:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03584; Thu, 13 Oct 94 17:23:09 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA13185; Thu, 13 Oct 94 17:20:18 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08479; Fri, 14 Oct 1994 09:34:27 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00839; Fri, 14 Oct 94 09:06:08 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00723; Fri, 14 Oct 1994 09:06:07 EST Date: 11 Oct 94 10:44:52 +1100 To: ipng@sunroof.Eng.Sun.COM, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Subject: (IPng) COMMENTS ON IPNG ADDR ARCH Ua-Content-Id: 941011 10:29:34 P1-Recipient: ipng@sunroof.eng.sun.com, /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941011 10:29:34 010 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941011104452+1100 deferred 941011104452+1100 action Relayed Message-Id: <"941011 10:29:34"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, just a brief comment on this doc ipng-addr-00.txt section 2.3.3 NSAPs (what else I hear you say!) Is it possible to just say that NSAPs are supported until the format is final.. Jack h is submitting some text for this for the SIPP doc.. My preference is to just say. 2.3.3 NSAP Addresses NSAPs are supported in the IP6 addressing scheme. The format of the NSAP as carried is fully defined in [NSAP]. NSAPs are usually Unicast but can be Multicast if used for discovery or announcement purposes (eg ISH). (If the proposal is accepted for HbH Options for NSAP address extension the following text can be added).. The general format for the NSAP in the IP6 header is: 0000001/g + Length + 14 bytes of address Where the total length of the NSAP exceeds the basic form (14 bytes), the NSAP address extension option in the Hop By Hop Options can be used. The use of this option is indicated by the value in the NSAP Length field. The other comments on the document really relate to the use of terms "domain", "providor" and "subscriber" which I have covered in another post.. Thanks and Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 17:31:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05385; Thu, 13 Oct 94 17:31:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05376; Thu, 13 Oct 94 17:31:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03959; Thu, 13 Oct 94 17:27:26 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA14150; Thu, 13 Oct 94 17:26:25 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA21859; Thu, 13 Oct 1994 17:26:14 -0700 Date: Thu, 13 Oct 1994 17:26:14 -0700 From: Tony Li Message-Id: <199410140026.RAA21859@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Robert Elz's message of Thu, 13 Oct 1994 22:07:45 +1000 <9018.782050065@munnari.OZ.AU> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Proxy arp may be a problem, sometimes, but its also a fact of life. Its simply a case of people pushing the model beyond its original design. Unless the final model for V6 is so complex that it covers everything imaginable, and is thus incomprehensible, there will be people who will want to go outside whatever it anticipates... Those people will find some way to bend the rules, whatever the rules are. Something as ugly as proxy arp (which is not actually very ugly, comparatively, so this won't be hard to meet) is going to exist in any model. So you admit that the current model is deficient (i.e., proxy arp is ugly) and you posit that any future model will be imperfect (agreed), and therefore there is no point in having any future model? If we follow this reasoning, then we can say that IPv4 is deficient, IPv6 will certainly be deficient, and so why bother. Certainly a new model is incremental improvement. But that's all that we can EVER hope to make. Robust, mature, technology does not spring forth without incremental progress and learning. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 17:58:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05479; Thu, 13 Oct 94 17:58:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05473; Thu, 13 Oct 94 17:58:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06041; Thu, 13 Oct 94 17:54:34 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA18859; Thu, 13 Oct 94 17:54:03 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08707; Fri, 14 Oct 1994 09:39:33 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA00801; Fri, 14 Oct 94 09:04:38 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT00723; Fri, 14 Oct 1994 09:04:37 EST Date: 13 Oct 94 10:22:55 +1100 To: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, ipng@sunroof.Eng.Sun.COM Subject: (IPng) DISCOVERY AND MOBILITY -ARP Ua-Content-Id: 941013 09:22:39 P1-Recipient: /I=j/S=houldsworth/OU=ste0906/O=icl/P=icl/A=gold_400/C=gb/@x400gw.datacraft.com.au, ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941013 09:22:39 055 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941013102255+1100 deferred 941013102255+1100 action Relayed Message-Id: <"941013 09:22:39"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, general comments on ARP and the discovery doc.. It seems that ARP does satisfy MAC based address resolution, but as we move to connection oriented wide area networks and mobiles, that the discovery mobility model should be revamped.. Again coming from my humble background, the issue is now one of having a logical IP6 addressing scheme which must relate to MAC addresses and also relate (determine in fact) NSAP addresses (or E.164 addresses) for ISDN, B- ISDN, X.25 (X.121) addresses, DLCI pairs (for nailed up Frame Relay) and logical channel numbers (eg for PVCs on X.25 or ATM).. Also there is a need to authenticate the user, authenticate the service profile of the user, authenticate the terminal and the terminals profile.. plus as with mobility have the concept of cells that include a home base and roaming. My preference to approaching this is that the issues of address resolution, circuit knowledge is handled with at the ICMP level, that way the tie between connection endpoints, network numbering plans, logical circuits, etc and logical internetwork addressing can be "implementation" dependent (ie. does and dealt with at the "layer" that it impacts. Also it does not need a full blown Directory system on small scale networks). Thus an ARP or ICMP approach is OK for this. As the network topology grows diffrent rules apply.. see below A little gotcha here may be IP links which span interworking units.. eg Host A goes to X.25 (X.121 address).. through and ISDN gateway (E.164 address) and then onto a LAN (MAC address) for Host B .. what do you ARP here? But items such as Router Capability, Service Profiles and User / Terminal Management and Mobility should be developed as per BOOTP, RIP OSPF.. as "applications" over a transport or datagram service.. In fact in a larger more sophistcated network, the address knowledge can be transferred by this means thus saving on the quantity of lower level ARPs. So my comments on Discovery are that it should not combine address resolution with Service capability publication, Mobility and Router Maps (Network Topologies).. These should be developed (because there complexity will increase as the IP6 network grows - Kernel Bloat?, ICMP stability?) as separate functions that can be architected as client server applications as per eg SNMP, Bootp, etc. Also, not being totally informed (Antipodes problem) what is "System - Heard" used for.. the description is vague. Finally the care of address thing.. If mobility is to be taken seriously, why not allocate a IP6 address prefix to Mobiles, that way any network can direct any mobile device to its nearest "mobile server".. for tarriffing, authentication and redirection.. not efficient, but it will work. It is a better address administration model than having 'care of addresses'.. because of billing and authentication and the fact that cells for mobiles can be instigated by address allocation.. cell size and range can be optimised on cities, states , etc... comments please.. Regards Alan@Oz PS Jack h if this one does not also arrive from the list can you forward it please? ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 21:14:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05554; Thu, 13 Oct 94 21:14:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05548; Thu, 13 Oct 94 21:14:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15360; Thu, 13 Oct 94 21:11:02 PDT Received: from inet-gw-2.pa.dec.com ([16.1.0.23]) by Sun.COM (sun-barr.Sun.COM) id AA21465; Thu, 13 Oct 94 21:10:38 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA11400; Thu, 13 Oct 94 21:05:40 -0700 Received: by xirtlu.zk3.dec.com; id AA21375; Fri, 14 Oct 1994 00:05:34 -0400 Message-Id: <9410140405.AA21375@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Anycast Date: Fri, 14 Oct 94 00:05:28 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Anycast addresses are still a research effort regarding accessing an anycast address which will be handled by some node within that anycast address scope. There is also the problem where to perform anycast aliasing. Today one model of this type of network service to assume the anycast address is one member of a set of nodes on a subnet that fields the anycast packet (and that member can change). At some point it is more efficient for the member of that anycast subnet to communicate directly with the corresponding node source that sent the packet to the anycast address. There are numerous other architectural and processing concepts that need much thought like TCP connections changing members on the subnet for example that require much more research. Do we need to do anything in IPv6 to address this technology need with a standard or within the IPv6 architecture? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 21:23:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05570; Thu, 13 Oct 94 21:23:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05564; Thu, 13 Oct 94 21:23:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15721; Thu, 13 Oct 94 21:19:31 PDT Received: from inet-gw-2.pa.dec.com ([16.1.0.23]) by Sun.COM (sun-barr.Sun.COM) id AA22317; Thu, 13 Oct 94 21:19:05 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA11644; Thu, 13 Oct 94 21:14:30 -0700 Received: by xirtlu.zk3.dec.com; id AA21417; Fri, 14 Oct 1994 00:14:25 -0400 Message-Id: <9410140414.AA21417@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Terminology - Cluster Address Date: Fri, 14 Oct 94 00:14:19 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Our term of Cluster Address is not really correct. The Cluster Address is an aggregate which can represent a convenient method to reach a boundary router with a packet (for a reason not well defined yet) from within the scope of that Cluster Address. Or enter a part of the internet through a Cluster Address to reach the boundary router for the range of that cluster address from outside the domain of that cluster address. Wow.. No where in the definition is there a "Cluster" of anything relating to addresses. The only "concrete abstract" (which is what it is and why its hard to grasp) in the whole concept is the boundary router is reached if needed for some reason. I suppose like a source route to reach the entry or exist point of that boundary router. I propose we not call this "thing" a cluster address but a boundary address in the IPv6 specifications. Thats what it defines and is a more accurate reflection of what it is or will be or could be, if we figure out what to do with it from a network utlitarian perspective. Comments? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 22:36:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05605; Thu, 13 Oct 94 22:36:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05599; Thu, 13 Oct 94 22:36:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18430; Thu, 13 Oct 94 22:32:53 PDT Received: from databus.databus.com ([198.186.154.34]) by Sun.COM (sun-barr.Sun.COM) id AA28384; Thu, 13 Oct 94 22:32:30 PDT Date: Fri, 14 Oct 94 01:32 EDT Message-Id: <9410140132.AA06937@databus.databus.com> From: Barney Wolff To: conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. Content-Length: 2403 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Thu, 13 Oct 94 18:42:16 -0400 > From: conta@zk3.dec.com > > > - The processing model in which the first data packet of an unkown > > destination media address host is sent with a "IPv6 unicast/link-layer > > multicast" opens in my view the door to faulty or unexpected behavior. > > Without agreeing or disagreeing, may I ask for specifics on this? Are > you afraid that some implementation will think it's supposed to forward > the packet? > > Yes. There are many variations of this type of failure, which multiply with > the type of media that become available. > > Philosophycally, it is the "robustness" principle. ANY protocol which uses broadcast/multicast (doesn't matter which, for the moment) will get some packet into my host which I'm not supposed to forward. All that's required here is that the link layer hand upward what sort of link layer address got the packet into the machine. But it's easy to imagine that there are loads of internal IP-link_layer interfaces out there in the world today which throw that information away - in fact I suspect the standard BSD interface is one. And we shouldn't require that link drivers be re-written for IPv6. So the problem is not that under some obscure and rare set of circumstances a host will mistakenly forward a packet it shouldn't have, but that some or many implementations will have to face modification at the network-link layer interface. That's particularly disturbing, because the code at the two sides of that interface is often written by different organizations (as for example when using plug-in Ethernet adapters). I'm afraid that I've talked myself into fearing the ICMP-unicast / link-multicast model. There is a semi-kludgy way to rescue the piggybacking of the link address request onto sending the first packet. Suppose ARP was redefined to allow appending the contents of the packet? I would also convert to multicast based on a hash (simple or trivial) of the dest address, as that needs to be done where possible no matter what is being 'casted. The ARPng code knows it's never supposed to forward, unless it's proxying, so that concern goes away. If the packet is to be processed, the ARPng code can hand it to the IPv6 code, and since both are intimately related anyway, this is easy and not bug-prone. Can I get anybody else to buy this? Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 13 22:41:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05617; Thu, 13 Oct 94 22:41:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05611; Thu, 13 Oct 94 22:41:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18659; Thu, 13 Oct 94 22:37:18 PDT Received: from netcom15.netcom.com ([192.100.81.128]) by Sun.COM (sun-barr.Sun.COM) id AA28838; Thu, 13 Oct 94 22:36:57 PDT Received: by netcom15.netcom.com (8.6.9/Netcom) id WAA29388; Thu, 13 Oct 1994 22:35:06 -0700 Date: Thu, 13 Oct 1994 22:35:06 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199410140535.WAA29388@netcom15.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I'm hard to shut up on this issue too. In the last month we have >logged 37 instances of a system on our main bridged >network being automatically blocked in the bridges for exceeding >what we regard as the acceptable rate of single-source broadcasts. >The actual size of our bridged network is above 6000 active MAC addresses, >and we see at least 68 different Ethernet manufacturer codes. We are not >particularly happy about either of these numbers, but there are >good reasons for both of them. Of course this is a research lab, not >a bank, so the cost/performance/reliability tradeoffs are different >from yours. This number is interesting. Lets not blame ARP too quickly for your or any problems with these kindsof numbers. Based on what I heard at the implementors meeting it would seem that a network of this size is (may) have similar problems,a s you described, whether we use ARP or ICMP based address resolution. I think it was stated earlier that a correctly implemented ARP and a correctly implemented ICMP mechanism will both have the same potentials for problems and misuse. I am tending to believe that it is a link layer issue that should be left up to the link layer mechanisms (drivers) to solve the problem correctly. We should just outline the list of requirements we wish the link layer mechanism to support (ie: more than one subnet on a wire). > Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 00:39:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05643; Fri, 14 Oct 94 00:39:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05637; Fri, 14 Oct 94 00:39:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25017; Fri, 14 Oct 94 00:35:49 PDT Received: from inet-gw-2.pa.dec.com ([16.1.0.23]) by Sun.COM (sun-barr.Sun.COM) id AA20637; Thu, 13 Oct 94 21:02:39 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA11219; Thu, 13 Oct 94 20:57:18 -0700 Received: by xirtlu.zk3.dec.com; id AA21239; Thu, 13 Oct 1994 23:57:12 -0400 Message-Id: <9410140357.AA21239@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: IPv6 Subnets : Re: (IPng) Re: ARP In-Reply-To: Your message of "Thu, 13 Oct 94 17:17:08 PDT." <199410140017.RAA20838@lager.cisco.com> Date: Thu, 13 Oct 94 23:57:06 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I changed the header to IPv6 subnets as opposed to ARP. I can't take two discussions on one subject line anymore. The model right now as I see it is as follows which I guess we still have to discuss pro's and con's: 1. A link represents a wire. 2. A subnet will not span multiple links. 3. Multiple subnets can be on a single link. 4. A node can be a router or a host. 5. A node cannot have the same address on different subnets within the same Administrative Domain. The problem of a node N1 on subnet S1 on Link L1 communicating with node N2 on subnet S2 on Link L1 is a real problem. But why do they want to do this? But lets say there is a reason. This is a problem without using a router or a host that is also a router and all other solutions will cause hacks unless well thought out. Do we need to solve this NOW to get IPv6 up for interoperability testing in the scheme of things to do. In the scheme of things is this important today? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 00:48:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05655; Fri, 14 Oct 94 00:48:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05649; Fri, 14 Oct 94 00:48:11 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25428; Fri, 14 Oct 94 00:44:29 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA12663; Fri, 14 Oct 94 00:44:05 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA07196; Fri, 14 Oct 94 03:39:55 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410140739.AA07196@pluto.dss.com> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 14 Oct 1994 03:39:52 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <199410140535.WAA29388@netcom15.netcom.com> from "Richard Fox" at Oct 13, 94 10:35:06 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1242 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > This number is interesting [6000 MAC addresses]. Lets not blame ARP too quickly for your or > any problems with these kindsof numbers. Based on what I heard at the > implementors meeting it would seem that a network of this size is > (may) have similar problems,a s you described, whether we use ARP or > ICMP based address resolution. It is an interesting number being about the same size as common bridge learning tables. > I think it was stated earlier that a correctly implemented ARP and a > correctly implemented ICMP mechanism will both have the same > potentials for problems and misuse. Actually once ARP functionality is put into a network layer packet, the potential for problems and misuse increases because this new sort of ARP would not be confined to a single communications subnet but could be routed all over an internet. > > Brian Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 00:51:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05667; Fri, 14 Oct 94 00:51:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05661; Fri, 14 Oct 94 00:51:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25615; Fri, 14 Oct 94 00:47:33 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA12981; Fri, 14 Oct 94 00:47:12 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10752; Fri, 14 Oct 1994 08:47:10 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18545; Fri, 14 Oct 1994 08:47:08 +0100 Message-Id: <9410140747.AA18545@dxcoms.cern.ch> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 14 Oct 1994 08:47:08 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410132025.AA02809@pluto.dss.com> from "Joachim Martillo" at Oct 13, 94 04:25:22 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 495 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, > > But how can we evaluate claims about the evil of arp without seeing > some raw data. > I will ask my colleague Mike Gerard, who spend his days as our network traffic policeman, to put together a concrete summary of what we see. He just told me that he can't remember the last time a broadcast storm was NOT caused by ARP. BTW we consider that a single source that sends more than 550 Ethernet broadcasts in 10 seconds is above threshold. This was tuned by experience. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 01:01:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05680; Fri, 14 Oct 94 01:01:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05674; Fri, 14 Oct 94 01:01:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26149; Fri, 14 Oct 94 00:57:56 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA13849; Fri, 14 Oct 94 00:57:36 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA15889; Fri, 14 Oct 1994 00:57:35 -0700 Date: Fri, 14 Oct 1994 00:57:35 -0700 From: Tony Li Message-Id: <199410140757.AAA15889@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: bound@zk3.dec.com's message of Thu, 13 Oct 94 23:57:06 -0400 <9410140357.AA21239@xirtlu.zk3.dec.com> Subject: IPv6 Subnets : Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Do we need to solve this NOW to get IPv6 up for interoperability testing in the scheme of things to do. In the scheme of things is this important today? Yes. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 02:55:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05796; Fri, 14 Oct 94 02:55:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05790; Fri, 14 Oct 94 02:55:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29302; Fri, 14 Oct 94 02:51:48 PDT Received: from relay1.pipex.net ([158.43.128.4]) by Sun.COM (sun-barr.Sun.COM) id AA21526; Fri, 14 Oct 94 02:51:13 PDT X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Fri, 14 Oct 1994 10:50:29 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Fri, 14 Oct 1994 10:47:52 +0100 Date: Fri, 14 Oct 1994 10:47:52 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003917] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 3917 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"3917*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ipng@sunroof.Eng.Sun.COM Cc: BESBRODS , cassidy , colin.amor@intelsat.int, hvb@arch4.att.com, rpbrandt@attmail.com, alan@archway.demon.co.uk, lyman@BBN.com, danthine@vm1.ulg.ac.be, frommi@zfe.siemens.de, pag@mci.org.uk, JEAN-FRANCOIS.GORNET@PRINCE.atlas1.edf.fr, josef.haas@fh-aalen.de, jnk@cclab.cau.ac.kr, kino@nttmhs.ntt.jp, " (Keith G Knightson)" , lee@ntd.comsat.com, sleistner@attmail.com, bobl@tmx.mhs.oz.au, arne.litlere@ntra.telemax.no, bcshin@eekaist.kaist.ac.kr, Schulte W , gsmith@werple.apana.org.au, monicas@vnet.ibm.com, magnus@vnet.IBM.COM, bruce-steer@saa.sa.telememo.au, rjthomas@bnr.ca, /G=matti/S=vasara/O=sty/@elisa.fi, jwheel@attmail.com, /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net Subject: (IPng) Hop by Hop extension for full NSAPs - Proposed Text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 See attached ------------------------------ Start of body part 2 >From Jack Houldsworth - SC6 liaison. Our preference is for the Lloyd scheme which is repeated below with some specimen text for the SIPP (IP6) spec. I hope that the editors can work this into the draft text before the BOFs in San Jose? BASIC PROPOSAL: IP address is: 0000001/g + Length + 14 bytes .. where: Length = (<=14) NSAP in IP6 remaining 14 bytes Length = (128 +12) IPX address ** Length = (>14) NSAP fragment in HbH option Length = 0 or 255, etc Full NSAP address in HbH option HBH Option - NSAP Address Extension Type = a = NSAP src fragment b = NSAP dest fragment c = NSAP src complete d = NSAP dest complete ** IPX addressing. Should IPX addresses share the same IP6 Address prefix as NSAPs then the IPX address form can be indicated by the length field set to 128 + 12 to indicate an IPX address follows. All that needs to be done formally is to allocate some Hop By Hop option identifiers for NSAP address extension headers in section 4.2 or 4.3 of the current SIPP document and remove some of the text in section 2.3.3 Ipng Addressing Architecture. The NSAP document will also need reworking. The preference here is for the NSAP document to detail the use of IP6 addresses as 20 byte NSAPs and formalise the use of NSAPs in their various forms within IP6 and how they utilise either the basic 16 byte addressing space or the Hop by Hop option as an Address Extension option. SPECIMEN TEXT for SIPP section 2.3 or 2.4 Note: the text below uses "option" as the the primary term and the term 'parameter' as the option's parameters. The current SIPP text uses 'option' for both parts and this could confuse the reader. This point has been raised out before. NSAP Extension Option Option Type = NSAP Extension.. ** value to be assigned.. The NSAP Extension Option is a Hop by Hop Option and permits the full carriage of ISOs 20 byte NSAPs in IP6 protocol. Where the complete NSAP can be encoded in 14 bytes or less, this option is not needed and the NSAP can be conveyed in the primary address field of the IP6 header. Where this length is exceeded, provision is made to carry the remainder (or the full NSAP) in this Hop by Hop Option. The IP adddress format for the header is 0000001/g + Length + 14 bytes of address where: Length = <= 14 .. NSAP in Address field. Length = > 14 .. NSAP fragment in Extension Option Length = 255 .. Full NSAP in Extension Option Where the NSAP Extension option is used, the option contains one or more parameters encoded as Type / Length / Value. The top two bits of each option parameter Type indicate what action should be taken if the SIPP node does not recognise this option parameter. Bit settings of 00, 01 and 11 will cause the packet to be discarded. Bit settings of 10 will cause an ICMP Unrecognised Type message to be sent to the packet's source address, pointing to the unrecognised Option (parameter) type. In this case if the source address is found to be in error, the packet is discarded. The third highest bit of the option parameter Type indicates if this parameter is to be included in integrity checks. 0 = include in integrity computation 1 = exclude from integrity computation Option Parameters The NSAP Extension option contains one or more 'parameters' which are or the format "Parameter Type, Parameter Data Length, Parameter Data where: Parameter Type: top 3 bits defined above. Parameter Type: lower 5 bits defined as follows: Parameter Type = 1 NSAP Fragment Source Parameter Type = 2 NSAP Fragment Destination Parameter Type = 3 NSAP Complete Source Parameter Type = 4 NSAP Complete Destination Parameter Data Length = 8 bit unsigned integer. Length of the 'parameter' in octets. Parameter Data = NSAP.. complete or fragment. Padding. The NSAP Extension Option, where required, is given eight byte alignment using the padding parameter in the last position of the parameter sequence. This parameter's length is included in the Options overall length specification. Note: The level of support for NSAPs and the interworking of NSAPs with IP6 addresses as provided by any node is implementation specific and beyond the scope of this document. ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 04:11:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05848; Fri, 14 Oct 94 04:11:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05842; Fri, 14 Oct 94 04:11:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00592; Fri, 14 Oct 94 04:08:02 PDT Received: from newdev.harvard.edu ([128.103.203.53]) by Sun.COM (sun-barr.Sun.COM) id AA29100; Fri, 14 Oct 94 04:07:41 PDT Received: by newdev.harvard.edu (5.64/Tenon-1.35.01) id AA01074; Fri, 14 Oct 94 07:09:00 -0400 (EDT) Date: Fri, 14 Oct 94 07:09:00 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) Message-Id: <9410141109.AA01074@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Charlie, As I remember the discussions the final idea was to allow the routers to advertise an address prifix if so configured. If the node had received such a message and the destination address matched the included prifix then it would go ahead and use an ARP model on the local lan. the routers would be involved if the destination did not match the prefix (just like the current model) or if the node had received router advertisements but they did not include prefix information. as you said, if no router messages have been received then the node must always assume that the dest is on the same lan and thus run an ARP request/response to see if it can find the dest. under the above, if the user configures the router to send out address prefixes then everything works as it does now, if the configuration is set to not send out prefixes then the router would be part of all session startups. i.e. its up to the network manager. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 04:15:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05864; Fri, 14 Oct 94 04:15:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05858; Fri, 14 Oct 94 04:15:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00645; Fri, 14 Oct 94 04:11:54 PDT Received: from newdev.harvard.edu ([128.103.203.53]) by Sun.COM (sun-barr.Sun.COM) id AA29473; Fri, 14 Oct 94 04:11:33 PDT Received: by newdev.harvard.edu (5.64/Tenon-1.35.01) id AA01078; Fri, 14 Oct 94 07:12:51 -0400 (EDT) Date: Fri, 14 Oct 94 07:12:51 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) Message-Id: <9410141112.AA01078@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Terminology - Cluster Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, I see a cluster address as an abstraction representing some chunk of the network. I would expect that there are some times when one wants to reach the boundary of the cluster but also some times when one might want to say 'any node/router in the cluster' I do not support the change in name. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 04:19:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05876; Fri, 14 Oct 94 04:19:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05870; Fri, 14 Oct 94 04:19:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00725; Fri, 14 Oct 94 04:16:03 PDT Received: from newdev.harvard.edu ([128.103.203.53]) by Sun.COM (sun-barr.Sun.COM) id AA29801; Fri, 14 Oct 94 04:15:28 PDT Received: by newdev.harvard.edu (5.64/Tenon-1.35.01) id AA01090; Fri, 14 Oct 94 07:16:38 -0400 (EDT) Date: Fri, 14 Oct 94 07:16:38 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) Message-Id: <9410141116.AA01090@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Suppose ARP was redefined to allow appending the contents of the packet? there are MTU related problems with this. when this happens the 1st packet is larger then the rest of the packets in a stream but only if there is no cached MAC address info. it seems to add confusion for little gain. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 05:13:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05916; Fri, 14 Oct 94 05:13:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05909; Fri, 14 Oct 94 05:12:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01421; Fri, 14 Oct 94 05:09:12 PDT Received: from watson.ibm.com ([129.34.139.4]) by Sun.COM (sun-barr.Sun.COM) id AA02687; Fri, 14 Oct 94 05:08:51 PDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0165; Fri, 14 Oct 94 08:08:49 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 4459; Fri, 14 Oct 1994 08:08:49 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 14 Oct 94 08:08:49 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA21725; Fri, 14 Oct 1994 08:08:42 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9410141208.AA21725@hawpub1.watson.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: (Your message of Fri, 14 Oct 94 07:09:00 D.) <9410141109.AA01074@newdev.harvard.edu> Date: Fri, 14 Oct 94 08:08:42 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott, For subnets (or prefixes) with many hosts, I think it is at least worthwhile to consider ways to decrease the number and need for broadcasts. And, as the famous bank robber might have said, if you want a MAC address you can go to a place that has lots of them -- a router. If the router doesn't have the information, it will have to do a broadcast, but there's a good chance that it won't have to. My main idea was that both models can operationally co-exist. We can let hosts (...and, the market) decide whether or not to always ARP -- they have to have the capability to do so for routerless networks anyway. It would be nice if the broadcast was not always required, for those administrative domains that would rather let the routers do the work. I mentioned in my previous note what I thought some of the benefits of the latter strategy would be. I like models of operation where individual non-server nodes aren't "pestered" (e.g, by broadcasts). Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 05:34:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05949; Fri, 14 Oct 94 05:34:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05943; Fri, 14 Oct 94 05:33:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01846; Fri, 14 Oct 94 05:30:14 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA04390; Fri, 14 Oct 94 05:29:52 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28421; Fri, 14 Oct 1994 13:29:50 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03026; Fri, 14 Oct 1994 13:29:48 +0100 Message-Id: <9410141229.AA03026@dxcoms.cern.ch> Subject: Re: IPv6 Subnets : Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 14 Oct 1994 13:29:47 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410140357.AA21239@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Oct 13, 94 11:57:06 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2092 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, > 1. A link represents a wire. > 2. A subnet will not span multiple links. Have we defined "wire"? Is an ATM Logical IP Subnet (LIS, using RFC 1577 terminology) a "wire"? Brian -----extract from RFC1577------ 3. IP Subnetwork Configuration In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LISs on the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is an ATM Endpoint attached to the ATM network that is configured as a member of one or more LISs. This configuration may result in a number of disjoint LISs operating over the same ATM network. Hosts of differing IP subnets MUST communicate via an intermediate IP router even though it may be possible to open a direct VC between the two IP members over the ATM network. The requirements for IP members (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number and address mask [8]. o All members within a LIS are directly connected to the ATM network. o All members outside of the LIS are accessed via a router. o All members of a LIS MUST have a mechanism for resolving IP addresses to ATM addresses via ATMARP (based on [3]) and vice versa via InATMARP (based on [12]) when using SVCs. Refer to Section 6 "Address Resolution" in this memo. o All members of a LIS MUST have a mechanism for resolving VCs to IP addresses via InATMARP (based on [12]) when using PVCs. Refer to Section 6 "Address Resolution" in this memo. o All members within a LIS MUST be able to communicate via ATM with all other members in the same LIS; i.e., the virtual Connection topology underlying the intercommunication among the members is fully meshed. ... ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 06:23:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05977; Fri, 14 Oct 94 06:23:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05968; Fri, 14 Oct 94 06:22:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03237; Fri, 14 Oct 94 06:19:16 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA08956; Fri, 14 Oct 94 06:18:51 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA27425; Fri, 14 Oct 94 09:14:43 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410141314.AA27425@pluto.dss.com> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 14 Oct 1994 09:14:42 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9410140747.AA18545@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Oct 14, 94 08:47:08 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2284 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Joachim, > BTW we consider that a single source that sends more than > 550 Ethernet broadcasts in 10 seconds is above threshold. > This was tuned by experience. > Brian A reasonable implementation of ARP would maintain a queue of some maximum number of outstanding unique (by destination IP address) ARP requests. Associated with each ARP request should be a queue of data packets destined for the IP address being resolved. There should be a maximum number of ARP retries for a given ARP queue entry, and each separate ARP attempt should be given an interval of time before being declared as failed. If the ARP queue is full, and a new ARP request is to be made, this ARP request can only be added to the ARP queue after removing the first element on the ARP queue. The first ARP queue element can only be removed if the first element on the queue has timed out at least once. ARP table entries should have a reasonable timeout. ARP table entries whose corresponding MAC address learning table entries have been removed from the learning table should be removed from the ARP table. Any ARP functionality which does not follow a procedure like what is above will have major problems whether it is implemented at the link or network layer. As for the threshold in your network, given that you have a bridged communications subnet with over 6000 MAC addresses, it is not impossible to exceed your threshold legitimately (without a broadcast storm due to misoperation). If hosts on another subnet connected by a router to your subnet suddenly need to communicate with several thousand hosts on your subnet whose addresses have not been resolved by the router and who respond immediately to ARP requests, bursts of several thousand ARP requests from the router could occur. But such bursts could occur whether the ARP functionality operates at the link layer or at the network layer. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 07:00:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06018; Fri, 14 Oct 94 07:00:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06012; Fri, 14 Oct 94 06:59:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05032; Fri, 14 Oct 94 06:56:12 PDT Received: from bridge2.NSD.3Com.COM ([129.213.128.4]) by Sun.COM (sun-barr.Sun.COM) id AA13689; Fri, 14 Oct 94 06:55:51 PDT Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA00641 (5.65c/IDA-1.4.4nsd for ); Fri, 14 Oct 1994 06:55:50 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA09102 (5.65c/IDA-1.4.4-910725 for ); Fri, 14 Oct 1994 06:55:48 -0700 Message-Id: <199410141355.AA09102@remmel.NSD.3Com.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Thu, 13 Oct 1994 17:42:23 EDT." <9410132142.AA06367@brigit.zk3.dec.com> Date: Fri, 14 Oct 1994 06:55:47 -0700 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Walt is absolutely correct -- we must have some mechanism to partition > the network and provide abstraction. However, the current model of Agreed. And this model SHOULD allow for logical partitioning on the same wire. > Consider what happens right now if I have Host A, Host B and Router C > on the same subnet where A and B are not in the same subnet. To > exchange packets, you either have to do warped configuration (tell A > that it can route directly to B and vice versa) OR the two hosts talk > via the router, with everything taking two hops on the LAN. This is a > clear case where the inflexibility in the model results in a horrible > result. Sometimes the "horrible result" is exactly what is wanted/needed. While I agree that in many, perhaps most, situations, it is desirable to eliminate the extra hop, there are a number of applications where enforcing the extra hop through a router for hosts with different subnet addresses is highly desirable. Testing new addressing plans, logically prototyping new physical topologies, trial deployment of new services, ... Most of these uses are of a temporary nature, but the feature should be available. IPv6 must not eliminate the ability to provide logical separation, and in fact, it should be possible to configure a host to enforce the logical separation. Tracy ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 07:23:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06037; Fri, 14 Oct 94 07:23:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06031; Fri, 14 Oct 94 07:23:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06303; Fri, 14 Oct 94 07:19:39 PDT Received: from gosip.net.ohio.gov ([156.63.130.6]) by Sun.COM (sun-barr.Sun.COM) id AA17442; Fri, 14 Oct 94 07:19:17 PDT Received: from [156.63.209.39] (macip-bbrho3-39.net.ohio.gov) by gosip.net.ohio.gov (PMDF V4.3-7 #3232) id <01HI9HCKWH4W000N4Z@gosip.net.ohio.gov>; Fri, 14 Oct 1994 10:19:09 EST Date: Fri, 14 Oct 1994 10:13:44 -0500 From: warner@ohio.gov (Bill Warner) Subject: Re: (IPng) Re: ARP X-Sender: warner@pop3.postoffice.ohio.gov. To: ipng@sunroof.Eng.Sun.COM Message-Id: <01HI9HCMK7ZM000N4Z@gosip.net.ohio.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From the discussion, it appears that there is consensus on two things: There are things we might like to change about ARP if we could, and that it does work. If it didn't it wouldn't still be around. Maybe what we should be considering is not whether ARP should be changed at all, but what changes could be made. It may be reasonable to change the model, if we can get a big win for a little effort, but not if the big win takes a big change. It might be easier to reach a consensous on questions with a little more meat to them. So I thought I would just throw out a possible change: One possible minor change, is to take a idea from the CLNS model when running with out an router on a broadcast type media. In this case, CLNS uses a model very similar to ARP, with a couple of interesting changes. As in IP, each host/ES keeps a table of Network Addresses and Subnetwork Addresses (an ARP table, no matter what you call it). This table is filled anytime a packet is received by the ES, since each packet has this information. (See below if you are concerned about the overhead of doing this for every packet.) If the ES wants to send a packet to an network address, it looks in its table, and if it is there uses the associated Subnetwork Address. If it is not in its table it sends the packet to the ALL-ES's multicast. Each ES looks at the network address and decides if the packet is for it, and if so, updates its 'arp table' (Actually all the hosts that see it could do this, maybe in this case the host doesn't need to update the arp table for every packet only multicasted ones.) The ES then handles the packet just as if it was sent directly to it. The return packet, if any, would go directly since the 'arp table' has the subnetwork address information from the multicast packet. Essentially instead of a specific ARP packet, it uses data it needs to send any way. This removes the ARP round trip delay. Also, it works independantly of the addressing of the subnetwork or wire. If there are more than one subnetwork (addressing-wise) on the wire, this still works if everyone listens to the same multicast. This might be able to be extended so it works instead of a specific router discovery mechanism, but I haven't thought much about this, but I can ramble a little: If the packet was sent from a router the 'arp table' will have the router's subnetwork address. (This may or may not be done this way, if the ES has some information about the topology of the network, it may think that it needs to pass the packet to the router and would need to specifically enter this in its table.) I don't know whether the router could (or even should) do something logcally like proxy arp (actually it would be proxy forwarding, since it would just try to get the packet to the correct destination, if it didn't think it was on the local subnetwork.) ww3 -------------- Bill Warner, N8HJP warner@ohio.gov State of Ohio - Office of Telecommuncations +1 614 466 6683 (Toll Free in 2151 Carmark Road Ohio, 950-1OHI, wait for dial tone, then 6-6683) Columbus, OH 43221 +1 614 644 3349 FAX ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 07:49:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06123; Fri, 14 Oct 94 07:49:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06117; Fri, 14 Oct 94 07:49:12 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07970; Fri, 14 Oct 94 07:45:29 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA21476; Fri, 14 Oct 94 07:45:08 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22683; Fri, 14 Oct 1994 15:45:05 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09577; Fri, 14 Oct 1994 15:45:03 +0100 Message-Id: <9410141445.AA09577@dxcoms.cern.ch> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 14 Oct 1994 15:45:03 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410141314.AA27425@pluto.dss.com> from "Joachim Martillo" at Oct 14, 94 09:14:42 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 635 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, I would be delighted if all ARP implementations used the algorithm you describe (and if they allowed for an arbitrary size of ARP cache without rebuilding the kernel). You are correct, on a large network, reasonably legitimate behaviour can lead to unpleasantly high rates of ARP. That is close to expressing why I don't like the ARP design paradigm: if the nature of ARP forces me to make my subnets smaller than a particular size, there is something wrong. Rather, the discovery protocol should work on any reasonable size subnet. (Although I am the first to admit that our >6000 node "subnet" is unreasonable.) Brian ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 08:22:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06157; Fri, 14 Oct 94 08:22:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06145; Fri, 14 Oct 94 08:22:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10632; Fri, 14 Oct 94 08:18:46 PDT Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by Sun.COM (sun-barr.Sun.COM) id AA27015; Fri, 14 Oct 94 08:18:22 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA26170; Fri, 14 Oct 94 08:03:44 -0700 Received: by xirtlu.zk3.dec.com; id AA22750; Fri, 14 Oct 1994 11:03:40 -0400 Message-Id: <9410141503.AA22750@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Terminology - Cluster Address In-Reply-To: Your message of "Fri, 14 Oct 94 07:12:51 EDT." <9410141112.AA01078@newdev.harvard.edu> Date: Fri, 14 Oct 94 11:03:34 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott, > I see a cluster address as an abstraction representing some >chunk of the network. I would expect that there are some times >when one wants to reach the boundary of the cluster but also some >times when one might want to say 'any node/router in the cluster' The only way that some node could reach "any node/router" in the cluster would be the same way any node could reach the boundary router in the cluster today based on what has been suggested. It would be hard configured. The same applies to what you suggest. None of this right now can be specified via autoconfiguration as we have no model or discussion of such design. I do not believe that users will want hard configuration within the cluster, but may accept configuration for boundary routers. Thus I see no use of this address at all in any draft that can technically justify a purpose for what you suggest. Nor could vendors just invent their own unless done in a proprietary manner and I would rather not open options to vendors to do proprietary functions in IPv6 in the way we define the standard (this is why I support any translation in the IPv6 transition plan so it has some definition if used). But this will happen anyway I am sure. But you have not convinced me there is another use for an address which we have not found a good use for the key priniciple we have coined the term Cluster address. > I do not support the change in name. At the implementors meeting several folks talked this out and felt the term was bogus as is today. So I will wait to here if we get more input on this pro or con for awhile and see what happens within the working group per this discussion. So would other folks reply if you support this change in name too or I am going to drop it (which was my intention in the first place). My objective is to force clarity when this is deployed some day and Cluster Address will cause confusion as it has continually in the previous SIPP WG and now the IPng WG. I think the name causes much of the problem anc it will for future users when designing their networks to use IPv6. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 08:22:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06158; Fri, 14 Oct 94 08:22:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06151; Fri, 14 Oct 94 08:22:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10638; Fri, 14 Oct 94 08:18:50 PDT Received: from rodan.UU.NET ([153.39.128.10]) by Sun.COM (sun-barr.Sun.COM) id AA27026; Fri, 14 Oct 94 08:18:28 PDT Received: by rodan.UU.NET id QQxlpd21018; Fri, 14 Oct 1994 11:18:26 -0400 Date: Fri, 14 Oct 1994 11:18:26 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ARP.... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM dynamic binding always has a cost, and ARP is classic dynamic binding (it is even non-persistant and requires periodic rebinding) this is powerful machinery and it has a cost under what circumstances is the machinery worth the cost and under what circumstances is it not? under what circumstances are "directly computable" addresses worthwhile (hear a prefix announcment and append to local identity bits to create a working address) and under what circumstances do you want more rope? these are the kinds of questions to ask if we are taking about taking a chain-saw to ARP.... -mo ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 08:45:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06179; Fri, 14 Oct 94 08:45:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06173; Fri, 14 Oct 94 08:45:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12333; Fri, 14 Oct 94 08:41:32 PDT Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by Sun.COM (sun-barr.Sun.COM) id AA01668; Fri, 14 Oct 94 08:41:04 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA27952; Fri, 14 Oct 94 08:27:08 -0700 Received: by xirtlu.zk3.dec.com; id AA24929; Fri, 14 Oct 1994 11:27:01 -0400 Message-Id: <9410141527.AA24929@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: IPv6 Subnets : Re: (IPng) Re: ARP In-Reply-To: Your message of "Fri, 14 Oct 94 13:29:47 BST." <9410141229.AA03026@dxcoms.cern.ch> Date: Fri, 14 Oct 94 11:26:55 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian, >> 1. A link represents a wire. >> 2. A subnet will not span multiple links. >Have we defined "wire"? Is an ATM Logical IP Subnet (LIS, using RFC 1577 >terminology) a "wire"? Yes that is my view of any link. But I am not sure its everyones, hence, I sent this mail. This discussion can stop very quickly if in the address spec and then pointed to in the IPv6 spec there is wording such as the statemets below: --------------------------------- If two nodes are on the same link but using different prefix subnets within their global IPv6 address want to communicate they MUST do so through a router. --------------------------------- Now if folks want this to be different we need to come up with: 1. Why - Whats the market requirement. 2. Then whats the design center to begin discussion. 3. What link technology can the design center support. 4. What are the possible implementation scenarios we can build the design center with. I think this work borders closely to changing the core architecture model of the Internet Engineering Model and think we should just use my text above to make sure folks don't try to do this in an open systems implementation. But if we want to try then I just want to understand what exactly we are going to do if we have to implement this and why. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 08:48:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06191; Fri, 14 Oct 94 08:48:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06185; Fri, 14 Oct 94 08:48:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12556; Fri, 14 Oct 94 08:44:47 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA02210; Fri, 14 Oct 94 08:44:24 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA28784; Fri, 14 Oct 94 11:40:12 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410141540.AA28784@pluto.dss.com> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 14 Oct 1994 11:40:10 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9410141445.AA09577@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Oct 14, 94 03:45:03 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1947 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Joachim, > You are correct, on a large network, reasonably legitimate behaviour can > lead to unpleasantly high rates of ARP. That is close to expressing > why I don't like the ARP design paradigm: if the nature of ARP forces me > to make my subnets smaller than a particular size, there is something > wrong. Rather, the discovery protocol should work on any reasonable size > subnet. (Although I am the first to admit that our >6000 node "subnet" is > unreasonable.) > Brian Just one note. A fully powered Ethernet packet-switch acting as an Ethernet router should be able to handle 5000 arp transactions per second. Today a fully powered packet-switch can be built at reasonable cost per interface without special hardware assists with an ordinary processor, memory and standard ether interfaces albeit with careful crafting of hardware to software and of software to hardware. The trick is the identification of such high performance reasonably priced systems (but that problem is true of purchasing any system). Writing standards for constraints imposed by the misbehavior of mediocre devices can effectively drive out of the market high performance reasonably priced systems (Gresham's law applied to manufacturing regimes so to speak) because all possibility of making use of the higher performance is eliminated. If the ARP issue is just the first example of trying to write IPv6 standards for the constraints imposed by mediocre devices, the ultimate result of the IPv6 standardization process could immensely lower network performance. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 09:16:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06254; Fri, 14 Oct 94 09:16:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06248; Fri, 14 Oct 94 09:16:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15245; Fri, 14 Oct 94 09:12:59 PDT Received: from feta.cisco.com ([131.108.13.70]) by Sun.COM (sun-barr.Sun.COM) id AA07982; Fri, 14 Oct 94 09:12:35 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id JAA13360; Fri, 14 Oct 1994 09:12:32 -0700 Date: Fri, 14 Oct 1994 09:12:32 -0700 From: Dave Katz Message-Id: <199410141612.JAA13360@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: bound@zk3.dec.com's message of Fri, 14 Oct 94 11:26:55 -0400 <9410141527.AA24929@xirtlu.zk3.dec.com> Subject: IPv6 Subnets : Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This discussion can stop very quickly if in the address spec and then pointed to in the IPv6 spec there is wording such as the statemets below: --------------------------------- If two nodes are on the same link but using different prefix subnets within their global IPv6 address want to communicate they MUST do so through a router. --------------------------------- I would amend this slightly (or be creative in my interpretation) to say that a router may choose to redirect the hosts to communicate directly (assuming the new-model redirects containing media information) and it should work Just Fine. (Another reason why I'm resistant to hosts being overly subnet-knowledgable). ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 09:45:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06342; Fri, 14 Oct 94 09:45:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06206; Fri, 14 Oct 94 08:55:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13134; Fri, 14 Oct 94 08:51:17 PDT Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA03564; Fri, 14 Oct 94 08:50:48 PDT Received: by nero.dcrc.com (4.1/1.34) id AA10858; Fri, 14 Oct 94 11:50:42 EDT Date: Fri, 14 Oct 94 11:50:42 EDT From: mad@nero.dcrc.com (Michael A. Davis) Message-Id: <9410141550.AA10858@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9410141503.AA22750@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: (IPng) IPv6 Terminology - Cluster Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott, Jim, et al, >From what I remember of the discussions in Cambridge, there was an additional issue of what happens when a node sends to a "Cluster address" from within the cluster. If I understand Jim's proposal, we rename and/or redfine "Cluster Address" to some sort of "Boundary Address." If so, I think that would both be clearer and address the "inside the cluster" issue. From: bound@zk3.dec.com Scott, > I see a cluster address as an abstraction representing some >chunk of the network. I would expect that there are some times >when one wants to reach the boundary of the cluster but also some >times when one might want to say 'any node/router in the cluster' The only way that some node could reach "any node/router" in the cluster would be the same way any node could reach the boundary router in the cluster today based on what has been suggested. It would be hard configured. The same applies to what you suggest. None of this right now can be specified via autoconfiguration as we have no model or discussion of such design. I do not believe that users will want hard configuration within the cluster, but may accept configuration for boundary routers. Thus I see no use of this address at all in any draft that can technically justify a purpose for what you suggest. Nor could vendors just invent their own unless done in a proprietary manner and I would rather not open options to vendors to do proprietary functions in IPv6 in the way we define the standard (this is why I support any translation in the IPv6 transition plan so it has some definition if used). But this will happen anyway I am sure. But you have not convinced me there is another use for an address which we have not found a good use for the key priniciple we have coined the term Cluster address. > I do not support the change in name. At the implementors meeting several folks talked this out and felt the term was bogus as is today. So I will wait to here if we get more input on this pro or con for awhile and see what happens within the working group per this discussion. So would other folks reply if you support this change in name too or I am going to drop it (which was my intention in the first place). My objective is to force clarity when this is deployed some day and Cluster Address will cause confusion as it has continually in the previous SIPP WG and now the IPng WG. I think the name causes much of the problem anc it will for future users when designing their networks to use IPv6. /jim -- - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + Mike Davis + Do not use the return address + + Penril Datability Networks + Use mike@dss.com + + 190 North Main Street +- -- -- -- -- -- -- -- -- -- -- -+ + Natick, MA 01760 + "POST NO BILLS" + - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 09:46:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06357; Fri, 14 Oct 94 09:46:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06130; Fri, 14 Oct 94 07:56:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08707; Fri, 14 Oct 94 07:53:01 PDT Received: from ceres.fokus.gmd.de ([192.35.149.15]) by Sun.COM (sun-barr.Sun.COM) id AA22588; Fri, 14 Oct 94 07:52:38 PDT Message-Id: <9410141452.AA22588@Sun.COM> Received: from fokus.gmd.de by ceres.fokus.gmd.de id <02360-0@ceres.fokus.gmd.de>; Fri, 14 Oct 1994 15:50:43 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: IPv6 Subnets : Re: (IPng) Re: ARP Date: Fri, 14 Oct 1994 15:50:43 +0100 From: Joerg Micheel Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM # > 1. A link represents a wire. # > 2. A subnet will not span multiple links. # Have we defined "wire"? Is an ATM Logical IP Subnet (LIS, using RFC 1577 # terminology) a "wire"? I believe not. A "wire" means that IP entities on different nodes could potentially communicate with each other directly, provided that the addresses assigned to them enable this (LIS). That way, an ATM Network itself is a wire, if it permits data transmission between two IP implementations on different nodes (there exists either a permanent bidirectional AAL5 VPConnection or there could one be established via signalling). This "wire" could be used for carrying messages within several subnets if both nodes belong to more than one LIS. That way a LIS is not a wire ... Joerg ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 09:55:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06375; Fri, 14 Oct 94 09:55:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06369; Fri, 14 Oct 94 09:55:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18551; Fri, 14 Oct 94 09:51:31 PDT Received: from newdev.harvard.edu ([128.103.203.53]) by Sun.COM (sun-barr.Sun.COM) id AA15270; Fri, 14 Oct 94 09:49:57 PDT Received: by newdev.harvard.edu (5.64/Tenon-1.35.01) id AA01617; Fri, 14 Oct 94 12:51:05 -0400 (EDT) Date: Fri, 14 Oct 94 12:51:05 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) Message-Id: <9410141651.AA01617@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: IPv6 Subnets : Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > --------------------------------- If two nodes are on the same link but using different prefix subnets within their global IPv6 address want to communicate they MUST do so through a router. I see no reason to constrain the user to this 'classical' model of the way that networks work and see many reasons not to Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 10:11:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06387; Fri, 14 Oct 94 10:11:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06381; Fri, 14 Oct 94 10:11:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19927; Fri, 14 Oct 94 10:07:26 PDT Received: from uu2.psi.com ([128.145.228.2]) by Sun.COM (sun-barr.Sun.COM) id AA17712; Fri, 14 Oct 94 10:04:10 PDT Received: from port16.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06243 for ipng@sunroof.eng.sun.com; Fri, 14 Oct 94 12:55:02 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA09059; Fri, 14 Oct 1994 09:53:43 -0700 Message-Id: <199410141653.JAA09059@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Anycast In-Reply-To: Your message of Fri, 14 Oct 94 00:05:28 -0400. <9410140405.AA21375@xirtlu.zk3.dec.com> From: Craig Partridge Date: Fri, 14 Oct 94 09:53:40 -0700 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Jim: That's a good question, and Steve Deering periodically beats me over the head with it because I'd promised some time ago to write up a follow up to RFC 1546 saying what anycasting is and isn't good for and I haven't written anything yet (because every time I poll folks I get different answers). In brief, here's my sense of the state of anycasting. * People like the concept. It has clear utility, for example, for replicated servers. One can just, for instance, have a name like home-page.www.net mapped to a single address that is replicated everywhere. Other examples arise in host configuration (bootservers have anycast addresses). And one doesn't have to use expanding TTL multicast searches to find an anycast server. * The execution is problematic on several levels: 1. If the nodes for a given anycast address are scattered through the Internet, we currently have to advertise host routes for the anycast address into the global net. So routing tables have a new component (anycast host routes) which grow proportional to the number of network services (e.g., number of different types of replicated services you'd like to offer -- imagine, every FTP archive gets its own routing table entry!). There may be solutions to this problem -- PIM-like rendezvous points, etc., but right now, no one's looking at the issue. 2. The semantics of anycast is that you get the "nearest" anycast address. But many folks really want not the nearest but "best", where best is whatever they define "best" to be. Normally the answer to this question is "tough, routing protocols don't do that" but for anycasting, the anycast hosts have to participate, at least a little, in routing protocols (to advertise themselves) which means they could play games like varying their metric based on load. (Tony & Noel -- don't shoot! -- I'm not saying we should do this, just that someone will). 3. Recognizing anycast addresses for protocols like TCP. There are ways to permit TCP connections to anycast addresses but it requires that TCP be able to recognize an anycast address on inspection. (Or we have to arrange some type of TCP option in the SYN). * Note that in a subnet, you can finesse some of these problems, so, for instance, support for anycast in ATM has some utility with much less pain. However, this also means that at some point in the future we're likely to see subnet anycast (which may place pressure on us to put anycast into IPv6). Hope this helps! Craig ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 11:18:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06493; Fri, 14 Oct 94 11:18:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06487; Fri, 14 Oct 94 11:18:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25649; Fri, 14 Oct 94 11:14:44 PDT Received: from databus.databus.com ([198.186.154.34]) by Sun.COM (sun-barr.Sun.COM) id AA27893; Fri, 14 Oct 94 11:10:37 PDT Date: Fri, 14 Oct 94 13:50 EDT Message-Id: <9410141413.AA08432@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. Content-Length: 904 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Fri, 14 Oct 94 07:16:38 -0400 (EDT) > From: sob@harvard.edu (Scott Bradner) > > > Suppose ARP was redefined to allow appending the contents of the packet? > > there are MTU related problems with this. when this happens the 1st > packet is larger then the rest of the packets in a stream but only > if there is no cached MAC address info. it seems to add confusion > for little gain. I thought about that before posting. But, almost always, first packets are enough smaller than the MTU that there's no problem. And the packet's not going anywhere else, so if it makes it on this wire, it's at the destination, unfragmented. If a router is proxy arp'ing, the router is going to strip the arp prefix and just forward the packet. The gain is the arp latency, and saving the extra (also multicast) packet of Bill's draft, and the broadcast of today's arp. Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 11:22:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06511; Fri, 14 Oct 94 11:22:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06505; Fri, 14 Oct 94 11:22:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25975; Fri, 14 Oct 94 11:18:35 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA28728; Fri, 14 Oct 94 11:16:09 PDT Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA15178; Fri, 14 Oct 1994 14:15:53 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA27299; Fri, 14 Oct 1994 14:16:25 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA07355; Fri, 14 Oct 1994 13:52:26 -0400 Message-Id: <9410141752.AA07355@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Fri, 14 Oct 94 06:55:47 PDT." <199410141355.AA09102@remmel.NSD.3Com.COM> Date: Fri, 14 Oct 94 13:52:26 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Walt is absolutely correct -- we must have some mechanism to partition > the network and provide abstraction. However, the current model of Agreed. And this model SHOULD allow for logical partitioning on the same wire. IPv6 does allow you to have logical partitions on a link. > Consider what happens right now if I have Host A, Host B and Router C > on the same subnet where A and B are not in the same subnet. To > exchange packets, you either have to do warped configuration (tell A > that it can route directly to B and vice versa) OR the two hosts talk > via the router, with everything taking two hops on the LAN. This is a > clear case where the inflexibility in the model results in a horrible > result. Sometimes the "horrible result" is exactly what is wanted/needed. While I agree that in many, perhaps most, situations, it is desirable to eliminate the extra hop, there are a number of applications where enforcing the extra hop through a router for hosts with different subnet addresses is highly desirable. Testing new addressing plans, logically prototyping new physical topologies, trial deployment of new services, ... Most of these uses are of a temporary nature, but the feature should be available. IPv6 must not eliminate the ability to provide logical separation, and in fact, it should be possible to configure a host to enforce the logical separation. Tracy IPv6 does both, i.e. it allows you to force hosts from two different subnets (partitions) to communicate through a router - "forcing" is done by means of configuration and discovery - and it allows you to make hosts members of many subnets on the same link (logical partitions) by allowing a host have multiple IPv6 addresses on the same link - also through means of configuration and discovery. This has been re-discussed and re-agreed recently at the Implementors meeting. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 11:37:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06531; Fri, 14 Oct 94 11:37:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06525; Fri, 14 Oct 94 11:37:23 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27349; Fri, 14 Oct 94 11:33:40 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA01374; Fri, 14 Oct 94 11:31:23 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA29951; Fri, 14 Oct 94 14:01:12 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410141801.AA29951@pluto.dss.com> Subject: Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 14 Oct 1994 14:01:10 -0400 (EDT) Cc: martillo@pluto.dss.com In-Reply-To: <9410141540.AA28784@pluto.dss.com> from "Joachim Martillo" at Oct 14, 94 11:40:10 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 595 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Just one note. A fully powered Ethernet packet-switch acting as an > Ethernet router should be able to handle 5000 arp transactions per > second. Per interface needs to be added to this sentence. Sorry. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 11:38:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06543; Fri, 14 Oct 94 11:38:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06537; Fri, 14 Oct 94 11:38:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27552; Fri, 14 Oct 94 11:35:07 PDT Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by Sun.COM (sun-barr.Sun.COM) id AA01500; Fri, 14 Oct 94 11:31:45 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA03884; Fri, 14 Oct 94 09:54:01 -0700 Received: by xirtlu.zk3.dec.com; id AA00329; Fri, 14 Oct 1994 12:53:52 -0400 Message-Id: <9410141653.AA00329@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: IPv6 Subnets : Re: (IPng) Re: ARP In-Reply-To: Your message of "Fri, 14 Oct 94 09:12:32 PDT." <199410141612.JAA13360@feta.cisco.com> Date: Fri, 14 Oct 94 12:53:45 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, >> This discussion can stop very quickly if in the address spec and then >> pointed to in the IPv6 spec there is wording such as the statemets >> below: >> --------------------------------- >> If two nodes are on the same link but using different prefix subnets >> within their global IPv6 address want to communicate they MUST do so >> through a router. --------------------------------- >I would amend this slightly (or be creative in my interpretation) to >say that a router may choose to redirect the hosts to communicate >directly (assuming the new-model redirects containing media information) >and it should work Just Fine. (Another reason why I'm resistant to >hosts being overly subnet-knowledgable). But when you say "redirect the host to communicate directly" is where the issue is. Right now that is not technically specified or discussed amongst the host implementors how exactly this can be accomplished. My point was that hosts can NEVER communicate directly in this situation and MUST use a router. If we want the hosts to do this then we have to start that technical discussion to verify that it can be done and how. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 11:46:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06585; Fri, 14 Oct 94 11:46:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06576; Fri, 14 Oct 94 11:46:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28380; Fri, 14 Oct 94 11:42:27 PDT Received: from newdev.harvard.edu ([128.103.203.53]) by Sun.COM (sun-barr.Sun.COM) id AA02809; Fri, 14 Oct 94 11:40:07 PDT Received: by newdev.harvard.edu (5.64/Tenon-1.35.01) id AA01911; Fri, 14 Oct 94 14:38:59 -0400 (EDT) Date: Fri, 14 Oct 94 14:38:59 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) Message-Id: <9410141838.AA01911@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Barney, I'd like to get an understanding about how much saving this latency means. As I see it since there will generally be traffic between backbone & local LAN routers this feature will only reduce the latency for the 1st packet in a stream on its last hop and then only if there is no cached arp entry. how important is this? how much is it worth adding in complexity in order to reduce this latency? Scott ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06830; Fri, 14 Oct 94 14:40:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06824; Fri, 14 Oct 94 14:40:47 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB14870; Fri, 14 Oct 94 14:37:04 PDT Received: from databus.databus.com ([198.186.154.34]) by Sun.COM (sun-barr.Sun.COM) id AA07485; Fri, 14 Oct 94 14:36:21 PDT Date: Fri, 14 Oct 94 17:36 EDT Message-Id: <9410141736.AA08973@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Fri, 14 Oct 94 14:38:59 -0400 (EDT) > From: sob@harvard.edu (Scott Bradner) > > Barney, > I'd like to get an understanding about how much saving this > latency means. > > As I see it since there will generally be traffic between > backbone & local LAN routers this feature will only reduce the latency > for the 1st packet in a stream on its last hop and then only if > there is no cached arp entry. > > how important is this? how much is it worth adding in > complexity in order to reduce this latency? Right now, the sending host on the last hop buffers the IP packet until it gets the ARP response, right? That's painful even when the response time is short. My understanding of Bill's draft is that, in his scheme, the sender can send that packet right away, and not have to save a copy. The sender then sends, as a second packet, a General Solicitation. The receiver responds with IP address --> data-link address to the GS, not to the first packet. I'm suggesting that there's nothing in the GS that makes it worthwhile sending as a separate packet. If that first packet were sent as a link-layer multicast, with an "ARPng" ethertype (or equiv), the proper receiver would know to both process the packet and respond to it with its data-link address (and the other stuff Bill proposes). Other receivers would get the multicast (but only 1/n of them, as the IPv6 address was hashed to get the link multicast group), but would not be confused into forwarding it, because it didn't have the IP ethertype, but went to the ARPng receive code instead. Done this way, there would be no MTU issue, because there would be no extra bytes in the ARPng packet, and ARPng code would never *have* to buffer a packet. It would, as it does today, either throw away subsequent packets given to it to transmit, if it had not yet heard from the receiver & the timeout had not yet expired, or buffer them, or buffer the latest, or (rather impolitely, and only if it's multicast, not broadcast) just send them. The whole ARP mechanism of query/response, buffering and retries seems motivated by the need/desire to send a destination unreachable, and not to send it as a false alarm. But it seems to me these days that senders are quite sceptical about host/network unreachables anyway. I think that, on the whole, ARP complexity is reduced, not increased. A simpleminded ARPng implementation could choose never to buffer. That loses only when the packet gets hit on the wire (which had better be rare, and can happen to any other packet without justifying a last-hop retry) or when the destination is slow to respond and another packet comes in before the response. The latter is likely only when the destination is a mobile which is newly on the link, and in that case I believe the destination should have sent an "I'm here" before it expects any packets. Surely a good mobility protocol would not have a host say "I'm moving" and then allow a race condition between when the host gets to the new place and its partners send to it? In this case the last-hop sender is almost certainly a router, and a router's ARPng implementation need not be simpleminded. For the 6000-bridged-host case, this uses multicast rather than broadcast, cuts the number of multicast packets from the two of Bill's draft to one, and because ARPng does not retry, *may* be less prone to storms. I'm not sure that multicast actually helps this case, because unless the hashing algorithm is supernatural the multicast has to be sent on every segment anyway - unless the hash is allowed enough bits that the probability of a segment having a member of the group on it, other than the real destination, is fairly low. That would imply that the hash should be allowed about 16 bits, which still doesn't take up a noticeable fraction of the multicast link-layer address space. Putting the actual data of the first packet in a multicast link-layer frame has some implications for secure hubs which overwrite data on unicast packets not to the MAC address of the segment - but that's true of the draft as well. For the typical case of wanting to preclude sniffing of userid/passwords on a TCP connection, this is not a problem, as they're not in the first packet. Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06842; Fri, 14 Oct 94 14:42:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06836; Fri, 14 Oct 94 14:42:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15006; Fri, 14 Oct 94 14:38:22 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA07772; Fri, 14 Oct 94 14:37:54 PDT Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA25096; Fri, 14 Oct 1994 17:36:57 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA08146; Fri, 14 Oct 1994 17:37:17 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA07922; Fri, 14 Oct 1994 17:13:31 -0400 Message-Id: <9410142113.AA07922@brigit.zk3.dec.com> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Thu, 13 Oct 94 16:41:28 PDT." <199410132341.QAA16961@lager.cisco.com> Date: Fri, 14 Oct 94 17:13:31 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 1. - Hosts don't need to know which partition they're in. 2. - Hosts don't need to know which partition the destination is in. 3. - Hosts can be in multiple partitions simultaneously. 4. - Partitions can overlap, and not necessarily nest. 5. - Partitions can be discontigous. I - disagree strongly with - 1., and 2., To qualify, a host should know whether the destination is in the same partition or not. Why? A host should clearly learn whether or not it's on the same media or not. There are several methods to implement "learn whether or not it's on the same media". 1. Use the intervention of a third party even when the traffic is between two hosts on the same media (link). 2. Use the resources of the participant hosts to determine whether their traffic is on the same media (link). For cost effectivness, many prefer the second method. Why does it matter if I'm in the same partition or some other partition? It's just a namespace and I should _not_ have to know the organization of that namespace. The cost effective method implies that a subnet (partition) does not span a link, and therefore two hosts on the same subnet are on the same link. To determine that a destination host is on the same link means to determine whether it is on the same subnet. For a host to make that determination is trivially simple, with no additional hardware, and a minimum amount of code, and storage - in fact the support of multihoming requires the presence of that code anyways. Well, then you condemn partitioned (sigh terminology overlap) media to instant failure. We already know how to deal with area partitioning in ISIS. One would hope that in the next 20 years we might do SOMETHING better about partition repair for individual subnets. First there are many other reasons to keep the size of a link under control, which reduces the probabililty of partitioned links. Second, with multiple routers and subnets on a link, the partitioning of that link can be resolved using the IPv6 discovery, if each of the partitions has at least one router. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 14 17:47:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07010; Fri, 14 Oct 94 17:47:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07004; Fri, 14 Oct 94 17:47:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01447; Fri, 14 Oct 94 17:43:18 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA11935; Fri, 14 Oct 94 17:42:56 PDT Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA03840; Fri, 14 Oct 1994 20:42:54 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA12438; Fri, 14 Oct 1994 20:43:02 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA08122; Fri, 14 Oct 1994 20:19:19 -0400 Message-Id: <9410150019.AA08122@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: :conta@zk3.dec.com, sob@harvard.edu, barney@databus.com Subject: Re: (IPng) Re: ARP, etc. In-Reply-To: Your message of "Fri, 14 Oct 94 17:36:00 EDT." <9410141736.AA08973@databus.databus.com> Date: Fri, 14 Oct 94 20:19:19 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Fri, 14 Oct 94 14:38:59 -0400 (EDT) > From: sob@harvard.edu (Scott Bradner) > > Barney, > I'd like to get an understanding about how much saving this > latency means. > > As I see it since there will generally be traffic between > backbone & local LAN routers this feature will only reduce the latency > for the 1st packet in a stream on its last hop and then only if > there is no cached arp entry. > > how important is this? how much is it worth adding in > complexity in order to reduce this latency? Right now, the sending host on the last hop buffers the IP packet until it gets the ARP response, right? That's painful even when the response time is short. I read Scott's question as is the pain worth? I an not convinced it is. My understanding of Bill's draft is that, in his scheme, the ... were sent as a link-layer multicast, with an "ARPng" ethertype (or equiv), the proper receiver would know to both process the packet and respond to it with its data-link address (and the other stuff Bill proposes). Do you mean to use ARPng protocol type for all "NEW ARP" transactions or only for REQUESTs? If only for REQUESTs, you would use ARPng only for sending a "transparent" solicitation, i.e. the ARPng REQUEST, is in fact a NO HEADER packet. Then you would use another ethertype for the REPLY. I have several issues: - you use two link protocols, one for REQUEST, another for REPLY. The cost of processing any additional link protocol in the link layer driver is not negligible - the link driver must look through an additional set of link multicast addresses, which are enabled on a per protocol basis, must look through a longer list of protocols, and uses additional memory to create structures for the additional protocol type. For the benefit you get, it is questionable if it is worth. - during the IPv4 to IPv6 transition, a host would need to support the old ARP ethertype. This means that your host needs 3 ethertypes for address IPv4 and IPv6 related address resolution. - you do not specify the link type, and use the link address from link layer, which MAY create a problem when the packet crosses a multi-link bridge (hub). - the source of information for partially filling up the ARPng cache INCOMPLETE entry, is the IPv6 header, while for the COMPLETE entry is the ARPng REPLY - this adds to code implementation and maintenance cost. - you use the link header as source of information for the destination of the reply. This prohibits the implementation of an quasi-important ARP function which is ARP servers, which can answer ARP requests on behalph of other hosts. Other receivers would get the multicast (but only 1/n of them, as the IPv6 address was hashed to get the link multicast group), but would not be confused into forwarding it, because it didn't have the IP ethertype, but went to the ARPng receive code instead. Which presumably checks the IPv6 destination address against the hosts IPv6 addresses, before passing the packet to the real IPv6 protocol engine. If you didn't then you MIGHT just create the same problem as Bill's. So you do IPv6 header pre-processing, before getting into the IPv6 layer protocol engine. Do you like it? Is it worth? Done this way, there would be no MTU issue, because there would be no extra bytes in the ARPng packet, and ARPng code would never *have* to buffer a packet. It would, as it does today, either throw away subsequent packets given to it to transmit, if it had not yet heard from the receiver & the timeout had not yet expired, or buffer them, or buffer the latest, or (rather impolitely, and only if it's multicast, not broadcast) just send them. You mentioned the first two - drop or enqueue - as a negative side in ARP, if I remember well, so considering the third, we would have more multicasts than we would otherwise, right? The whole ARP mechanism of query/response, buffering and retries seems motivated by the need/desire to send a destination unreachable, and not to send it as a false alarm. But it seems to me these days that senders are quite sceptical about host/network unreachables anyway. The role of the buffering is most importantly to not lose packets, that otherwise have to be retransmitted by a transport or application. The host unreachable is in many implementations shunt-ed. I think that, on the whole, ARP complexity is reduced, not increased. With bare functionality, and ignoring the "issues" mentioned above, I am not convinced that the complexity is reduced. Your host still must do REQUEST/REPLY. The fact that you do not have an ARP header, you still have to manipulate the relevant information for the REQUEST as before, plus make all sort of assumptions. .... I'm not sure that multicast actually helps this case, because unless the hashing algorithm is supernatural the multicast has to be sent on every segment anyway - unless the hash is allowed enough bits that the probability of a segment having a member of the group on it, other than the real destination, is fairly low. That would imply that the hash should be allowed about 16 bits, which still doesn't take up a noticeable fraction of the multicast link-layer address space. I agree. It is not worth to try hashing at all. .... Barney Wolff Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 15 00:01:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07140; Sat, 15 Oct 94 00:01:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07134; Sat, 15 Oct 94 00:01:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13149; Fri, 14 Oct 94 23:57:31 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AB08794; Fri, 14 Oct 94 23:57:11 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA08396; Fri, 14 Oct 1994 23:53:14 -0700 Date: Fri, 14 Oct 1994 23:53:14 -0700 From: Tony Li Message-Id: <199410150653.XAA08396@lager.cisco.com> To: conta@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com In-Reply-To: conta@zk3.dec.com's message of Fri, 14 Oct 94 17:13:31 -0400 <9410142113.AA07922@brigit.zk3.dec.com> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 2. Use the resources of the participant hosts to determine whether their traffic is on the same media (link). For cost effectivness, many prefer the second method. The cost effective method implies that a subnet (partition) does not span a link, and therefore two hosts on the same subnet are on the same link. I don't follow that at all. That begs the question of what the efficient mechanism is and assumes that you are using mask and match to determine what's on the media. Certainly two hosts from different partitions on the same media should be able to determine that they're only one hop apart. To determine that a destination host is on the same link means to determine whether it is on the same subnet. For a host to make that determination is trivially simple, with no additional hardware, and a minimum amount of code, and storage - in fact the support of multihoming requires the presence of that code anyways. Only if you presume that there's only one subnet per link, which is clearly not reasonable -- it represents loss of features as compared with IPv4. Well, then you condemn partitioned (sigh terminology overlap) media to instant failure. We already know how to deal with area partitioning in ISIS. One would hope that in the next 20 years we might do SOMETHING better about partition repair for individual subnets. First there are many other reasons to keep the size of a link under control, which reduces the probabililty of partitioned links. Second, with multiple routers and subnets on a link, the partitioning of that link can be resolved using the IPv6 discovery, if each of the partitions has at least one router. But this breaks the model that you just established: that a subnet is only on one link. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 15 02:26:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07164; Sat, 15 Oct 94 02:26:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07158; Sat, 15 Oct 94 02:26:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15032; Sat, 15 Oct 94 02:22:23 PDT Received: from databus.databus.com ([198.186.154.34]) by Sun.COM (sun-barr.Sun.COM) id AA17578; Sat, 15 Oct 94 02:22:00 PDT Date: Sat, 15 Oct 94 05:21 EDT Message-Id: <9410150522.AA10300@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Cc: :conta@zk3.dec.com, sob@harvard.edu, barney@databus.com Subject: Re: (IPng) Re: ARP, etc. Content-Length: 10112 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Fri, 14 Oct 94 20:19:19 -0400 > From: conta@zk3.dec.com > > Right now, the sending host on the last hop buffers the IP packet until it > gets the ARP response, right? That's painful even when the response time > is short. > > I read Scott's question as is the pain worth? I an not convinced it is. We have a strongly felt complaint that ARP as we know it is in need of improvement. I can't put management of multi-thousand IP host networks on my resume, so I won't enter into that debate. I will say that the link-level-retry model of ARP is unique in the IP universe - everywhere else, we boast of end-to-end-ness. The only real excuse is that we don't want always to throw the first packet away, not that address resolution particularly needs local retries. > My understanding of Bill's draft is that, in his scheme, the > ... > were sent as a link-layer multicast, with an "ARPng" ethertype (or equiv), > the proper receiver would know to both process the packet and respond to > it with its data-link address (and the other stuff Bill proposes). > > Do you mean to use ARPng protocol type for all "NEW ARP" transactions or > only for REQUESTs? > > If only for REQUESTs, you would use ARPng only for sending a "transparent" > solicitation, i.e. the ARPng REQUEST, is in fact a NO HEADER packet. Then > you would use another ethertype for the REPLY. The only packet which needs the ARPng ethertype is the implicit request. The reply can be sent as ICMP, UDP or ARP. > I have several issues: > > - you use two link protocols, one for REQUEST, another for REPLY. The cost > of processing any additional link protocol in the link layer driver is not > negligible - the link driver must look through an additional set of > link multicast addresses, which are enabled on a per protocol basis, must look > through a longer list of protocols, and uses additional memory to create > structures for the additional protocol type. > For the benefit you get, it is questionable if it is worth. The only multicast is now ARPng, so there's only one multicast group for discovery in any scheme. (There's an obvious tradeoff here, in that everybody supports link-level broadcast, and multicast is "more work" - but my scheme works with broadcast too, so that's a separate question.) IPv6 lightswitches don't need to support IPv4, or ARP. Most everybody else already supports a number of ethertypes, and even an IP-only host supports both IP and ARP. After transition, the number of ethertypes goes back to 2. A really lightweight implementation does not trouble itself with table-driven elegance but just does a case ARPng: I would suggest overloading the ARP ethertype with ARPng, as the start of an IPv6 (or IPv4) packet cannot be mistaken for any defined ARP hardware type, but I'm sure many folks would fear that it would break existing flaky ARP implementations. > - during the IPv4 to IPv6 transition, a host would need to support the old > ARP ethertype. This means that your host needs 3 ethertypes for address IPv4 > and IPv6 related address resolution. Yes, but in the context of all the other changes going on I claim this is trivial. > - you do not specify the link type, and use the link address from link > layer, which MAY create a problem when the packet crosses a multi-link bridge > (hub). I don't understand the question, so let me try to answer what I think you might be asking. If there exist bridges which overwrite the source link-layer address with their own when forwarding, this scheme clearly just does not work, so it's not "MAY". Otherwise, surely the bridge must remember what port the packet came from, as it can't forward it back on that port without grave risk of a storm, so the link type is known. If the bridge is translating link layer addresses to a different hardware type, the new source address is indeed the one I should use to return packets to the sender. (I assume here that it translates both source and dest.) Such a translating bridge is going to have loads of fun with the new discovery protocols, I'm sure. > - the source of information for partially filling up the ARPng cache > INCOMPLETE entry, is the IPv6 header, while for the COMPLETE entry is the > ARPng REPLY - this adds to code implementation and maintenance cost. But it was the desire to transmit the IPv6 packet which caused the incomplete entry to be generated. Both that entry and the ARP request are today generated from the IP packet, yes? If you're talking about the incoming multicast first packet, the target sets up the complete cache entry for the source from it. > - you use the link header as source of information for the destination of >the reply. This prohibits the implementation of an quasi-important ARP function > which is ARP servers, which can answer ARP requests on behalph of other hosts. Proxy ARP works fine - the destination of the reply is the source link-layer address of the incoming packet and whether the replier is the proxy ARP'er or the real target makes no difference. If you mean an ARP server which is not a forwarder, let's ask why it's there. If the real target cannot receive either multicast or broadcast, but only unicast, there is a solution with some pain. The ARP server replies to the original sender, replies also to the target, as though the target had sent a request for the sender's address, and then forwards the packet to the target. Yes this is a kludge, but is this a real case? How is this host which can't deal with broadcast getting its address resolution services today? Is it configured to send unicast requests to a particular ARP server? How elegant. > Other > receivers would get the multicast (but only 1/n of them, as the IPv6 > address was hashed to get the link multicast group), but would not be > confused into forwarding it, because it didn't have the IP ethertype, > but went to the ARPng receive code instead. > > Which presumably checks the IPv6 destination address against the hosts IPv6 > addresses, before passing the packet to the real IPv6 protocol engine. > If you didn't then you MIGHT just create the same problem as > Bill's. So you do IPv6 header pre-processing, before getting into the > IPv6 layer protocol engine. Do you like it? Is it worth? Isn't this what any ARP implementation does today, to see if the packet's for it? After checking version, can't I just check the dest IPv6 address against my own set? Some option or other may mean that the address matches but the packet's not really for me? I hope not. > Done this way, there would be no MTU issue, because there would be no > extra bytes in the ARPng packet, and ARPng code would never *have* to > buffer a packet. It would, as it does today, either throw away subsequent > packets given to it to transmit, if it had not yet heard from the > receiver & the timeout had not yet expired, or buffer them, or buffer > the latest, or (rather impolitely, and only if it's multicast, not > broadcast) just send them. > > You mentioned the first two - drop or enqueue - as a negative side in ARP, > if I remember well, so considering the third, we would have more multicasts > than we would otherwise, right? I would not send another multicast before the timeout had expired, myself. In the normal case, I don't expect that another packet will arrive before the timeout - do you? (Brian, what's a reasonable ARP timeout in your 6000-host bridged net?) > The whole ARP mechanism of query/response, buffering and retries seems > motivated by the need/desire to send a destination unreachable, and not > to send it as a false alarm. But it seems to me these days that senders > are quite sceptical about host/network unreachables anyway. > > The role of the buffering is most importantly to not lose packets, that > otherwise have to be retransmitted by a transport or application. The host > unreachable is in many implementations shunt-ed. Where did these packets come from, all of a sudden? Under what circumstances does communication with a new host start with a burst? > I think that, on the whole, ARP complexity is reduced, not increased. > > With bare functionality, and ignoring the "issues" mentioned above, > I am not convinced that the complexity is reduced. Your host still must > do REQUEST/REPLY. The fact that you do not have an ARP header, you still > have to manipulate the relevant information for the REQUEST as before, plus > make all sort of assumptions. > > .... I'm not sure that multicast actually helps this case, because > unless the hashing algorithm is supernatural the multicast has to be > sent on every segment anyway - unless the hash is allowed enough bits > that the probability of a segment having a member of the group on it, > other than the real destination, is fairly low. That would imply that > the hash should be allowed about 16 bits, which still doesn't take up > a noticeable fraction of the multicast link-layer address space. > > I agree. It is not worth to try hashing at all. But multicast does help when a network has a lot of hosts on a wire, and the adapter hardware handles the filtering (which may be never, I suppose). If multicast is going to grow, better hardware support will come. This effort was a reaction to Bill's draft, which proposes multicast, and Alex's concerns about unicast-IP / multicast-link-layer, and a bunch of people saying classic ARP needs replacing. I must admit to liking the notion of sending the first packet rather than buffering it, a lot. There are clearly tradeoffs among using the sender's link-layer address from the link-layer, cutting into MTU by including it (as an option) in the packet, and sending the address resolution/discovery/solicitation as a separate packet. Since the sender's link layer address and address type are the only things in an ARP request that aren't in the IPv6 header already, the added space would be small, and only used when avoiding an extra packet. Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 15 18:58:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07249; Sat, 15 Oct 94 18:58:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07243; Sat, 15 Oct 94 18:58:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25644; Sat, 15 Oct 94 18:54:16 PDT Received: from pluto.dss.com ([192.41.217.2]) by Sun.COM (sun-barr.Sun.COM) id AA19958; Sat, 15 Oct 94 18:53:54 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA29433; Sat, 15 Oct 94 21:49:47 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410160149.AA29433@pluto.dss.com> Subject: Re: (IPng) Re: ARP, etc. To: ipng@sunroof.Eng.Sun.COM Date: Sat, 15 Oct 1994 21:49:46 -0400 (EDT) Cc: :conta@zk3.dec.com, sob@harvard.edu, barney@databus.com In-Reply-To: <9410150522.AA10300@databus.databus.com> from "Barney Wolff" at Oct 15, 94 05:21:00 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2003 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Date: Fri, 14 Oct 94 20:19:19 -0400 > > From: conta@zk3.dec.com > > Right now, the sending host on the last hop buffers the IP packet until it > > gets the ARP response, right? That's painful even when the response time > > is short. > > I read Scott's question as is the pain worth? I an not convinced it is. > We have a strongly felt complaint that ARP as we know it is in need of > improvement. I can't put management of multi-thousand IP host networks > on my resume, so I won't enter into that debate. I will say that the > link-level-retry model of ARP is unique in the IP universe - everywhere > else, we boast of end-to-end-ness. ARP is different from entities in the IP universe because ARP is not part of the IP universe. The fundamental principle of the DARPA internetworking model is the following. Computer networking takes place in homogeneous unitary virtual network wherein details of the underlying physical catenet is concealed from entities communicating within the virtual network. When the communicating entity delivers data to the virtual network, it passes the IP packet to a driver for one of interfaces associated with a less abstracted or less virtualized lower-layer network in the catenet. This driver must somehow convert the virtual network packet into a frame appropriate for the less abstractnetwork (assuming this lower layer network is frame oriented -- it need not be). Classic ARP was specified for some frame oriented lower layer networks. End-to-end-ness in the virtual network sense is irrelevant to the function and the functioning of Classic ARP. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 16 03:46:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07370; Sun, 16 Oct 94 03:46:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07364; Sun, 16 Oct 94 03:46:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00565; Sun, 16 Oct 94 03:42:28 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA10976; Sun, 16 Oct 94 03:42:07 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28712; Sun, 16 Oct 1994 11:42:03 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29790; Sun, 16 Oct 1994 11:42:02 +0100 Message-Id: <9410161042.AA29790@dxcoms.cern.ch> Subject: Re: IPv6 Subnets : Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Sun, 16 Oct 1994 11:42:01 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410141653.AA00329@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Oct 14, 94 12:53:45 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2245 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, The reason I asked the question about ATM is that exactly this piece of philosophy came up there a year ago. If there is a large ATM network -i.e. a single Level 2 address space where anybody can have a virtual channel to anybody- and the objects connected are both hosts and routers, the notions of wire and subnet become very fuzzy. Any host can talk to to any host or any router by a direct virtual channel. You cannot reasonably insist that traffic always goes through routers when direct channels exist. The NHRP work in rolc is directed towards resolving this fuzz. We need crosstalk between that and IPv6. At the boundary routers the fuzziness disappears and the classical Internet model works. Brian >--------- Text sent by bound@zk3.dec.com follows: > > Dave, > > > >> This discussion can stop very quickly if in the address spec and then > >> pointed to in the IPv6 spec there is wording such as the statemets > >> below: > > >> --------------------------------- > >> If two nodes are on the same link but using different prefix subnets > >> within their global IPv6 address want to communicate they MUST do so > >> through a router. > --------------------------------- > > >I would amend this slightly (or be creative in my interpretation) to > >say that a router may choose to redirect the hosts to communicate > >directly (assuming the new-model redirects containing media information) > >and it should work Just Fine. (Another reason why I'm resistant to > >hosts being overly subnet-knowledgable). > > But when you say "redirect the host to communicate directly" is where > the issue is. Right now that is not technically specified or discussed > amongst the host implementors how exactly this can be accomplished. > > My point was that hosts can NEVER communicate directly in this situation > and MUST use a router. If we want the hosts to do this then we have to > start that technical discussion to verify that it can be done and how. > > /jim > ------------------------------------------------------------------------------ > IETF IPng Mailing List > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 16 14:39:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07473; Sun, 16 Oct 94 14:39:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07467; Sun, 16 Oct 94 14:39:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06717; Sun, 16 Oct 94 14:36:03 PDT Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by Sun.COM (sun-barr.Sun.COM) id AA28154; Sun, 16 Oct 94 14:35:43 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA29762; Sun, 16 Oct 94 14:30:55 -0700 Received: by xirtlu.zk3.dec.com; id AA05707; Sun, 16 Oct 1994 17:30:53 -0400 Message-Id: <9410162130.AA05707@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Anycast In-Reply-To: Your message of "Fri, 14 Oct 94 09:53:40 PDT." <199410141653.JAA09059@aland.bbn.com> Date: Sun, 16 Oct 94 17:30:47 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Thanks. I suggest we take anycast off line unless folks start applying the concept to IPv6. Mabye we need a discussion just on this topic elsewhere (I don't think its e-2-e either and definitely not Big-I)? Doing protoypes for this would not be real hard and tests could be done quickly at least with hosts for now. We can probably do some prototyping to OSPF on Host Routers for the work too. From your mail I think the "principles" behind this technology are critical to agree upon first. Or we can work on the priniciples and then test them with an IPV6 code base for prototype if we can perform functions that are not part of IPv4. Anyway thanks, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 16 15:58:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07491; Sun, 16 Oct 94 15:58:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07485; Sun, 16 Oct 94 15:57:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08214; Sun, 16 Oct 94 15:54:05 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA01644; Sun, 16 Oct 94 15:53:37 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA16013; Mon, 17 Oct 1994 08:52:22 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA05067; Mon, 17 Oct 94 08:40:09 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT05042; Mon, 17 Oct 1994 08:40:07 EST Date: 14 Oct 94 11:38:12 +1100 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) FLOW LABELS Ua-Content-Id: 941014 11:27:14 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941014 11:27:14 009 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941014113812+1100 deferred 941014113812+1100 action Relayed Message-Id: <"941014 11:27:14"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, some time ago I made comments on SIP re the flow label.. I perceived that such a concept did not work because it relied on a router having explicit knowledge of the users requirements and that every router on the path must process the packet consistenly... With respect to all the other users.. using those routers.. It also relied on latency.. where each users flowid would be relative to other packets from that user (with different flow ids) I proposed that flow/QOS should be defined universally and applied in the local context-- like IP4 TOS.. Did I get this wrong .. Is there any docs of flowlabels Thanks and Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 01:05:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07625; Mon, 17 Oct 94 01:05:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07619; Mon, 17 Oct 94 01:05:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19790; Mon, 17 Oct 94 01:01:24 PDT Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by Sun.COM (sun-barr.Sun.COM) id AB07611; Mon, 17 Oct 94 01:01:02 PDT Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Oct 1994 09:00:55 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) FLOW LABELS In-Reply-To: Your message of "14 Oct 94 11:38:12 +1000." <"941014 11:27:14"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Mon, 17 Oct 94 09:00:53 +0100 Message-Id: <634.782380853@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >some time ago I made comments on SIP re the flow label.. >I perceived that such a concept did not work because it relied on a router >having explicit knowledge of the users requirements and that every router on >the path must process the packet consistenly... With respect to all the other >users.. using those routers.. no - you only have to have knowledge of a flow in routers that are on paths where FIFO would cause other traffic to cause a flow to not meet a particular spec. this turns out to be often not many... some of the UK internet providers over provision their backbones so they can _always meet bandwidth demands! the remaining problem is latency - you can always meet that provided the trasit delay isnt too high, and the queues are always around 1 (i.e. you have enough bandwidth) and you sort the packets by source ratehr than FIFO... but there are many scheudling algorithms that are easy to implement, efficient and serve the problem... >I proposed that flow/QOS should be defined universally and applied in the >local context-- like IP4 TOS.. the idea is that its an index or a key to previously established state based on externally (out of band) specified QoS (established thru a setup protocol such as RSVP) - it can conveniently be used for route+queue lookup... >Did I get this wrong .. Is there any docs of flowlabels check out working documents in the internet draft directories for the integrated services WG and the RSVP one (and maybe the AVT one too...) there's lots of stuff on this... see rfc 1633 as a baseline cheers jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 07:59:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07848; Mon, 17 Oct 94 07:59:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07842; Mon, 17 Oct 94 07:59:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03882; Mon, 17 Oct 94 07:56:05 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA14252; Mon, 17 Oct 94 07:55:44 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA10931; Mon, 17 Oct 1994 10:55:36 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA09042; Mon, 17 Oct 1994 10:55:34 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA08743; Mon, 17 Oct 1994 10:32:10 -0400 Message-Id: <9410171432.AA08743@brigit.zk3.dec.com> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Fri, 14 Oct 94 23:53:14 PDT." <199410150653.XAA08396@lager.cisco.com> Date: Mon, 17 Oct 94 10:32:10 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 1.Use the intervention of a third party even when the traffic is between two hosts on the same media (link). 2. Use the resources of the participant hosts to determine whether their traffic is on the same media (link). For cost effectivness, many prefer the second method. The cost effective method implies that a subnet (partition) does not span a link, and therefore two hosts on the same subnet are on the same link. I don't follow that at all. That begs the question of what the efficient mechanism is... If you read 1. and 2., the difference is that 1. requires a third party, besides the two communicating hosts, while 2. requires only the two communicating hosts. (I added 1. from my mail, which you omitted in your response) ... determination is trivially simple, with no additional hardware, and a minimum amount of code, and storage - in fact the support of multihoming requires the presence of that code anyways. Only if you presume that there's only one subnet per link, which is clearly not reasonable -- it represents loss of features as compared with IPv4. Why do you make that presumption? You can have multiple subnets per link, and multiple IPv6 addresses per interface (link adapter). ... First there are many other reasons to keep the size of a link under control, which reduces the probabililty of partitioned links. Second, with multiple routers and subnets on a link, the partitioning of that link can be resolved using the IPv6 discovery, if each of the partitions has at least one router. But this breaks the model that you just established: that a subnet is only on one link. Please read carefully what I wrote. I didn't establish or use that model. You presumed it, and it's not clear why. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 08:03:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07860; Mon, 17 Oct 94 08:03:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07854; Mon, 17 Oct 94 08:02:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04079; Mon, 17 Oct 94 07:59:11 PDT Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA14415; Mon, 17 Oct 94 07:57:11 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 17 Oct 94 23:47:54 +0859 From: Masataka Ohta Message-Id: <9410171448.AA04028@necom830.cc.titech.ac.jp> Subject: Re: IPv6 Subnets : Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Mon, 17 Oct 94 23:47:53 JST In-Reply-To: <9410141651.AA01617@newdev.harvard.edu>; from "Scott Bradner" at Oct 14, 94 12:51 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If two nodes are on the same link but using different prefix subnets > within their global IPv6 address want to communicate they MUST do so > through a router. > > > I see no reason to constrain the user to this 'classical' model > of the way that networks work and see many reasons not to Aren't you confusing two cases. One case is to support a SIGNLE subnet on a single link having MULTIPLE address prefixes. The other case is to support MULTIPLE subnets sharing a link layer having different addresses. There may be reasons to support the former, for example for multi-homing, but not for the latter. For the latter case, in ATM WG ML, it is recently pointed out that it is impossible to have a well known link layer address for IP subnet broadcast, which makes autoconfiguration impossible (note that, with LIS and NHRP model, a link layer is so large that link layer broadcast is practically impossible. You can't use it for LIS broadcast). So, there is a reason to have routers to make link layers reasonablly small. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 09:06:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07934; Mon, 17 Oct 94 09:06:02 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07928; Mon, 17 Oct 94 09:05:50 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA19516; Mon, 17 Oct 1994 08:59:40 -0700 Date: Mon, 17 Oct 1994 08:59:40 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410171559.IAA19516@jurassic.Eng.Sun.COM> To: J.Houldsworth@ste0906.wins.icl.co.uk Cc: ipng@sunroof.Eng.Sun.COM, BESBRODS , cassidy , colin.amor@intelsat.int, hvb@arch4.att.com, rpbrandt@attmail.com, alan@archway.demon.co.uk, lyman@BBN.com, danthine@vm1.ulg.ac.be, frommi@zfe.siemens.de, pag@mci.org.uk, JEAN-FRANCOIS.GORNET@PRINCE.atlas1.edf.fr, josef.haas@fh-aalen.de, jnk@cclab.cau.ac.kr, kino@nttmhs.ntt.jp, " (Keith G Knightson)" , lee@ntd.comsat.com, sleistner@attmail.com, bobl@tmx.mhs.oz.au, arne.litlere@ntra.telemax.no, bcshin@eekaist.kaist.ac.kr, Schulte W , gsmith@werple.apana.org.au, monicas@vnet.ibm.com, magnus@vnet.IBM.COM, bruce-steer@saa.sa.telememo.au, rjthomas@bnr.ca, /G=matti/S=vasara/O=sty/@elisa.fi, jwheel@attmail.com, /G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@pipex.net In-Reply-To: <"3917*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> Subject: (IPng) Hop by Hop extension for full NSAPs - Proposed Text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jack, > >From Jack Houldsworth - SC6 liaison. > > Our preference is for the Lloyd scheme which is repeated > below with some specimen text for the SIPP (IP6) spec. I > hope that the editors can work this into the draft text > before the BOFs in San Jose? You should submit this as an Internet Draft. It will be used as input to the BOF which Brian Carpenter is running at the December IETF meeting. Bob Hinden IPng Document Editor ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 14:18:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08234; Mon, 17 Oct 94 14:18:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08228; Mon, 17 Oct 94 14:18:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24530; Mon, 17 Oct 94 14:14:33 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA25758; Mon, 17 Oct 94 14:13:55 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA26288; Mon, 17 Oct 1994 16:27:46 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA04547; Mon, 17 Oct 1994 16:27:39 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA09104; Mon, 17 Oct 1994 16:04:15 -0400 Message-Id: <9410172004.AA09104@brigit.zk3.dec.com> To: barney@databus.com Cc: ipng@sunroof.Eng.Sun.COM, sob@harvard.edu, conta@zk3.dec.com Subject: Re: (IPng) Re: ARP, etc. In-Reply-To: Your message of "Sat, 15 Oct 94 05:21:00 EDT." <9410150534.AA10334@databus.databus.com> Date: Mon, 17 Oct 94 16:04:15 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ... for discovery in any scheme. (There's an obvious tradeoff here, in that everybody supports link-level broadcast, and multicast is "more work" - but my scheme works with broadcast too, so that's a separate question.) IPv6 lightswitches don't need to support IPv4, or ARP. Most everybody else already supports a number of ethertypes, and even an IP-only host supports both IP and ARP. After transition, the number of ethertypes goes back to 2. A really lightweight implementation does not trouble itself with table-driven elegance but just does a case ARPng: Is this an acceptable solution? > - you use the link header as source of information ... You do not seem to have a problem using a link protocol type without any protocol header. You think that you can use informaton passed in the link layer header, and ignore the need of information that is passed today in the ARP header, but although this may work in a particular case, and with a particular implementation, it does not scale to all links, and to all implementations. The ARP protocol header has an important role besides the role of passing the IP and Media address. It is creating a unified environment in which information typical to each link can be processed in the same way, regardless of differences that exist at link layer level. Think about this a little more. > If you didn't then you MIGHT just create the same problem as > Bill's. So you do IPv6 header pre-processing, before getting into the > IPv6 layer protocol engine. Do you like it? Is it worth? Isn't this what any ARP implementation does today, to see if the packet's for it? After checking version, can't I just check the dest IPv6 address against my own set? Some option or other may mean that the address matches but the packet's not really for me? I hope not. You imply that there is no difference. Are you over simplifying, or just ignoring? Today an ARP implementation is processing ARP header information. Both the ARP processing and ARP header are different than IPv4 processing and IPv4 header. After checking version, can't I just check the dest IPv6 address against my own set? And then do that again in the IPv6 protocol engine? ... in the normal case, I don't expect that another packet will arrive before the timeout - do you? > The role of the buffering is most importantly to not lose packets, that > otherwise have to be retransmitted by a transport or application. The host > unreachable is in many implementations shunt-ed. Where did these packets come from, all of a sudden? Under what circumstances does communication with a new host start with a burst? Is this another case of over simplifying, or just ignoring? But multicast does help when a network has a lot of hosts on a wire, and the adapter hardware handles the filtering (which may be never, I suppose). Using the hashing function helps as desired only if you have an address space usage that is uniformly contiguous. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 15:33:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08280; Mon, 17 Oct 94 15:33:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08274; Mon, 17 Oct 94 15:32:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01868; Mon, 17 Oct 94 15:29:09 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA09425; Mon, 17 Oct 94 15:28:39 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id PAA23620; Mon, 17 Oct 1994 15:24:29 -0700 Date: Mon, 17 Oct 1994 15:24:29 -0700 From: Tony Li Message-Id: <199410172224.PAA23620@lager.cisco.com> To: conta@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com In-Reply-To: conta@zk3.dec.com's message of Mon, 17 Oct 94 10:32:10 -0400 <9410171432.AA08743@brigit.zk3.dec.com> Subject: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 2. Use the resources of the participant hosts to determine whether their traffic is on the same media (link). For cost effectivness, many prefer the second method. The cost effective method implies that a subnet (partition) does not span a link, and therefore two hosts on the same subnet are on the same link. I don't follow that at all. That begs the question of what the efficient mechanism is... If you read 1. and 2., the difference is that 1. requires a third party, besides the two communicating hosts, while 2. requires only the two communicating hosts. We're arguing in circles here. There is NO requirement for a third party. There is currently NO mechanism for using the resources of ONLY the two involved parties. determination is trivially simple, with no additional hardware, and a minimum amount of code, and storage - in fact the support of multihoming requires the presence of that code anyways. Only if you presume that there's only one subnet per link, which is clearly not reasonable -- it represents loss of features as compared with IPv4. Why do you make that presumption? You can have multiple subnets per link, and multiple IPv6 addresses per interface (link adapter). Because a host should certainly not know all prefixes associated with a link. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 16:29:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08308; Mon, 17 Oct 94 16:29:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08302; Mon, 17 Oct 94 16:29:41 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07291; Mon, 17 Oct 94 16:25:53 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA16981; Mon, 17 Oct 94 16:25:20 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA03660; Mon, 17 Oct 1994 19:25:08 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA14145; Mon, 17 Oct 1994 19:25:05 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA09272; Mon, 17 Oct 1994 19:01:37 -0400 Message-Id: <9410172301.AA09272@brigit.zk3.dec.com> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com Subject: Re: (IPng) Re: ARP In-Reply-To: Your message of "Mon, 17 Oct 94 15:24:29 PDT." <199410172224.PAA23620@lager.cisco.com> Date: Mon, 17 Oct 94 19:01:37 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM If you read 1. and 2., the difference is that 1. requires a third party, besides the two communicating hosts, while 2. requires only the two communicating hosts. We're arguing in circles here. Agree. There is NO requirement for a third party. There is currently NO mechanism for using the resources of ONLY the two involved parties. NO - NO, we don't start another circle. Only if you presume that there's only one subnet per link, which is clearly not reasonable -- it represents loss of features as compared with IPv4. Why do you make that presumption? You can have multiple subnets per link, and multiple IPv6 addresses per interface (link adapter). Because a host should certainly not know all prefixes associated with a link. If the reason is something that has not already been said on this list, then you should say why. We certainly disagree. A host is capable to store and use, and therefore should know the prefixes of the subnets it is part of - not all subnets just those it is part of - (in fact the prefixes length, since it holds all the prefixes in its IPv6 addresses anyways). Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 16:37:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08320; Mon, 17 Oct 94 16:37:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08314; Mon, 17 Oct 94 16:36:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB07979; Mon, 17 Oct 94 16:33:07 PDT Received: from munnari.oz.au ([128.250.1.21]) by Sun.COM (sun-barr.Sun.COM) id AA18178; Mon, 17 Oct 94 16:32:09 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA05961; Tue, 18 Oct 1994 09:30:07 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA06563; Tue, 18 Oct 94 09:17:37 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT05042; Tue, 18 Oct 1994 09:17:34 EST Date: 18 Oct 94 09:28:20 +1100 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) RE: RE: (IPNG) FLOW LABELS Ua-Content-Id: 941018 08:28:03 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941018 08:28:03 005 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941018092820+1100 deferred 941018092820+1100 action Relayed Message-Id: <"941018 08:28:03"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: x400@mis@dcpmel[c=au;a=telememo;p=datacraft;o=smtp;s=ipng(a)sunroof.eng.sun.com;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: having problems with responses.. so here it is again. -------------------------- [Original Message] ------------------------- gday, thanks for the response jon.. I have been "talking" (in IA5) to scott on this also.. some comments though. There is never a problem with networks if one over provisions.. so this cannot be a "solution" when dealing with flow or QOS processing. with service levels, one has to deal with protocol behavior, nominal switch power, buffering/discard rates and packet distribution scenarios.. and deal with predictable degredation, in band signalling, connection/service management and higher level control (eg, IN).. What the issue is is that IP is an Internetworking connectionless protocol and therefore is logically detached from the underlying network resources that support it. It requests "resources" via abstracted QOS specifications.. which are interpreted by the network dependent protocols (signalling) or link management according to the services as offered by those lower levels.. These may or may not be network wide or end to end... AS IP moves to ATM (switched ATM) or switched ISDN, then B-ISDN signalling SHOULD be used to request network service levels.. I find it wierd that one must use a "resource allocation" Internetworking protocol to set up a "connection" (ie give knowledge of a data flow to the switches) and reserve resources in what must be a internetworking connection oriented environment for a connection less protocol that follows..Does the RSVP also use the same network dependent signalling procedures? Doh! I will read the RFC's Why not just make an IP option of a connection oriented protocol.. ie an IPCLNS and IPCONS.. that way it can map itself to QOS mechanisms of the underlying signalling and save all that hoo hah...and be more predicatble.. I feel that trying to get commercial level QOS for connectionless, internetworking protocols without overprovisioning or massive network signalling mechanisms.. will be an endless struggle. Hence the comments that have been received on the the failings of IP4TOS.. (Question ...if IP4 TOS is seen to have failed and was more simple than IP6 Flow ids with all the stuff above.. what chance does it (IP6flow) have of being implemented and made consistent?). Anyway I will read the books.. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 19:09:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08508; Mon, 17 Oct 94 19:09:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08502; Mon, 17 Oct 94 19:09:36 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22659; Mon, 17 Oct 94 19:05:48 PDT Received: from databus.databus.com ([198.186.154.34]) by Sun.COM (sun-barr.Sun.COM) id AA16605; Mon, 17 Oct 94 19:05:16 PDT Date: Mon, 17 Oct 94 22:05 EDT Message-Id: <9410172205.AA15474@databus.databus.com> From: Barney Wolff To: conta@zk3.dec.com, barney@databus.com Cc: ipng@sunroof.Eng.Sun.COM, sob@harvard.edu Subject: Re: (IPng) Re: ARP, etc. Content-Length: 4599 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Mon, 17 Oct 94 16:04:15 -0400 > From: conta@zk3.dec.com > > ... A really lightweight implementation does > not trouble itself with table-driven elegance but just does a case ARPng: > > Is this an acceptable solution? For a lightswitch? Are you kidding? > > - you use the link header as source of information > ... > > You do not seem to have a problem using a link protocol type without any > protocol header. You think that you can use informaton passed in the link > layer header, and ignore the need of information that is passed today in the > ARP header, but although this may work in a particular case, and with > a particular implementation, it does not scale to all links, and to all > implementations. The ARP protocol header has an important role besides > the role of passing the IP and Media address. It is creating a unified > environment in which information typical to each link can be processed in > the same way, regardless of differences that exist at link layer level. > Think about this a little more. This is indeed a fundamental point. I started by suggesting piggybacking the IP packet on the ARP request, but that raised issues of cutting the MTU. As I said in my last post, since the only thing in the ARP request which is not in the IPv6 header is the caller's link-layer address, one might consider putting just that in an optional header. If even this is not acceptable to the community, and the link-layer source address is considered inaccessible or unreliable, then no piggybacking is possible. > > If you didn't then you MIGHT just create the same problem as > > Bill's. So you do IPv6 header pre-processing, before getting into the > > IPv6 layer protocol engine. Do you like it? Is it worth? > > Isn't this what any ARP implementation does today, to see if the > packet's for it? > > After checking version, can't I just check the dest > IPv6 address against my own set? Some option or other may mean that > the address matches but the packet's not really for me? I hope not. > > You imply that there is no difference. Are you over simplifying, or just > ignoring? > > Today an ARP implementation is processing ARP header information. Both the ARP > processing and ARP header are different than IPv4 processing and IPv4 header. > > After checking version, can't I just check the dest > IPv6 address against my own set? > > And then do that again in the IPv6 protocol engine? Oh come on. ARP request processing makes exactly the same check - and takes a whole extra packet to do it, too. Think about this a little more. Do please show us how and why checking an IPv6 address against the set of "my addresses" is harder when it's in the IPv6 header than when it's in the ARP request, with variable length at a variable offset. > ... in the normal case, I don't expect that another packet will > arrive before the timeout - do you? > > > The role of the buffering is most importantly to not lose packets, that > > otherwise have to be retransmitted by a transport or application. The host > > unreachable is in many implementations shunt-ed. > > Where did these packets come from, all of a sudden? Under what > circumstances does communication with a new host start with a burst? > > Is this another case of over simplifying, or just ignoring? How about answering the question, instead of sneering? I will be glad to be shown that RFC1122 section 2.3.2.2 failed to anticipate a packet burst, *all of which are different and valid*. Could someone with live large-scale network management experience comment on how often an ARP retry succeeds, and what a reasonable ARP response timeout is, and how often another packet arrives before the timeout? > But multicast does help when a network has a lot of hosts on a wire, > and the adapter hardware handles the filtering (which may be never, I > suppose). > > Using the hashing function helps as desired only if you have an address space > usage that is uniformly contiguous. Oh no - the hash need not be perfect. But it will often be much better than nothing (ie, broadcast, or 1 multicast group for all IPv6 addresses). To summarize: Bill proposed (in the draft) a mechanism with two multicast packets, the first IPv6 packet and a General Solicitation. Alex appears to favor keeping ARP. I have proposed two mechanisms for piggybacking an address resolution request on the first IP packet, neither of which is without blemish. Where do we go from here? Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 22:01:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08668; Mon, 17 Oct 94 22:01:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08662; Mon, 17 Oct 94 22:01:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29900; Mon, 17 Oct 94 21:57:45 PDT Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by Sun.COM (sun-barr.Sun.COM) id AA11987; Mon, 17 Oct 94 21:57:24 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA17885; Mon, 17 Oct 94 21:51:07 -0700 Received: by xirtlu.zk3.dec.com; id AA03750; Tue, 18 Oct 1994 00:51:04 -0400 Message-Id: <9410180451.AA03750@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Mon, 17 Oct 94 19:01:37 EDT." <9410172301.AA09272@brigit.zk3.dec.com> Date: Tue, 18 Oct 94 00:50:59 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks I think we need some test cases to figure this out and to clean the cobb webs out of the discussion. Host A on Link Z Interface 'a' has prefix 1111 for subnet S1 as part of its address. Interface 'a' has prefix 1110 for subnet S2 as part of its address. Interface 'b' has prefix 1110 for subnet S2 as part of its address. Host B on Link Z Interface 'c' has prefix 1111 for subnet S1 as part of its address. Interface 'd' has prefix 1110 for subnet S2 as part of its address. Host C on Link Z Interface 'e' has prefix 1111 for subnet S1 as part of its address. All Hosts are on the same Link Z. Host A Interface 'a' has multiple addresses on Interface 'a' to recognize Subnet S1 and S2. Host B-c-S1 can communicate with Host A-a-S1 and Host C-e-S1. Host B-d-S2 can communicate with Host A-a-S2 and A-b-S2. But in the above. Host C-e-S1 cannot communicate directly with Host A-a-S2 or Host B-d-S2 unless a forwarding mechanism is used based on the previous discussions. A redirect to Host C-e-S1 with only one address on that interface to send to the MAC address of Host A-a-S2 or Host B-d-S2 I believe is a violation. Because I think Hosts should understand their position in the network relative to their subnet based on their prefix. This translates to hosts knowing their prefix and using that knowledge as required for host implementations. This is where the core disagreement is at present? Right now the specs to my knowledge do not state what I have to do as an implementor of IPv6. I interpret the specs at this time that I would not accept this redirect on my host implementation. It would be good if we could get this ironed out one way or another before San Jose. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 22:26:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08712; Mon, 17 Oct 94 22:26:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08706; Mon, 17 Oct 94 22:25:57 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01202; Mon, 17 Oct 94 22:22:09 PDT Received: from feta.cisco.com ([131.108.13.70]) by Sun.COM (sun-barr.Sun.COM) id AA13865; Mon, 17 Oct 94 22:21:50 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA14253; Mon, 17 Oct 1994 22:21:49 -0700 Date: Mon, 17 Oct 1994 22:21:49 -0700 From: Dave Katz Message-Id: <199410180521.WAA14253@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: bound@zk3.dec.com's message of Tue, 18 Oct 94 00:50:59 -0400 <9410180451.AA03750@xirtlu.zk3.dec.com> Subject: Subnets Again was Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A redirect to Host C-e-S1 with only one address on that interface to send to the MAC address of Host A-a-S2 or Host B-d-S2 I believe is a violation. Of what? And what problem results from this? Because I think Hosts should understand their position in the network relative to their subnet based on their prefix. This translates to hosts knowing their prefix and using that knowledge as required for host implementations. I read this as an example of why hosts *shouldn't* try to be too knowledgable about their place in the universe. Hosts should not be trying to second-guess the routing infrastructure, which to me seems to be what's going on here. Keep in mind that there will be situations where the idea of the "prefix on the wire" doesn't make sense (such as direct host attaches to large NBMA networks), and getting too literal about the subnet model is going to lead to problems. Try to view subnets/prefixes as a clustering mechanism to reduce the load on the routing infrastructure. I become very uncomfortable when an attempt is made to read much more into the concept. This is where the core disagreement is at present? Right now the specs to my knowledge do not state what I have to do as an implementor of IPv6. I interpret the specs at this time that I would not accept this redirect on my host implementation. It would be good if we could get this ironed out one way or another before San Jose. Indeed. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 17 23:12:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08739; Mon, 17 Oct 94 23:12:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08733; Mon, 17 Oct 94 23:12:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02734; Mon, 17 Oct 94 23:08:39 PDT Received: from feta.cisco.com ([131.108.13.70]) by Sun.COM (sun-barr.Sun.COM) id AA17111; Mon, 17 Oct 94 23:08:19 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA15450; Mon, 17 Oct 1994 23:08:19 -0700 Date: Mon, 17 Oct 1994 23:08:19 -0700 From: Dave Katz Message-Id: <199410180608.XAA15450@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Barney Wolff's message of Sat, 15 Oct 94 05:21 EDT <9410150522.AA10300@databus.databus.com> Subject: (IPng) Re: ARP, etc. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I offer the following anecdote as one of the things that's wrong with ARP and Proxy ARP. (I wish that the latter had kept its original name, which was the "ARP Hack;" the current name makes it sound like We Meant to Do That. But I digress.) A number of InterOps ago ('90, I think) I plugged in a BSD machine, booted it up, and got, "Duplicate IP Address!" This was curious; I was pretty sure that I was using the proper one. OK, what the heck, I'll change it. "Duplicate IP Address!" Changed it a few more times. "Duplicate IP Address!" Seems that BSD machines used a clever hack as a first-order test of whether the host had been misconfigured--the host ARPs for its own address, and if anybody answers, the address must be a duplicate. Weird. Everything seemed to be configured properly. Finally broke out a Sniffer and watched. Seems that an unnamed bridge vendor was part of a multivendor technology demo and had run an 802.4 (!) link between the demo booth and their home booth, and then said, "what the heck,", and bridged in the booth drop as well. The routers at the head of each segment politely answered via proxy every ARP sent on the other segment. Moral of the story: we need to add one more requirement to the pile-- Nets must be robust in the face of bridges/repeaters/miswired hubs. This kind of thing is quite common, and will become more so as datalink switching becomes more widespread. (And, wearing my scarlet 'O' and hanging my head in eternal shame and penitence, I'll point out that the OSI network layer is immune to this sort of thing, precisely because no host assumptions are made about how network addresses and physical topology fit together.) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 00:06:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08752; Tue, 18 Oct 94 00:06:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08746; Tue, 18 Oct 94 00:06:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04329; Tue, 18 Oct 94 00:02:17 PDT Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA21443; Tue, 18 Oct 94 00:01:45 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 18 Oct 94 15:53:36 +0900 From: Masataka Ohta Message-Id: <9410180653.AA09230@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof.Eng.Sun.COM Date: Tue, 18 Oct 94 15:53:35 JST In-Reply-To: <"941018 08:28:03"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS>; from "/G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au" at Oct 18, 94 9:28 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > What the issue is is that IP is an Internetworking connectionless protocol > and therefore is logically detached from the underlying network resources > that support it. > It requests "resources" via abstracted QOS specifications.. which are > interpreted by the network dependent protocols (signalling) or link > management according to the services as offered by those lower levels.. > These may or may not be network wide or end to end... Just as we can constuct connection oriented transport layer protocol, TCP, over connectionless internet layer protocol, IP, we can construct reservation based transport layer protocol over IP. > AS IP moves to ATM (switched ATM) or switched ISDN, then B-ISDN signalling > SHOULD be used to request network service levels.. No, not at all. ATM is at the link layer and B-ISDN signalling may, just like ARP, be used for link layer setup. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 00:22:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08764; Tue, 18 Oct 94 00:22:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08758; Tue, 18 Oct 94 00:22:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04865; Tue, 18 Oct 94 00:18:27 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA25791; Tue, 18 Oct 94 00:18:06 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14216; Tue, 18 Oct 1994 08:18:03 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05474; Tue, 18 Oct 1994 08:18:01 +0100 Message-Id: <9410180718.AA05474@dxcoms.cern.ch> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Tue, 18 Oct 1994 08:18:01 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199410180521.WAA14253@feta.cisco.com> from "Dave Katz" at Oct 17, 94 10:21:49 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 681 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim: > A redirect to Host C-e-S1 with only one address on that interface to > send to the MAC address of Host A-a-S2 or Host B-d-S2 I believe is a > violation. Dave: > Of what? And what problem results from this? > I agree with Dave. It seems more like an optimisation than a violation. And Jim works for the people who invented the "on Ethernet" bit :-) There is one potential problem area, I think, with bridged networks. If a dual-interfaced host, for whatever reason, is silent on one of its interfaces, the address of that interface gets forgotten by the bridges. With Jim's example, I have no doubt you can construct scenarios where this happens. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 01:18:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08794; Tue, 18 Oct 94 01:18:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08788; Tue, 18 Oct 94 01:18:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06509; Tue, 18 Oct 94 01:14:41 PDT Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by Sun.COM (sun-barr.Sun.COM) id AA29436; Tue, 18 Oct 94 01:14:20 PDT Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Oct 1994 09:14:14 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RE: RE: (IPNG) FLOW LABELS In-Reply-To: Your message of "18 Oct 94 09:28:20 +1000." <"941018 08:28:03"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> Date: Tue, 18 Oct 94 09:14:12 +0100 Message-Id: <817.782468052@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Why not just make an IP option of a connection oriented protocol.. ie an >IPCLNS and IPCONS.. that way it can map itself to QOS mechanisms of the >underlying signalling and save all that hoo hah...and be more predicatble.. the RSVP + Integrated Services model is what i call "connectionish" - it has state i nthe routers, but does not tie the patrh down unless needed, and has a periodic state refresh mechanism to recover from router or path alterations. >I feel that trying to get commercial level QOS for connectionless, >internetworking protocols without overprovisioning or massive network >signalling mechanisms.. will be an endless struggle. Hence the comments that >have been received on the the failings of IP4TOS.. (Question ...if IP4 TOS >is seen to have failed and was more simple than IP6 Flow ids with all the >stuff above.. what chance does it (IP6flow) have of being implemented and >made consistent?). zealots of 'soft state' compare the cost of circuit based networks, and tend to deduce that starting with IP (or IP6) and evolving towards sufficient and necessary mechanisms for guarantees is probably gonna get us a more cost-optimal solution than starting with circuits and trying to ffigure out how to add dynamic routing and fault tolerance (on a per packet level of granulairity) the cost of the NSFnet backbonr and its availaiblity are really very impressive testimonies to this (in fact our experience i nthe UK switching from largely x.5 based to an IP based net also supports this - i'm not talking about s/w costs here, but about complexity of managing the interconenct fabric and resulting performance/etc) jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 05:18:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08928; Tue, 18 Oct 94 05:18:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08922; Tue, 18 Oct 94 05:17:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12755; Tue, 18 Oct 94 05:14:05 PDT Received: from sundance.itd.nrl.navy.mil ([132.250.92.89]) by Sun.COM (sun-barr.Sun.COM) id AA19270; Tue, 18 Oct 94 05:13:45 PDT To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Host prefix knowledge Date: Tue, 18 Oct 94 13:09:51 GMT From: Ran Atkinson Message-Id: <9410181309.aa00516@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I agree with Jim Bound on this. I keep being told that its a problem by router vendors, but I haven't seen a persuasive argument yet. Among other things, consider a multi-level secure (sic) network that runs over a single common physical link and uses RFC-1108 labelling. In that case, there are several logically separate subnets, often one per sensitivity level. The examples Jim gave apply quite nicely here if you associate a different sensitivity level with each prefix. These sorts of networks are increasingly common as most vendors (e.g. IBM, DEC, HP, Sun, SGI, SCO) now ship B1 or B1/Compartmented-Mode Workstations as commercial products. This scenario works properly with IPv4. I do NOT want to lose capability when I move to IPv6. Hosts need to know the prefix of their attached interfaces (not all interfaces in the world, only active attached interfaces) to retain this capability. Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 05:52:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09002; Tue, 18 Oct 94 05:52:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08990; Tue, 18 Oct 94 05:52:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14589; Tue, 18 Oct 94 05:48:33 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA22305; Tue, 18 Oct 94 05:48:13 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id FAA09593; Tue, 18 Oct 1994 05:48:11 -0700 Date: Tue, 18 Oct 1994 05:48:11 -0700 From: Tony Li Message-Id: <199410181248.FAA09593@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: Ran Atkinson's message of Tue, 18 Oct 94 13:09:51 GMT <9410181309.aa00516@sundance.itd.nrl.navy.mil> Subject: (IPng) Host prefix knowledge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Among other things, consider a multi-level secure (sic) network that runs over a single common physical link and uses RFC-1108 labelling. In that case, there are several logically separate subnets, often one per sensitivity level. The examples Jim gave apply quite nicely here if you associate a different sensitivity level with each prefix. These sorts of networks are increasingly common as most vendors (e.g. IBM, DEC, HP, Sun, SGI, SCO) now ship B1 or B1/Compartmented-Mode Workstations as commercial products. This scenario works properly with IPv4. I do NOT want to lose capability when I move to IPv6. Hosts need to know the prefix of their attached interfaces (not all interfaces in the world, only active attached interfaces) to retain this capability. Ran, Are you asserting that our proposed relaxation of the rules would break RFC 1108? And if so, how? And are you really planning on using RFC 1108 verbatim in the new world order? Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 05:52:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09003; Tue, 18 Oct 94 05:52:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08991; Tue, 18 Oct 94 05:52:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14589; Tue, 18 Oct 94 05:48:33 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA22305; Tue, 18 Oct 94 05:48:13 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id FAA09593; Tue, 18 Oct 1994 05:48:11 -0700 Date: Tue, 18 Oct 1994 05:48:11 -0700 From: Tony Li Message-Id: <199410181248.FAA09593@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: Ran Atkinson's message of Tue, 18 Oct 94 13:09:51 GMT <9410181309.aa00516@sundance.itd.nrl.navy.mil> Subject: (IPng) Host prefix knowledge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Among other things, consider a multi-level secure (sic) network that runs over a single common physical link and uses RFC-1108 labelling. In that case, there are several logically separate subnets, often one per sensitivity level. The examples Jim gave apply quite nicely here if you associate a different sensitivity level with each prefix. These sorts of networks are increasingly common as most vendors (e.g. IBM, DEC, HP, Sun, SGI, SCO) now ship B1 or B1/Compartmented-Mode Workstations as commercial products. This scenario works properly with IPv4. I do NOT want to lose capability when I move to IPv6. Hosts need to know the prefix of their attached interfaces (not all interfaces in the world, only active attached interfaces) to retain this capability. Ran, Are you asserting that our proposed relaxation of the rules would break RFC 1108? And if so, how? And are you really planning on using RFC 1108 verbatim in the new world order? Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 06:33:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09057; Tue, 18 Oct 94 06:33:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09051; Tue, 18 Oct 94 06:33:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16274; Tue, 18 Oct 94 06:29:33 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA27809; Tue, 18 Oct 94 06:28:16 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA11007 for ; Tue, 18 Oct 1994 09:27:50 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA16157 for ; Tue, 18 Oct 1994 09:27:49 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA11465; Tue, 18 Oct 94 09:27:49 EDT Message-Id: <9410181327.AA11465@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: ARP, etc. In-Reply-To: Your message of "Mon, 17 Oct 1994 23:08:19 PDT." <199410180608.XAA15450@feta.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Tue, 18 Oct 1994 09:27:48 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave Katz says: > Moral of the story: we need to add one more requirement to the pile-- > Nets must be robust in the face of bridges/repeaters/miswired hubs. I'm not sure you can make things robust in the face of every possible situation. I just want to assure that things don't change too much and there are at least some architectures that are very robust. That way I can just make sure that those are the architectures I use. My fear is that we are moving towards architectures that have never been tested and never become robust. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 08:06:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09098; Tue, 18 Oct 94 08:06:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09092; Tue, 18 Oct 94 08:06:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20502; Tue, 18 Oct 94 08:02:42 PDT Received: from nbkanata.Newbridge.COM ([192.75.23.5]) by Sun.COM (sun-barr.Sun.COM) id AA06971; Tue, 18 Oct 94 07:57:57 PDT Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA27006; Tue, 18 Oct 94 10:28:55 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA20338; Tue, 18 Oct 94 10:28:46 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA10432; Tue, 18 Oct 94 10:34:36 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA03018; Tue, 18 Oct 1994 10:34:35 +0500 Date: Tue, 18 Oct 1994 10:34:35 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9410181434.AA03018@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP X-Sun-Charset: US-ASCII Content-Length: 1923 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim Bound gives a nice enumeration of cases, and conclusions. The key element I disagree with is "hosts knowing their prefix and using that knowledge". One suggestion I have heard is that routers be permitted, but not required, to advertise prefixes. This is a fine and useful thing. If routers are advertising prefixes, hosts clearly should use such information. However, such usage should be inclusive, not exclusive. That is, it is desirable for the host to "know" that things in that prefix are on the same wire. However, the host should not "know" that things outside the prefix are not on the same wire. If a host gets a redirect to an IPv6/MAC address pair, it should use that without regard to whether it matches a prefix the host knows about. (Note that the policy on whether to send such a redirection is a local matter, to allow the strict separation that some people want.) I believe that this allows the efficiency of prefix use without putting "smarts" in the host which get in the way of routing flexibility, particularly as it relates to large NBMA networks. On a somewhat related note, there has been discussion of using the data packet as the ARP request, by sending it on a media level multicast. There are two kinds of cases when this will come up. One case, which I tend to agree would not be onnerous by itself, is when a new communication starts up. However, if one is using a protocol which has been idle for a while, a new message may be a large one when the ARP entry has expired. An example of this is an NFS write from a workstation. If the machine has been operating locally for an extended time, it could easily have expired the ARP entry. While I understand the attraction of the time savings, there are a number of architectures where this large multicast packet could be a significant hardship. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 08:48:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09168; Tue, 18 Oct 94 08:48:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09162; Tue, 18 Oct 94 08:47:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23235; Tue, 18 Oct 94 08:44:05 PDT Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA13508; Tue, 18 Oct 94 08:40:10 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA10196; Tue, 18 Oct 94 07:26:09 -0700 Received: by xirtlu.zk3.dec.com; id AA16473; Tue, 18 Oct 1994 10:25:53 -0400 Message-Id: <9410181425.AA16473@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Mon, 17 Oct 94 22:21:49 PDT." <199410180521.WAA14253@feta.cisco.com> Date: Tue, 18 Oct 94 10:25:47 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A redirect to Host C-e-S1 with only one address on that interface to send to the MAC address of Host A-a-S2 or Host B-d-S2 I believe is a violation. >Of what? And what problem results from this? Well I believe the model in IPv4 is correct per the code path. If my dst address is on this subnet I send the packet on its way. Otherwise I determine which router I send the packet to in the case of no default router. Because I think Hosts should understand their position in the network relative to their subnet based on their prefix. This translates to hosts knowing their prefix and using that knowledge as required for host implementations. >I read this as an example of why hosts *shouldn't* try to be too >knowledgable about their place in the universe. Hosts should not be >trying to second-guess the routing infrastructure, which to me >seems to be what's going on here. Another way to look at is that hosts are using knowledge of their subnet or prefix in IPv6 to directly communicate with nodes on the same link using the same prefix. This is not understanding the Universe or the Routing Infrastructure. Your statement is extreme in this debate. If I want my UNIX host to know that I turn on the code to make it a router. >Keep in mind that there will be situations where the idea of the >"prefix on the wire" doesn't make sense (such as direct host attaches >to large NBMA networks), and getting too literal about the subnet model >is going to lead to problems. Please say more and explain why this is true in detail I don't see your point? >Try to view subnets/prefixes as a clustering mechanism to reduce the >load on the routing infrastructure. I become very uncomfortable when >an attempt is made to read much more into the concept. Well I become uncomfortable with changing the basic tenet of IPv4 on the hosts regarding subnets. I want this model kept through prefixes in IPv6. This is where the core disagreement is at present? Right now the specs to my knowledge do not state what I have to do as an implementor of IPv6. I interpret the specs at this time that I would not accept this redirect on my host implementation. It would be good if we could get this ironed out one way or another before San Jose. >Indeed. I hope the implementor notes come out very soon because this was discussed at that meeting. From my recollection it was consensus in that discussion that we should relate to the working group that we felt hosts must have knowledge of prefixes as additional input to this discussion per the arguments amongst the implementors. I hope this will affect the working group to reach closure on this issue. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 09:37:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09245; Tue, 18 Oct 94 09:37:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09104; Tue, 18 Oct 94 08:13:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20863; Tue, 18 Oct 94 08:10:10 PDT Received: from relay1.pipex.net ([158.43.128.4]) by Sun.COM (sun-barr.Sun.COM) id AA29089; Tue, 18 Oct 94 06:40:49 PDT Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <17655-0@relay1.pipex.net>; Tue, 18 Oct 1994 14:39:19 +0100 Received: by widow.spider.co.uk; Tue, 18 Oct 94 14:41:06 +0100 From: Andy Davis Date: Tue, 18 Oct 94 14:36:26 +0100 Message-Id: <25030.9410181336@raft.spider.co.uk> Received: by raft.spider.co.uk; Tue, 18 Oct 94 14:36:26 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Terminology - Cluster Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The concept of a Cluster Address is certainly one which has me baffled, because it is an artefact for which I cannot imagine a use. The name is misleading, because I might expect a packet sent to the cluster address to be delivered to ALL the nodes in that cluster - the suggestion of "boundary address" might be an improvement; deliver the packet to the "boundary"? But why? Please can someone enlighten me? Andy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 10:26:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09279; Tue, 18 Oct 94 10:26:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09273; Tue, 18 Oct 94 10:26:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03721; Tue, 18 Oct 94 10:23:02 PDT Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA13360; Tue, 18 Oct 94 08:39:46 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA10712; Tue, 18 Oct 94 07:32:40 -0700 Received: by xirtlu.zk3.dec.com; id AA16657; Tue, 18 Oct 1994 10:32:24 -0400 Message-Id: <9410181432.AA16657@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Re: ARP, etc. In-Reply-To: Your message of "Mon, 17 Oct 94 23:08:19 PDT." <199410180608.XAA15450@feta.cisco.com> Date: Tue, 18 Oct 94 10:32:18 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Moral of the story: we need to add one more requirement to the pile-- >Nets must be robust in the face of bridges/repeaters/miswired hubs. >This kind of thing is quite common, and will become more so as >datalink switching becomes more widespread. (And, wearing my scarlet >'O' and hanging my head in eternal shame and penitence, I'll point out >that the OSI network layer is immune to this sort of thing, precisely >because no host assumptions are made about how network addresses and >physical topology fit together.) No the moral of the story is hacks can wreak havoc on any network. Your sublimal argument against host knowledge of prefixes is based on a bad implementation. As many have said and I agree with; we should not build or determine standards based on bad implementations. This is a recipe for failure by missing why IPv4 was defined the way it was and how it was implemented by good implementations. Using clever hacks can be done to any protocol to cause faulty behavior. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 11:55:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09411; Tue, 18 Oct 94 11:55:56 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09405; Tue, 18 Oct 94 11:55:44 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA00507; Tue, 18 Oct 1994 11:51:57 -0700 Date: Tue, 18 Oct 1994 11:51:57 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410181851.LAA00507@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Cc: hinden@jurassic In-Reply-To: <9410181309.aa00516@sundance.itd.nrl.navy.mil> Subject: (IPng) Host prefix knowledge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I also think that hosts need to know about prefixes. There may be host implementations which will not use this information, but the ones I am familiar with, do need it. My model is that the hosts are getting more complicated in this area. For example my laptop has more different network interfaces (ethernet, PPP, appletalk) than my desktop machine (ethernet). The laptop is likely to add a wireless interface soon. My desktop machine will not. Currently the laptop only allows me to use one interface at a time, but I think this will soon change. It will need to decide which one to use independent of a router. Servers are also commonly connected to many interfaces. The server needs to choose the correct interface to talk to it's clients without the traffic going through a router. For example a multi-homed file server wants to talk to its clients on it's directly connected subnets directly without through or consulting a router. The issue is that the router does not know what interfaces the host has. It can not tell the host which interface to use. The host needs to determine this itself. The only alternative I see is to turn all multi-homed hosts into full fledged routers. This seems undesirable to me. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 13:02:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09469; Tue, 18 Oct 94 13:02:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09463; Tue, 18 Oct 94 13:02:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19596; Tue, 18 Oct 94 12:58:12 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA27454; Tue, 18 Oct 94 12:57:37 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA03634; Tue, 18 Oct 1994 12:31:30 -0700 Date: Tue, 18 Oct 1994 12:31:30 -0700 From: Tony Li Message-Id: <199410181931.MAA03634@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, Bob.Hinden@Eng In-Reply-To: Bob Hinden's message of Tue, 18 Oct 1994 11:51:57 -0700 <199410181851.LAA00507@jurassic.Eng.Sun.COM> Subject: (IPng) Host prefix knowledge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, The issue is that the router does not know what interfaces the host has. It can not tell the host which interface to use. The host needs to determine this itself. The only alternative I see is to turn all multi-homed hosts into full fledged routers. This seems undesirable to me. The host can certainly determine this, but it should not have stable state about this information. If the host queries the routers on each interface as to the optimal path, then it has a simple soft state solution. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 13:42:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09510; Tue, 18 Oct 94 13:42:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09504; Tue, 18 Oct 94 13:42:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23977; Tue, 18 Oct 94 13:38:59 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA02773; Tue, 18 Oct 94 13:30:04 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA09758; Tue, 18 Oct 1994 13:29:12 -0700 Date: Tue, 18 Oct 1994 13:29:12 -0700 From: Tony Li Message-Id: <199410182029.NAA09758@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: bound@zk3.dec.com's message of Tue, 18 Oct 94 10:25:47 -0400 <9410181425.AA16473@xirtlu.zk3.dec.com> Subject: Subnets Again was Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A redirect to Host C-e-S1 with only one address on that interface to send to the MAC address of Host A-a-S2 or Host B-d-S2 I believe is a violation. >Of what? And what problem results from this? Well I believe the model in IPv4 is correct per the code path. If my dst address is on this subnet I send the packet on its way. Otherwise I determine which router I send the packet to in the case of no default router. I wasn't aware that not changing the code path was a requirement for IPv6. I'll re-ask Dave's question beause this is not a reasonable answer. >Keep in mind that there will be situations where the idea of the >"prefix on the wire" doesn't make sense (such as direct host attaches >to large NBMA networks), and getting too literal about the subnet model >is going to lead to problems. Please say more and explain why this is true in detail I don't see your point? Suppose that your workstation is attached to the worldwide ATM cloud. According to your model(s), one of the following is true: a) your host has knowledge of every subnet on the ATM cloud b) your host has knowledge of its subnet and can find other subnets without the use of routers In our model c) your host has knowledge of its address and can get link layer information from a server, and d) if there are no servers and its a broadcast medium, you can broadcast Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 15:26:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09738; Tue, 18 Oct 94 15:26:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09732; Tue, 18 Oct 94 15:26:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06164; Tue, 18 Oct 94 15:22:31 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA27589; Tue, 18 Oct 94 15:22:29 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA21260; Tue, 18 Oct 1994 15:18:27 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA02123; Tue, 18 Oct 1994 15:18:27 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA09751; Tue, 18 Oct 1994 14:55:02 -0400 Message-Id: <9410181855.AA09751@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, bound@zk3.dec.com Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 18 Oct 94 00:50:59 EDT." <9410180451.AA03750@xirtlu.zk3.dec.com> Date: Tue, 18 Oct 94 14:55:02 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM .... Host C-e-S1 cannot communicate directly with Host A-a-S2 or Host B-d-S2 unless a forwarding mechanism is used based on the previous discussions. Jim has chosen a particular case of a link in which one of the hosts (C) is not on the same subnet (S2) with other hosts (A, and B). I would point out the following: 1. In IPv6, considering current "system discovery" specs, Jim's particular case gets configured this way only if the system or network manager specifically DOES WANT host C be part of S1, and NOT S2. 2. In a normal situation, conform with system discovery specs, the router on the link, would advertize global IPv6 addresses and prefixes for both subnets S1, and S2, and so hosts A, B, C, would get IPv6 addresses that would be part of both S1, and S2, allowing the hosts A, B, and C communicate on both S1, and S2 subnet (hosts can have muliple IPv6 addresses per interface). A redirect to Host C-e-S1 with only one address on that interface to send to the MAC address of Host A-a-S2 or Host B-d-S2 I believe is a violation. Because I think Hosts should understand their position in the network relative to their subnet based on their prefix. This translates to hosts knowing their prefix and using that knowledge as required for host implementations. This is where the core disagreement is at present? Right now the specs to my knowledge do not state what I have to do as an implementor of IPv6. I interpret the specs at this time that I would not accept this redirect on my host implementation. It would be good if we could get this ironed out one way or another before San Jose. Going back to 1., the system or network manager DOES NOT WANT host C be on subnet S2, because of specific reasons. One such reason could be that there is a need to monitor or do accounting of all packets that go from host C to subnet S2, and a proper place to do the monitoring or accounting is the router, so host C will get or send its packets from/to S2 through the router. For the router to send a redirect to host C for packets that go to S2, would make sense only in a case when the router MUST not be involived in C's traffic with S2. But then, host C should have been given by the router a global IPv6 address which through its prefix is part of S2 from the very beginning, this way avoiding any redirects and forwarding. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 15:28:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09754; Tue, 18 Oct 94 15:28:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09748; Tue, 18 Oct 94 15:28:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06301; Tue, 18 Oct 94 15:23:53 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA27951; Tue, 18 Oct 94 15:23:51 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA21884; Tue, 18 Oct 1994 15:32:07 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA03239; Tue, 18 Oct 1994 15:32:01 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA09774; Tue, 18 Oct 1994 15:08:36 -0400 Message-Id: <9410181908.AA09774@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, brian@dxcoms.cern.ch Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 18 Oct 94 08:18:01 BST." <9410180718.AA05474@dxcoms.cern.ch> Date: Tue, 18 Oct 94 15:08:36 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim: > A redirect to Host C-e-S1 with only one address on that interface to > send to the MAC address of Host A-a-S2 or Host B-d-S2 I believe is a > violation. Dave: > Of what? And what problem results from this? > I agree with Dave. It seems more like an optimisation than a violation. And Jim works for the people who invented the "on Ethernet" bit :-) According to the current 'system discovery' each host is given its global IPv6 addresses by a router. One host's IPv6 addresses contain the prefixes for all subnets which that host is part of. For a router to advertize to a host selectively only a subset of the subnets on the link on which the host is connected on, and then later 'redirect' the hosts packets to those subnets it did not advertise, can be interpreted as NON-SENSE, or BAD CONFIGURATION, or BOGUS router. There is one potential problem area, I think, with bridged networks. If a dual-interfaced host, for whatever reason, is silent on one of its interfaces, the address of that interface gets forgotten by the bridges. With Jim's example, I have no doubt you can construct scenarios where this happens. Brian, There are many other scenarios that bogus bridges can mis-handle, however I do not see the relevance of that to this discussion. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 15:51:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09766; Tue, 18 Oct 94 15:51:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09760; Tue, 18 Oct 94 15:51:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08763; Tue, 18 Oct 94 15:46:56 PDT Received: from feta.cisco.com ([131.108.13.70]) by Sun.COM (sun-barr.Sun.COM) id AA02466; Tue, 18 Oct 94 15:46:32 PDT Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id PAA00451; Tue, 18 Oct 1994 15:46:17 -0700 Date: Tue, 18 Oct 1994 15:46:17 -0700 From: Dave Katz Message-Id: <199410182246.PAA00451@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, Bob.Hinden@Eng In-Reply-To: Bob Hinden's message of Tue, 18 Oct 1994 11:51:57 -0700 <199410181851.LAA00507@jurassic.Eng.Sun.COM> Subject: (IPng) Host prefix knowledge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 18 Oct 1994 11:51:57 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I also think that hosts need to know about prefixes. There may be host implementations which will not use this information, but the ones I am familiar with, do need it. My model is that the hosts are getting more complicated in this area. For example my laptop has more different network interfaces (ethernet, PPP, appletalk) than my desktop machine (ethernet). The laptop is likely to add a wireless interface soon. My desktop machine will not. Currently the laptop only allows me to use one interface at a time, but I think this will soon change. It will need to decide which one to use independent of a router. Why independently? Servers are also commonly connected to many interfaces. The server needs to choose the correct interface to talk to it's clients without the traffic going through a router. For example a multi-homed file server wants to talk to its clients on it's directly connected subnets directly without through or consulting a router. I don't think the file server particularly cares whether it consults a router first or not. And I doubt that 99% of the server administrators care, either, so long as the thing works properly. The issue is that the router does not know what interfaces the host has. It can not tell the host which interface to use. The host needs to determine this itself. The only alternative I see is to turn all multi-homed hosts into full fledged routers. This seems undesirable to me. In general the multihomed host problem cannot be solved without the aid of a router. Knowing the local prefix won't help you if the destination is not on the local link. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 16:20:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09796; Tue, 18 Oct 94 16:20:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09789; Tue, 18 Oct 94 16:20:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12252; Tue, 18 Oct 94 16:15:52 PDT Received: from nbkanata.Newbridge.COM ([192.75.23.5]) by Sun.COM (sun-barr.Sun.COM) id AA08366; Tue, 18 Oct 94 16:15:22 PDT Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA10161; Tue, 18 Oct 94 19:09:46 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA09468; Tue, 18 Oct 94 19:09:37 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA14113; Tue, 18 Oct 94 19:15:28 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA03456; Tue, 18 Oct 1994 19:15:26 +0500 Date: Tue, 18 Oct 1994 19:15:26 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9410182315.AA03456@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP X-Sun-Charset: US-ASCII Content-Length: 1576 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I believe that two issues are being confused, and that this is masking the basic disagreement that does need to be resolved. 1) There is the possiblity of subnets spanning wires. This has been "agreed" to be a non-goal. In consequence, a host which has been told a mask by a router may assume that all addresses within that mask are "directly" reachable. This I believe is agreed. 2) There is the possibility of direct communication between things which do not have a common subnet. Contrary to Alex's assertion, this does not represent NON-SENSE or BAD CONFIGURATION. In a large NBMA it is VERY desirable to allow this without informing the host of what subnets are directly reachable. There was a security concern raised. Clearly there are times when one does not want hosts communicating directly. If the direct communication only occurs as a result of re-direction from a router, then if the site manager does not want it to happen, he configures the routers not to do that. The host behavior to permit this is for the hosts to consider the masks it learns as inclusive information, not exclusive. The host should be prepared to accept re-direction from the router, since the router presumably has a better understanding of the topology and communication paths than the host does. These two behaviors are not contradictory. There is no need to restrict ourselves away from the second behavior, and many reasons to allow it. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 18:03:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09970; Tue, 18 Oct 94 18:03:50 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09964; Tue, 18 Oct 94 18:03:39 PDT Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id RAA23036; Tue, 18 Oct 1994 17:59:26 -0700 Date: Tue, 18 Oct 1994 17:59:26 -0700 From: hinden@jurassic (Bob Hinden) Message-Id: <199410190059.RAA23036@jurassic.Eng.Sun.COM> To: Dave Katz Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199410182246.PAA00451@feta.cisco.com> Subject: (IPng) Host prefix knowledge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, > Currently the laptop only allows me to use one interface at a time, but I > think this will soon change. It will need to decide which one to use > independent of a router. > > Why independently? I would prefer that the host not have to communicate with a router to send traffic on the local attached network. It is a robustness / reliability issue. > Servers are also commonly connected to many interfaces. The server needs > to choose the correct interface to talk to it's clients without the > traffic going through a router. For example a multi-homed file server > wants to talk to its clients on it's directly connected subnets directly > without through or consulting a router. > > I don't think the file server particularly cares whether it consults a router > first or not. And I doubt that 99% of the server administrators care, > either, so long as the thing works properly. That is the point. The server should still keep working (serving it's local clients) even when the router is down or unavailable. Organizations run their businesses on servers. The less dependencies the better. > The issue is that the router does not know what interfaces the host has. > It can not tell the host which interface to use. The host needs to > determine this itself. The only alternative I see is to turn all > multi-homed hosts into full fledged routers. This seems undesirable to > me. > > In general the multihomed host problem cannot be solved without the aid > of a router. Knowing the local prefix won't help you if the destination > is not on the local link. I agree that the general multi-homed host problem is difficult. I am not trying solve that problem. My concern is about the locally connected networks and agree this will not help if destination is not on the local link. My concern is when the destination is on the local link. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 19:00:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10066; Tue, 18 Oct 94 19:00:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10060; Tue, 18 Oct 94 19:00:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27108; Tue, 18 Oct 94 18:55:57 PDT Received: from inet-gw-2.pa.dec.com ([16.1.0.23]) by Sun.COM (sun-barr.Sun.COM) id AA11476; Tue, 18 Oct 94 18:55:55 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA19728; Tue, 18 Oct 94 18:51:30 -0700 Received: by xirtlu.zk3.dec.com; id AA28625; Tue, 18 Oct 1994 21:51:26 -0400 Message-Id: <9410190151.AA28625@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 18 Oct 94 13:29:12 PDT." <199410182029.NAA09758@lager.cisco.com> Date: Tue, 18 Oct 94 21:51:20 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Suppose that your workstation is attached to the worldwide ATM cloud. >According to your model(s), one of the following is true: >a) your host has knowledge of every subnet on the ATM cloud >b) your host has knowledge of its subnet and can find other subnets > without the use of routers Neither applies in my model. >In our model >c) your host has knowledge of its address and can get link layer > information from a server, and >d) if there are no servers and its a broadcast medium, you can > broadcast My model is that hosts have knowledge of subnets they are directly attached too. For this reason when the hosts in my model send packets they have no need of servers or broadcast. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 19:31:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10089; Tue, 18 Oct 94 19:31:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10083; Tue, 18 Oct 94 19:30:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28953; Tue, 18 Oct 94 19:26:46 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA16321; Tue, 18 Oct 94 19:26:45 PDT Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA08944; Tue, 18 Oct 1994 22:26:40 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA20459; Tue, 18 Oct 1994 22:26:40 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA10044; Tue, 18 Oct 1994 22:03:16 -0400 Message-Id: <9410190203.AA10044@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, jhalpern@Newbridge.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 18 Oct 94 19:15:26 +0500." <9410182315.AA03456@lobster.Newbridge.COM> Date: Tue, 18 Oct 94 22:03:16 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM .... 2) There is the possibility of direct communication between things which do not have a common subnet. Contrary to Alex's assertion, this does not represent NON-SENSE or BAD CONFIGURATION. In a large NBMA it is VERY desirable to allow this without informing the host of what subnets are directly reachable. Joel, I would like to understand better the reasons behind "VERY desirable" in relation with NBMA. Dave Katz mentioned a similar argument in an earlier mail, and someone asked for more details, but I didn't see them yet. Would you please elaborate, if you could? Thanks. ... The host behavior to permit this is for the hosts to consider the masks it learns as inclusive information, not exclusive. The host should be prepared to accept re-direction from the router, since the router presumably has a better understanding of the topology and communication paths than the host does. It makes sense to require hosts to correctly handle all 'redirects'. These would include also those redirects that inform a host that a particular remote host is better reached through one of the host's interfaces (host's IPv6 addresses) than the router. These two behaviors are not contradictory. There is no need to restrict ourselves away from the second behavior, and many reasons to allow it. Although philosophycally I think it is better to have more options than fewer, I also know that practically, it is easier to achieve "robustness" being conservative than liberal. There is no debate that hosts SHOULD NOT be concerned with 'global topology'. SHOULD NOT is relaxed enough to allow those cases in which it is useful in a host to know 'global topology'. In that context, using redirects for improving the routes is absolutely reasonable, and desirable. In the context of your message which implied to me "peace", you mention 'many reasons', and I understand that in reference to why the 'redirection' mechanism should be used instead of hosts' knowledge of 'local topology', i.e. hosts on the same link. Many recent messages elaborated on why hosts SHOULD know about 'local topology'. With no wish to deviate from the "peace" context, I would appreciate if you would elaborate on the 'many reasons' why they SHOULD NOT. Thanks, Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 20:20:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10142; Tue, 18 Oct 94 20:20:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10136; Tue, 18 Oct 94 20:19:55 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01183; Tue, 18 Oct 94 20:15:46 PDT Received: from inet-gw-2.pa.dec.com ([16.1.0.23]) by Sun.COM (sun-barr.Sun.COM) id AA21684; Tue, 18 Oct 94 20:15:46 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA23492; Tue, 18 Oct 94 20:11:16 -0700 Received: by xirtlu.zk3.dec.com; id AA29487; Tue, 18 Oct 1994 23:11:12 -0400 Message-Id: <9410190311.AA29487@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 18 Oct 94 10:34:35 +0500." <9410181434.AA03018@lobster.Newbridge.COM> Date: Tue, 18 Oct 94 23:11:05 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Jim Bound gives a nice enumeration of cases, and conclusions. >The key element I disagree with is "hosts knowing their prefix and >using that knowledge". Well thats OK but as another asked you I would like to see your enumeration why its not a good idea? >One suggestion I have heard is that routers be permitted, but not required, >to advertise prefixes. This is a fine and useful thing. Its been in Simpsons drafts for a long time so I think its more than a suggestion. I think its OK too. >If routers are advertising prefixes, hosts clearly should use such >information. However, such usage should be inclusive, not exclusive. >That is, it is desirable for the host to "know" that things in that >prefix are on the same wire. I am confused. In your first two sentences in the mail above you say you disagree with the hosts knowing the prefix and using that knowledge. Here you say its desirable for the host to "know" that things in that prefix are on the same wire. That is what I am saying too??????? Why did you disagree with me in the begining of this mail???? >However, the host should not "know" that >things outside the prefix are not on the same wire. I agree if its not attached to any interface where I am on that subnet. I think on this we are in violent agreement. But we need to bring in the concept of subnet into that discussion. >If a host gets a >redirect to an IPv6/MAC address pair, it should use that without regard >to whether it matches a prefix the host knows about. (Note that the >policy on whether to send such a redirection is a local matter, to allow >the strict separation that some people want.) This is where we do not agree and you have outstanding mail on this question from previous discussion so I will hold off respondiing. >I believe that this allows the efficiency of prefix use without putting >"smarts" in the host which get in the way of routing flexibility, >particularly as it relates to large NBMA networks. We are not talking about routing flexibility. We all agree on that. What we are talking about is sending to other hosts who are not attached to a subnet I am not a member of and I believe this is a bad thing to do. It interferes with the princpals of robustness and begs the question of why the interface is not a member of the subnet in the first place which I did not get into but others have. Please define in detail how this relates to NBMA networks? Its not clear to me it applies. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 18 23:28:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10188; Tue, 18 Oct 94 23:28:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10182; Tue, 18 Oct 94 23:28:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09160; Tue, 18 Oct 94 23:24:11 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA07143; Tue, 18 Oct 94 23:24:11 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA15673; Tue, 18 Oct 1994 23:24:10 -0700 Date: Tue, 18 Oct 1994 23:24:10 -0700 From: Tony Li Message-Id: <199410190624.XAA15673@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Andy Davis's message of Tue, 18 Oct 94 14:36:26 +0100 <25030.9410181336@raft.spider.co.uk> Subject: (IPng) IPv6 Terminology - Cluster Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The concept of a Cluster Address is certainly one which has me baffled, because it is an artefact for which I cannot imagine a use. The name is misleading, because I might expect a packet sent to the cluster address to be delivered to ALL the nodes in that cluster - the suggestion of "boundary address" might be an improvement; deliver the packet to the "boundary"? But why? Please can someone enlighten me? We're about to have this discussion over on the SDRP mailing list... One of the possible applications is that a cluster is one hop along a source route. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 01:29:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10243; Wed, 19 Oct 94 01:29:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10237; Wed, 19 Oct 94 01:29:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13514; Wed, 19 Oct 94 01:24:57 PDT Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA19256; Wed, 19 Oct 94 01:22:07 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 19 Oct 94 17:14:36 +0900 From: Masataka Ohta Message-Id: <9410190814.AA04527@necom830.cc.titech.ac.jp> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Wed, 19 Oct 94 17:14:34 JST In-Reply-To: <9410180451.AA03750@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at Oct 18, 94 12:50 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Host A on Link Z > Interface 'a' has prefix 1111 for subnet S1 as part of its address. > Interface 'a' has prefix 1110 for subnet S2 as part of its address. > Interface 'b' has prefix 1110 for subnet S2 as part of its address. > > Host B on Link Z > Interface 'c' has prefix 1111 for subnet S1 as part of its address. > Interface 'd' has prefix 1110 for subnet S2 as part of its address. > > Host C on Link Z > Interface 'e' has prefix 1111 for subnet S1 as part of its address. I think it a configuration error and the correct situation should be: Host A on Link Z Interface 'a' has prefixes 1111 and 1110 for subnet S1 as part of its address. Interface 'b' has prefix 1100 for subnet S2 as part of its address. Host B on Link Z Interface 'c' has prefixes 1111 and 1110 for subnet S1 as part of its address. Interface 'd' has prefix 1100 for subnet S2 as part of its address. Host C on Link Z Interface 'e' has prefixes 1111 and 1110 for subnet S1 as part of its address. Moreover, there are no reason that the host A and B has interfaces 'b' and 'd'. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 06:24:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10426; Wed, 19 Oct 94 06:24:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10420; Wed, 19 Oct 94 06:23:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23926; Wed, 19 Oct 94 06:19:41 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA14464; Wed, 19 Oct 94 06:19:32 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA17802; Wed, 19 Oct 1994 09:19:30 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA25393; Wed, 19 Oct 1994 09:19:30 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA13058; Wed, 19 Oct 94 09:19:28 EDT Message-Id: <9410191319.AA13058@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: dkatz@cisco.com Subject: Re: (IPng) Host prefix knowledge In-Reply-To: Your message of "Tue, 18 Oct 1994 15:46:17 PDT." <199410182246.PAA00451@feta.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Wed, 19 Oct 1994 09:19:28 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave Katz says: > From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) > > Currently the laptop only allows me to use one interface at a time, but I > think this will soon change. It will need to decide which one to use > independent of a router. > > Why independently? I don't know what Bob's motives might be, but on a network that I deal with there might be several very good motives. The most important to me is failure handling. In case of failure, it would be necessary to use the other interface -- a failure of the network media, the interface, or a router should all swiftly bring about this consequence. Any IPng that makes this impossible is totally unacceptable to me because I not only have networks right now that do this but my clients DEPEND on having networks that can rapidly fix themselves this way. Seconds count. Of course, merely being able to select the optimal interface might be sufficient motive. > Servers are also commonly connected to many interfaces. The server needs > to choose the correct interface to talk to it's clients without the > traffic going through a router. For example a multi-homed file server > wants to talk to its clients on it's directly connected subnets directly > without through or consulting a router. > > I don't think the file server particularly cares whether it consults a router > first or not. I was going to give you a real life example from my work, but hell, lets be mundane -- if I have a simple multi-homed file server connected to a network that becomes isolated because of router failure, I want the hosts on that net to keep getting their files from the server. I get this stuff to work right now, today. Break it and I'll never support your IPng. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 06:33:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10438; Wed, 19 Oct 94 06:33:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10432; Wed, 19 Oct 94 06:33:35 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24641; Wed, 19 Oct 94 06:29:26 PDT Received: from watson.ibm.com ([129.34.139.4]) by Sun.COM (sun-barr.Sun.COM) id AB15528; Wed, 19 Oct 94 06:29:25 PDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3937; Wed, 19 Oct 94 09:29:31 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 3945; Wed, 19 Oct 1994 09:29:31 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Wed, 19 Oct 94 09:29:29 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA31905; Wed, 19 Oct 1994 09:29:22 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9410191329.AA31905@hawpub1.watson.ibm.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Subnets Again ... In-Reply-To: (Your message of Tue, 18 Oct 94 21:51:20 D.) <9410190151.AA28625@xirtlu.zk3.dec.com> Date: Wed, 19 Oct 94 09:29:21 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The entities defined for IPv4 mobility may eventually perform redirects or not, without consideration of the normal IPv4 subnet model. For instance, a router on a mobile node's physical Home Network should not normally send a redirect for the mobile node to any host resident on the Home Network, when the mobile node is gone. Also, suppose that two mobile nodes from different Home Networks are visiting the same foreign agent. They will have different subnet prefixes. It is possible to imagine (this will be described in the upcoming route optimization draft for IPv4) that the foreign agent could send a redirect to a visiting mobile nodes if that mobile node is sending data to another mobile node visiting at the same foreign agent. Doing this requires extra care in several ways, especially using wireless links with limited range, but at least it's possible and doesn't match well with the current IPv4 subnet model. Wireless nodes are going to have to be careful in using ARP. I'm in favor of _allowing_ hosts to know their subnet prefixes, and _allowing_ them to ARP, but also allowing them to be blissfully unaware, by allowing them to get local redirects from their default routers (for _all_ "local" subnets regardless of prefix matching!). This can be done interoperably. By managing their routers appropriately, people can get the results they want. Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 06:39:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10462; Wed, 19 Oct 94 06:39:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10456; Wed, 19 Oct 94 06:39:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25117; Wed, 19 Oct 94 06:35:36 PDT Received: from nbkanata.Newbridge.COM ([192.75.23.5]) by Sun.COM (sun-barr.Sun.COM) id AA16274; Wed, 19 Oct 94 06:35:33 PDT Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA22511; Wed, 19 Oct 94 09:30:20 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA24779; Wed, 19 Oct 94 09:30:18 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA18690; Wed, 19 Oct 94 09:36:07 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA03621; Wed, 19 Oct 1994 09:36:06 +0500 Date: Wed, 19 Oct 1994 09:36:06 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9410191336.AA03621@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP X-Sun-Charset: US-ASCII Content-Length: 3921 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Several people have asked for elaboration on my assertion that there is utility in allowing arbitrary redirection of hosts. The argument can be made on the grounds of generality. That is, we do not know all the topologies that we want to work with, and allowing flexibility is good. One could even sight the old Internet dogma: "Be restrictive in what one sends, and generous in what one accepts", since what I am asking for is "generousity" on the part of the host in accepting re-direction. However, that is all platitude, and the request was for concrete examples. Since I want to avoid fighting about ATM, I will use Frame relay with SVCs. For reference, SVCs have not been deployed with frame relay, in large part because nobody can see an advantage, given current usage. The key assumption in the following is that switching (cell, packet, ...) is faster than routing. Thus, a direct switched path is "preferred". While there are people who disagree with this, I think it is safe to assert that it might well be true. And if it is ... Assume a large frame relay network with SVCs. Assume further that each company has a "LIS" in the SMDS/ATM sense on this network. This LIS may be build using SVCs, PVCs, or a combination thereof. If one assumes an address resolution technique within the LIS, then the routers could "advertise" a prefix for that LIS. And all the attached devices (hosts, routers, ...) could use that to find other things in the LIS. The LIS's will be interconnected with a fabric of IP routers (this is not the only way to do it, but it is one way). These are normal routers forming a connected IP overlay. Now, when a frame relay attached host from company A wishes to talk to a frame relay attached host from company B, what happens. If we do nothing, the packets will go over several sets of frame relay circuits and through several routers. However, if we assume that there is a technique for the first router to determine the correct path accross the fabric, it would be useful if it could re-direct the originating host to communicate with some other entity. (Note, this could be the target host, or a firewall router, depending on policy.) This kind of redirection is what the ROLC working group is trying to define. However, the largest roadblock to actually deploying a ROLC solution is that the host, running IPv4, refuses to accept the information. Even if the redirect had a MAC address, the host will ignore it. With IPv6, we have already said that the redirect will carry a MAC address. That is part one. However, what this requires is simply that the host accept the re-direct even if it does not match any address/mask pair for the host. One person suggested that the host should have an address in all subnets it participates in. Clearly, this is impractical when dealing with a large NBMA. It then follows that there is no useful mask to send the host, since he has nothing to match it with. To get into a more controversial example, one can imagine an ethernet with multiple subnets on it. These subnets exist not to force traffic through a firewall, but as an administrative convenience. If arbitrary redirection is allowed, a site administrator could choose to keep different groups separate this way, even on the same wire. The host (auto)configuration would assign the correct address to each host. However, direct communication is clearly still desired. Yes, it can be argued that this is an irrelevant nicety. But allowing customers administrative flexibility is a useful thing. In summary, while the Mask and match paradigm is useful, it is not the be all and end all. [There are even those who argue that it is a useles paradigm. I am not going that far.] Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS This is a separate matter from the selection of exit interfaces for multi-homed hosts. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 06:58:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10491; Wed, 19 Oct 94 06:58:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10485; Wed, 19 Oct 94 06:58:16 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26241; Wed, 19 Oct 94 06:54:07 PDT Received: from wintermute.imsi.com ([192.103.3.10]) by Sun.COM (sun-barr.Sun.COM) id AA18234; Wed, 19 Oct 94 06:54:06 PDT Received: from relay.imsi.com by wintermute.imsi.com id JAA17967 for ; Wed, 19 Oct 1994 09:54:05 -0400 Received: from snark.imsi.com by relay.imsi.com id JAA25633 for ; Wed, 19 Oct 1994 09:54:04 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA13130; Wed, 19 Oct 94 09:54:03 EDT Message-Id: <9410191354.AA13130@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Host prefix knowledge In-Reply-To: Your message of "Tue, 18 Oct 1994 12:31:30 PDT." <199410181931.MAA03634@lager.cisco.com> X-Reposting-Policy: redistribute only with permission Date: Wed, 19 Oct 1994 09:54:02 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Tony Li says: > The issue is that the router does not know what interfaces the host has. > It can not tell the host which interface to use. The host needs to > determine this itself. The only alternative I see is to turn all > multi-homed hosts into full fledged routers. This seems undesirable to > me. > > The host can certainly determine this, but it should not have stable > state about this information. If the host queries the routers on each > interface as to the optimal path, then it has a simple soft state > solution. I don't understand what you mean here. Are you implying that the host should query the routers each and every time? And what about the case where the router on one of the LANs dies and you still want the network to keep functioning? I have mission critical market data systems that work fine in the face of such failures today; an IPv6 that does not work in the face of such failures is totally unacceptable to me. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 07:03:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10503; Wed, 19 Oct 94 07:03:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10497; Wed, 19 Oct 94 07:02:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26422; Wed, 19 Oct 94 06:58:47 PDT Received: from necom830.cc.titech.ac.jp ([131.112.32.132]) by Sun.COM (sun-barr.Sun.COM) id AA18767; Wed, 19 Oct 94 06:58:37 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 19 Oct 94 22:51:20 +0900 From: Masataka Ohta Message-Id: <9410191351.AA06231@necom830.cc.titech.ac.jp> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Wed, 19 Oct 94 22:51:18 JST In-Reply-To: <9410191336.AA03621@lobster.Newbridge.COM>; from "Joel Halpern" at Oct 19, 94 9:36 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joel; > Assume a large frame relay network with SVCs. Assume further that each > company has a "LIS" in the SMDS/ATM sense on this network. Please don't assume non-broadcast link layer where autoconfiguration is impossible. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 08:11:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10611; Wed, 19 Oct 94 08:11:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10605; Wed, 19 Oct 94 08:11:13 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00697; Wed, 19 Oct 94 08:07:03 PDT Received: from inet-gw-1.pa.dec.com ([16.1.0.22]) by Sun.COM (sun-barr.Sun.COM) id AA28551; Wed, 19 Oct 94 08:06:54 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA05782; Wed, 19 Oct 94 07:57:23 -0700 Received: by xirtlu.zk3.dec.com; id AA12790; Wed, 19 Oct 1994 10:57:19 -0400 Message-Id: <9410191457.AA12790@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Wed, 19 Oct 94 09:36:06 +0500." <9410191336.AA03621@lobster.Newbridge.COM> Date: Wed, 19 Oct 94 10:57:12 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joel, I now understand your model thank you. The problem is new and I can see the problem (at least new to me as I don't work in the space your referencing). I think this problem can be solved in one of two ways with out doing the all subnets model. But first let me say something that "may" apply to most hosts. The cache check for media address is done after a match in the ip layer to determine if the host is sending direct or to a router. This is the layering principal many follow and we should not get into this one as it will take us off the deep end of this subject so lets not. So the first way is to bypass the layering model and I don't think that is a good idea because finding a mechanism to tell me that would complicate things greatly I think. Now lets see if we can add something that will solve this problem. Lets say we define a new discovery message to IPv6 called "push-advertisement" redirect. Here is what it would do: The push-advertisement redirect is defined by a TBD bit in an IPv6 system discovery packet. When a host sees this redirect and the push-advertisement bit is ON, then that host caches that address/MAC (for lack of better word for now) pair in its media address cache resolution. The host SHOULD (I say this on purpose to not make it mandatory) then because the push-advertisment bit is ON move that address into its network layer routing table as another entry where the check is done for direct to one of its subnets or to a known router. WIth the above if an application now sends a packet to an address which has been brought into the routing table per the push-advertisement redirect. Here is what could happen at the ipv6 layer: 1. Check to see if the address is one of its subnets if so send direct to one of the hosts subnets. 2. During the check to locate the router to use if there is a match to the address then send to that address. This will cause the ipv6 layer to process the destination address just like a direct connection and enter the media resolution cache and then it will send to the MAC address in that cache that was provided by the push-advertisement redirect. This will permit nodes to redirect hosts in your model to send the packets where they can be more efficiently moved across the SVC or PVC depending on that link layer technology (and I would like to make that transparent as this could be useful to other scenarios too). The cost to the host will be an extra search at the ipv6 layer. This should be analyzed as to the costs from a few host vendors. Just for a sanity check OK. This also changes the existing IPv4 model in an architectural way where now a host can send directly to a node that is not part of any of its subnets, and the destination may or may not be a router or some other type of node TBD. I would like to hear the cons of changing the model and need time to think on this myself. Is that fair? Does this help? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 08:47:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10623; Wed, 19 Oct 94 08:47:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10617; Wed, 19 Oct 94 08:47:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04081; Wed, 19 Oct 94 08:43:42 PDT Received: from nbkanata.Newbridge.COM ([192.75.23.5]) by Sun.COM (sun-barr.Sun.COM) id AB05929; Wed, 19 Oct 94 08:43:40 PDT Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA25480; Wed, 19 Oct 94 11:38:29 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA00825; Wed, 19 Oct 94 11:38:29 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA19732; Wed, 19 Oct 94 11:44:18 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA03694; Wed, 19 Oct 1994 11:44:17 +0500 Date: Wed, 19 Oct 1994 11:44:17 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9410191544.AA03694@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP X-Sun-Charset: US-ASCII Content-Length: 642 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim Bound suggested a new advertisement with a "push bit" to tell the host it should accept this advertisement for a host it does not have a mask/match with. This leaves me confused. Why do we need a new advertisement to do this. Under what circumstance should a host NOT use the information? I can understand that one might not always send the information, but I do not follow why a host needs to differentiate for receiving it. (And yes, this does minor violence to the local/router logic. Frankly, that logic is exactly what I am trying to relax/change.) Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 10:39:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10832; Wed, 19 Oct 94 10:39:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10826; Wed, 19 Oct 94 10:39:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17647; Wed, 19 Oct 94 10:34:50 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA00510; Wed, 19 Oct 94 10:34:19 PDT Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA15497; Wed, 19 Oct 1994 13:30:33 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA03335; Wed, 19 Oct 1994 13:30:26 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA10593; Wed, 19 Oct 1994 13:07:01 -0400 Message-Id: <9410191707.AA10593@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, bound@zk3.dec.com, andy@spider.co.uk Subject: Re: (IPng) IPv6 Terminology - Cluster Address In-Reply-To: Your message of "Tue, 18 Oct 94 14:36:26 BST." <25030.9410181336@raft.spider.co.uk> Date: Wed, 19 Oct 94 13:07:01 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The concept of a Cluster Address is certainly one which has me baffled, because it is an artefact for which I cannot imagine a use. The name is misleading, because I might expect a packet sent to the cluster address to be delivered to ALL the nodes in that cluster - the suggestion of "boundary address" might be an improvement; deliver the packet to the "boundary"? But why? Please can someone enlighten me? Andy The "cluster address" may mislead as you said. The name should be closer to what it means, in that respect so far there were no better suggestions than 'boundary address'. Perhaps "boundary router address", or "boundary router identifier"? Oh well... Alex ----------------------------------------------------------------------------- ***- IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/ ***pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 11:52:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10959; Wed, 19 Oct 94 11:52:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10953; Wed, 19 Oct 94 11:51:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24817; Wed, 19 Oct 94 11:47:44 PDT Received: from lobster.wellfleet.com ([192.32.253.3]) by Sun.COM (sun-barr.Sun.COM) id AB13138; Wed, 19 Oct 94 11:45:07 PDT Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13128; Wed, 19 Oct 94 14:37:54 EDT Received: from andover.wellfleet by wellfleet (4.1/SMI-4.1) id AA10055; Wed, 19 Oct 94 14:37:25 EDT Date: Wed, 19 Oct 94 14:37:25 EDT From: dimitry_haskin@wellfleet.com (Dimitry Haskin) Message-Id: <9410191837.AA10055@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I believe that redirection from a router to a "shortcut" route regardless of subnet boundaries is a very useful feature. I also realize that some nodes may not want some/all packet flows that they originate to be re-directed. Furthermore, some nodes may agree to be redirected to another router but not to a destination host. Sending redirects to such nodes is a waist of resources. Since I don't think it is reasonable to ask to configure a router to send or not to send re-directs for specific flows, I'd like to suggest that there should be an indication in IPv6 packets (the Hop-by-Hop Options header comes to mind) whether re-direction is desired (I guess default should be no redirection). Dimitry Haskin ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 13:49:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11347; Wed, 19 Oct 94 13:49:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11328; Wed, 19 Oct 94 13:49:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07043; Wed, 19 Oct 94 13:45:13 PDT Received: from lager.cisco.com ([131.108.11.55]) by Sun.COM (sun-barr.Sun.COM) id AA02035; Wed, 19 Oct 94 13:41:52 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA04530; Wed, 19 Oct 1994 13:38:53 -0700 Date: Wed, 19 Oct 1994 13:38:53 -0700 From: Tony Li Message-Id: <199410192038.NAA04530@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: "Perry E. Metzger"'s message of Wed, 19 Oct 1994 09:54:02 -0400 <9410191354.AA13130@snark.imsi.com> Subject: (IPng) Host prefix knowledge Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The host can certainly determine this, but it should not have stable > state about this information. If the host queries the routers on each > interface as to the optimal path, then it has a simple soft state > solution. I don't understand what you mean here. Are you implying that the host should query the routers each and every time? No, of course not. There should be a query which can be cached for a known lifetime. Note that this is far more dynamic than learning prefixes either via manual or autoconfiguration. And what about the case where the router on one of the LANs dies and you still want the network to keep functioning? What about it? This does not affect basic router discovery techniques. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 14:07:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11533; Wed, 19 Oct 94 14:07:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11527; Wed, 19 Oct 94 14:07:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08607; Wed, 19 Oct 94 14:03:20 PDT Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA05691; Wed, 19 Oct 94 14:03:09 PDT Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA06147; Wed, 19 Oct 1994 17:00:13 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA05966; Wed, 19 Oct 1994 17:00:07 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA10904; Wed, 19 Oct 1994 16:36:37 -0400 Message-Id: <9410192036.AA10904@brigit.zk3.dec.com> To: jhalpern@Newbridge.COM Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Wed, 19 Oct 94 09:36:06 +0500." <9410191336.AA03621@lobster.Newbridge.COM> Date: Wed, 19 Oct 94 16:36:36 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Several people have asked for elaboration on my assertion that there is utility in allowing arbitrary redirection of hosts. ... However, that is all platitude, and the request was for concrete examples. Since I want to avoid fighting about ATM, I will use Frame relay with SVCs. For reference, SVCs have not been deployed with frame relay, in large part because nobody can see an advantage, given current usage. For fair comparison, I wish your example discussed a case in which there is a lot more practical experience. ... Now, when a frame relay attached host from company A wishes to talk to a frame relay attached host from company B, what happens. If we do nothing, the packets will go over several sets of frame relay circuits and through several routers. However, if we assume that there is a ... Your explanation is valuable. Thanks. However, the largest roadblock to actually deploying a ROLC solution is that the host, running IPv4, refuses to accept the information. Even if the redirect had a MAC address, the host will ignore it. With IPv6, we have already said that the redirect will carry a MAC address. That is part one. However, what this requires is simply that the host accept the re-direct even if it does not match any address/mask pair for the host. I understand the IPv4 redirects are not accepted because the gateway address specified is not reachable, and that you would fear that the same would happen with a redirect in IPv6 if the same model is followed. Am I correct? If that is the case, why is the redirect message not specifying one of the hosts IP addresses to the link? The router could get that from the packet, isn't it? One person suggested that the host should have an address in all subnets it participates in. I said that - others perhaps too - and will elaborate more on it. Clearly, this is impractical when dealing with a large NBMA. Is it the number of subnets a host would be part of? IPv6 does not limit that. What makes it impractical? Please elaborate if you would? It then follows that there is no useful mask to send the host, since he has nothing to match it with. I am not sure that is the case. In a provider based address plan, as I understand it, if two hosts are directly connected in some way, then they share an identical prefix in their IPv6 addresses. Certainly how much is identical depends on the granularity of the address. Given that there is always a way to bring those two hosts to a common prefix, it is so simple to let a host know how many bits from its address to consider as a prefix, in deciding where to send a packet. To get into a more controversial example, one can imagine an ethernet with multiple subnets on it. These subnets exist not to force traffic through a firewall, but as an administrative convenience. If arbitrary redirection is allowed, a site administrator could choose to keep different groups separate this way, even on the same wire. The host (auto)configuration would assign the correct address to each host. However, direct communication is clearly still desired. Yes, it can be argued that this is an irrelevant nicety. But allowing customers administrative flexibility is a useful thing. Although this may be controversial, as your frame relay may be, I do not think it should be an interdiction if one wants to do it that way. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 19 18:23:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14729; Wed, 19 Oct 94 18:23:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14723; Wed, 19 Oct 94 18:23:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03565; Wed, 19 Oct 94 18:19:41 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA01255; Wed, 19 Oct 94 18:19:39 PDT Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16081; Wed, 19 Oct 1994 21:02:19 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA14698; Wed, 19 Oct 1994 21:02:17 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA11099; Wed, 19 Oct 1994 20:38:52 -0400 Message-Id: <9410200038.AA11099@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: jhalpern@Newbridge.COM, conta@zk3.dec.com Subject: Re: links superset of Internet? was Subnets Again was Re: (IPng) In-Reply-To: Your message of "Wed, 19 Oct 94 17:13:19 +0500." <9410192113.AA03826@lobster.Newbridge.COM> Date: Wed, 19 Oct 94 20:38:52 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joel writes: Alex Conta followed up on my note with: > If that is the case, why is the redirect message not specifying one of the > hosts IP addresses to the link? The router could get that from the packet, > isn't it? I am not sure what "host IP address on the link" is. The situation is one where there is no prefix which is restricted to the common media and shared between the two hosts. The IPv4 redirect contains the field "gateway address". What is that field filled in with when hosts drop the IPv5 redirect? It could/should be filled in with an IP address that is reachable by the host, and so the host will not drop the 'redirect'. > One person suggested that the host should have an address in all subnets > it participates in. > > I said that - others perhaps too - and will elaborate more on it. > > Clearly, this is impractical when dealing with a large NBMA. > > Is it the number of subnets a host would be part of? IPv6 does not limit > that. What makes it impractical? Please elaborate if you would? It is impractical because there would be thousands of subnets on the "common" media. Is it understood that 'redirects' create in a host the same structure as 'subnet' knowledge, with the difference, that a subnet structure is valid for more than one host, while for 'redirects', there is one structure per host? Let's assume 1000 subnets. Are you aware that: - with the 'redirect' model, if a host speaks to 2 hosts on each of the subnets, the host will receive 2*1000 redirects and will create 2*1000 'redirect' entries in the route cache? For 'N' hosts in each subnet, there will be N*1000 redirects, and N*1000 'redirect' entries in the route cache? - with the 'subnet' model, the host will receive fewer than 1000 advertisments - because one advertisment may contain information about many subnets - and it will create 1000 entries in the route cache? Regardless of the number of hosts it talks to on each subnet, 2, or N? Many different IP service providers may even be connected by the underlying media switches. Thus, even the provider part is not "common". Aha, so you would like to use 'redirects' even when the "virtual link" spans many "real links", and many providers IPv6 address spaces, as you would rely on the switches at link layer to make the "virtual link" look like one link. Hm... A host can reach a destination directly on a "virtual link" and that cannot be encoded in the IPv6 address!?!. Do we have a problem with the IPv6 address plan then? Considering the model with which most of us are used to, which is that the Internet is a superset of all the links a host is directly connected to, than the 'virtual link' brakes that model. Well this deserves at least some discussion in the IPv6 specs, if not a revisiting of the IPv6 address plan. We all know the old model worked well, so according to don't fix what is not broken, I think the 'virtually' direct reachability of a host should be encodable in the IPv6 address, and if today it is not, then I think at this point we have a problem. Comments? We could impose the restriction that a "virtual link" should not span two completely different IPv6 address spaces. Do we want that? (Also, the provider prefix will refer to a lot of things that are not directly reachable on the "wire", since it is reachable via routers "behind" the wire. The assumption that a prefix implies direct reachability is at best usable only at the bottommost prefix.) Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. This is true, however if two hosts are on a "wire", then their IPv6 addresses should be part of the same cluster at some level, as I use the model, in which the internetwork is a superset of any link that a host is attached to. Alex -------------------------- Previous message: Joel, Several people have asked for elaboration on my assertion that there is utility in allowing arbitrary redirection of hosts. ... However, that is all platitude, and the request was for concrete examples. Since I want to avoid fighting about ATM, I will use Frame relay with SVCs. For reference, SVCs have not been deployed with frame relay, in large part because nobody can see an advantage, given current usage. For fair comparison, I wish your example discussed a case in which there is a lot more practical experience. ... Now, when a frame relay attached host from company A wishes to talk to a frame relay attached host from company B, what happens. If we do nothing, the packets will go over several sets of frame relay circuits and through several routers. However, if we assume that there is a ... Your explanation is valuable. Thanks. However, the largest roadblock to actually deploying a ROLC solution is that the host, running IPv4, refuses to accept the information. Even if the redirect had a MAC address, the host will ignore it. With IPv6, we have already said that the redirect will carry a MAC address. That is part one. However, what this requires is simply that the host accept the re-direct even if it does not match any address/mask pair for the host. I understand the IPv4 redirects are not accepted because the gateway address specified is not reachable, and that you would fear that the same would happen with a redirect in IPv6 if the same model is followed. Am I correct? If that is the case, why is the redirect message not specifying one of the hosts IP addresses to the link? The router could get that from the packet, isn't it? One person suggested that the host should have an address in all subnets it participates in. I said that - others perhaps too - and will elaborate more on it. Clearly, this is impractical when dealing with a large NBMA. Is it the number of subnets a host would be part of? IPv6 does not limit that. What makes it impractical? Please elaborate if you would? It then follows that there is no useful mask to send the host, since he has nothing to match it with. I am not sure that is the case. In a provider based address plan, as I understand it, if two hosts are directly connected in some way, then they share an identical prefix in their IPv6 addresses. Certainly how much is identical depends on the granularity of the address. Given that there is always a way to bring those two hosts to a common prefix, it is so simple to let a host know how many bits from its address to consider as a prefix, in deciding where to send a packet. To get into a more controversial example, one can imagine an ethernet with multiple subnets on it. These subnets exist not to force traffic through a firewall, but as an administrative convenience. If arbitrary redirection is allowed, a site administrator could choose to keep different groups separate this way, even on the same wire. The host (auto)configuration would assign the correct address to each host. However, direct communication is clearly still desired. Yes, it can be argued that this is an irrelevant nicety. But allowing customers administrative flexibility is a useful thing. Although this may be controversial, as your frame relay may be, I do not think it should be an interdiction if one wants to do it that way. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 04:40:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15064; Thu, 20 Oct 94 04:40:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15058; Thu, 20 Oct 94 04:40:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26534; Thu, 20 Oct 94 04:36:30 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA28434; Thu, 20 Oct 94 04:36:24 PDT Received: by rodan.UU.NET id QQxmks12996; Thu, 20 Oct 1994 07:36:22 -0400 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) fun with ARP Date: Thu, 20 Oct 1994 07:36:22 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM We have an application where one computer is required to have multiple IP addresses (in the same subnet) on the SAME interface. The reasons are somewhat complex, but it boils down to providing multiple implementations of a service using the same machine, and the port number of the service is fixed. We are doing that using BSDI on a PC just fine - you just "ifconfig" a few extra "aliases" and *it just works*." Of course it's the magic of dynamic late binding (as implemented by ARP) which allows us to do this. I would be very upset if IP6 did not provide an equally trivial way to do this. "But why do this horrid thing?" I hear you asking. Well, there are a number of reasons. Processors are sufficiently powerful now that rehoming two service machines into the same box is starting to get to be routine. "Just change the address in DNS!!" you suggest out of blissful naivete. But alas, you can't just change the IP addresses, especially if one of them is a NAMESERVER!!!! More importantly, the number of systems out there which still wire-in IP addresses (not DNS names) is appalling. Not quite as many REQUIRE it as was once the case, but the number of systems whose installation instructions still include examples of putting dotted quads into some critical system config file is terrifying (not to mention it isn't clear how to do anything other than that when configuring a DNS resolver on a client system when we run a secondary for one of customers). So, the ability for one body to hold two brains is actually very important in the operational scheme of things. While we're beating poor ARP senseless, I hope we don't lose these abilities. Yours for bigger and better bugs, -Mike O'Dell ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 05:21:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15081; Thu, 20 Oct 94 05:21:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15075; Thu, 20 Oct 94 05:21:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27487; Thu, 20 Oct 94 05:17:40 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA01313; Thu, 20 Oct 94 05:17:39 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) fun with ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 20 Oct 1994 13:17:14 +0200 (BST) In-Reply-To: from "Mike O'Dell" at Oct 20, 94 07:36:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1158 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > But alas, you can't just change the IP addresses, especially if one of > them is a NAMESERVER!!!! More importantly, the number of systems out > there which still wire-in IP addresses (not DNS names) is appalling. > Not quite as many REQUIRE it as was once the case, but the number of > systems whose installation instructions still include examples of putting > dotted quads into some critical system config file is terrifying (not > to mention it isn't clear how to do anything other than that when > configuring a DNS resolver on a client system when we run a secondary > for one of customers). For IPv4 there are good reasons for never using DNS names - notably anything using DNS names or YP for name resolving can be spoofed much more easily - its been a security issue for some time. Now supposing IPv6 people didn't wire in addresses would you still need to do it. Also nothing prevents the use of multiple addresses/interface without ARP. Conceptually you just happen to have two interfaces on the same cable - two IP one physical. For load balancing people regularly have two physical one conceptual IP interface so what is the issue ? Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 06:28:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15296; Thu, 20 Oct 94 06:28:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15290; Thu, 20 Oct 94 06:28:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00592; Thu, 20 Oct 94 06:23:51 PDT Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA08730; Thu, 20 Oct 94 06:23:42 PDT Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <16302-0@relay1.pipex.net>; Thu, 20 Oct 1994 14:23:11 +0100 Received: by widow.spider.co.uk; Thu, 20 Oct 94 14:25:05 +0100 From: Andy Davis Date: Thu, 20 Oct 94 14:20:18 +0100 Message-Id: <19063.9410201320@raft.spider.co.uk> Received: by raft.spider.co.uk; Thu, 20 Oct 94 14:20:18 +0100 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Terminology - Cluster Address Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In article conta@zk3.dec.com write: |> |> |> The "cluster address" may mislead as you said. The name should be closer |> to what it means, in that respect so far there were no better suggestions |> than 'boundary address'. Perhaps "boundary router address", or |> "boundary router identifier"? Oh well... |> |> Alex |> But the problem with this is that, as I understand the semantics of a cluster address, it does NOT identify a boundary router - so calling it a "boundary router identifier" is bogus. My understanding is that a packet addressed to the cluster address (or indirectly addressing the cluster address, eg in a source route) will "match" whichever boundary router it happens to hit first. If there are multiple paths in the network, then a subsequent packet addressed the same way might well be delivered to a DIFFERENT boundary router. Which behaviour incidently is what makes me doubt the value of the mechanism in a practical network - what protocol can use a semi-random destination address mechanism? In any case, it doesn't address or identify a particular router... Andy (still baffled) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 06:34:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15308; Thu, 20 Oct 94 06:34:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15302; Thu, 20 Oct 94 06:34:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00837; Thu, 20 Oct 94 06:30:32 PDT Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA09579; Thu, 20 Oct 94 06:30:26 PDT Received: by nero.dcrc.com (4.1/1.34) id AA26287; Thu, 20 Oct 94 09:30:02 EDT Date: Thu, 20 Oct 94 09:30:02 EDT From: mad@nero.dcrc.com (Michael A. Davis) Message-Id: <9410201330.AA26287@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: links superset of Internet? was . . . Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I quote two statements by Alex: 1 - We could impose the restriction that a "virtual link" should not span two completely different IPv6 address spaces. Do we want that? 2 - In a provider based address plan, as I understand it, if two hosts are directly connected in some way, then they share an identical prefix in their IPv6 addresses. Certainly how much is identical depends on the granularity of the address. Given that there is always a way to bring those two hosts to a common prefix, it is so simple to let a host know how many bits from its address to consider as a prefix, in deciding where to send a packet. I realize they are from differnt contexts, but they seem on their face to be contradictions. Perhaps I just don't understand what is meant by "two completely different IPv6 address spaces." If two hosts are on a "virtual link," are they not directly connected in the virtual link, therefore "there is always a way to bring those two hosts to a common prefix." If this is the case I'm not sure what the restriction of quotation 1 means. Could someone explain this to me? Thanks. -mad -- - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + Mike Davis + Do not use the return address + + Penril Datability Networks + Use mike@dss.com + + 190 North Main Street +- -- -- -- -- -- -- -- -- -- -- -+ + Natick, MA 01760 + "POST NO BILLS" + - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 07:18:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15345; Thu, 20 Oct 94 07:18:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15339; Thu, 20 Oct 94 07:18:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02831; Thu, 20 Oct 94 07:14:06 PDT Received: from nbkanata.Newbridge.COM by Sun.COM (sun-barr.Sun.COM) id AA15318; Thu, 20 Oct 94 07:14:04 PDT Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA20331; Thu, 20 Oct 94 10:08:52 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA02776; Thu, 20 Oct 94 10:08:48 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA03507; Thu, 20 Oct 94 10:14:38 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA03990; Thu, 20 Oct 1994 10:14:37 +0500 Date: Thu, 20 Oct 1994 10:14:37 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9410201414.AA03990@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: links superset of Internet? was Subnets Again was Re: (IPng) X-Sun-Charset: US-ASCII Content-Length: 2696 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I think that these messages are getting redundant. We appear to be arguing from different premises. I will try again to elucidate the assumptions I am making, and the conclusions. 1) I assume that a host knows its own addresses (and prefixes) for an extended period of time. This is in contrast to a cache entry for the MAC address of a peer host, which it only knows while it is talking to that host, and for a little while afterwards. Alex Conta wrote: > Considering the model with which most of us are used to, which is that the > Internet is a superset of all the links a host is directly connected to, than > the 'virtual link' brakes that model. Well this deserves at least > some discussion in the IPv6 specs, if not a revisiting of the IPv6 address > plan. > We all know the old model worked well, so according to don't fix what is not > broken, I think the 'virtually' direct reachability of a host should be > encodable in the IPv6 address, and if today it is not, then I think at this > point we have a problem. Comments? 2) We have been fighting this problem since the inception of the IPLPDN working group. The current model works badly for Frame Relay even with only PVC, barely works at all for SMDS (and is arguably one of the reasons that SMDS is not practical to use) and would not extend to a large ATM service. This is NOT something which "works with IPv4". It is something that is broken in IPv4 and I was hoping IPv6 could FIX! 3) Imposing a restriction, as Alex suggests, that a "virtual link" should not span two completely different IPv6 address spaces (providers?) is counter-productive. The goal is to allow things to communicate as effectively as possible. Sometimes that is through an intervening router. But if that router is a bottleneck and a source of ineffeciency, and is not needed for policy reasons, then it should be eliminated. 4) The problem is not with the adressing plan. The plan, quite reasonably, allows a site to derive its addresses from a prefix associated with the provider it gets service from. That does not mean that all addresses with that prefix are MAC level reachable on the provider. Prefixes at other than the bottom layer MUST addresses clusters which cross wires. Hence, one can never usefully draw reachability conclusions from such prefixes. (This relates to why prefix advertisements to hosts make me nervous. But as long as the host only treats them as a hint, the routers can be carefully to only advertise prefixes which are useful hints.) Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 08:07:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15387; Thu, 20 Oct 94 08:07:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15381; Thu, 20 Oct 94 08:07:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05909; Thu, 20 Oct 94 08:03:06 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA23478; Thu, 20 Oct 94 08:03:03 PDT Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22481; Thu, 20 Oct 1994 11:02:50 -0400 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA06566; Thu, 20 Oct 1994 11:02:40 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA11293; Thu, 20 Oct 1994 10:39:10 -0400 Message-Id: <9410201439.AA11293@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, mike@dss.com Subject: Re: (IPng) Re: links superset of Internet? was . . . In-Reply-To: Your message of "Thu, 20 Oct 94 09:30:02 EDT." <9410201330.AA26287@nero.dcrc.com> Date: Thu, 20 Oct 94 10:39:10 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM .... I realize they are from differnt contexts, but they seem on their face to be contradictions. Perhaps I just don't understand what is meant by "two completely different IPv6 address spaces." If two hosts are on a "virtual link," are they not directly connected in the virtual link, therefore "there is always a way to bring those two hosts to a common prefix." If this is the case I'm not sure what the restriction of quotation 1 means. Could someone explain this to me? Thanks. -mad - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + Mike Davis + Do not use the return address + + Penril Datability Networks + Use mike@dss.com + + 190 North Main Street +- -- -- -- -- -- -- -- -- -- -- -+ + Natick, MA 01760 + "POST NO BILLS" + - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ============= Apparently with NBMA it is quite possible that two hosts on a "virtual link' will have completely different IPv6 addresses, from right to left, and left to right, which ever you like, i.e. their prefixes will be absolutely different. A simple analogy to this in IPv4 would be on your Ethernet you have two hosts, one with address 1.2.3.4, and the other with address 2.4.8.8., and you want them to talk directly without a router. This is not the way I understood the IPv6 address plan, and my question was is there a problem there, and if it is do we do anything about it? Does this help? Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 10:32:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15590; Thu, 20 Oct 94 10:32:04 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15397; Thu, 20 Oct 94 08:28:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07392; Thu, 20 Oct 94 08:23:50 PDT Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA27250; Thu, 20 Oct 94 08:23:48 PDT Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id LAA05840 for ipng@sunroof.Eng.Sun.COM; Thu, 20 Oct 1994 11:25:05 -0400 (EDT) Date: Thu, 20 Oct 1994 11:25:05 -0400 (EDT) >From: Scott Bradner Message-Id: <199410201525.LAA05840@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: links superset of Internet? was . . . Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > This is not the way I understood the IPv6 address plan, and my question was is there a problem there, and if it is do we do anything about it? Alex, I think the point is that there may be administrative reasons that you want two (or more) seperate networks on the same wire. People have security related reasons to do this sort of thing today and ATM will (someday) bring virtual LANs etc that are in effect the same thing. I don't think you can 'fix' the addressing plan since the aim is seperation unless some higher authority says diferently for a particular data stream. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 13:06:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15816; Thu, 20 Oct 94 13:06:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15810; Thu, 20 Oct 94 13:06:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08923; Thu, 20 Oct 94 13:01:51 PDT Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA26728; Thu, 20 Oct 94 13:01:50 PDT Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id QAA23680; Thu, 20 Oct 1994 16:01:49 -0400 Message-Id: <199410202001.QAA23680@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP In-Reply-To: Your message of "Tue, 18 Oct 1994 19:15:26 EDT." <9410182315.AA03456@lobster.Newbridge.COM> From: Valdis.Kletnieks@vt.edu Date: Thu, 20 Oct 1994 16:01:48 +22306356 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Tue, 18 Oct 1994 19:15:26 EDT, you said: > There was a security concern raised. Clearly there are times when one > does not want hosts communicating directly. If the direct communication > only occurs as a result of re-direction from a router, then if the site > manager does not want it to happen, he configures the routers not to do > that. Joel: Umm.. I have a problem with this. At least for some very popular media, such as ethernet, it is quite possible for anybody to sniff packets - this would allow one node to find and then send directly to another node on the same physical wire but a different logical subnet, without benefit of a router. Absent a rule that says "machines are free to not accept packets from a prefix they dont want to" (which is still subject to prefix spoofing if the source machine really wants to do so), I don't see how regulating the routers helps much here.... Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 13:31:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15840; Thu, 20 Oct 94 13:31:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15834; Thu, 20 Oct 94 13:31:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11562; Thu, 20 Oct 94 13:27:31 PDT Received: from nbkanata.Newbridge.COM by Sun.COM (sun-barr.Sun.COM) id AA03025; Thu, 20 Oct 94 13:27:28 PDT Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA29203; Thu, 20 Oct 94 16:22:15 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA18452; Thu, 20 Oct 94 16:22:12 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA05460; Thu, 20 Oct 94 16:28:00 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA04283; Thu, 20 Oct 1994 16:28:00 +0500 Date: Thu, 20 Oct 1994 16:28:00 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9410202028.AA04283@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Subnets Again was Re: (IPng) Re: ARP X-Sun-Charset: US-ASCII Content-Length: 1108 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Valdis Kletnieks asks about the security concern if a host were to learn of a remote host by snooping, and then send to it. I will observe that there is a little more involved than that. In order to get the un-hacked host to respond, you have to send him a bogus redirect. (However, redirects are notoriously insecure anyway.) In contrast to this, I will observe that since the host snooping and learning from arbitrary packets is already violating the rules, it can easily perform other invalid behaviors. For example, it could probably steal a number in the subnet that is common with the host it wishes to talk to. It could then talk even under the older model. Thus, I think that the increased security risk is negligble. Real security comes through other mechanisms that are being included in IPv6. All I was observing was that for compliant hosts, in sites which want inter-subnet same wire traffic to go through a router, it can go through a router. This does not prevent snooping, but it was not prevented before. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 14:13:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15933; Thu, 20 Oct 94 14:13:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15927; Thu, 20 Oct 94 14:13:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15845; Thu, 20 Oct 94 14:09:29 PDT Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA12867; Thu, 20 Oct 94 14:03:24 PDT Received: by rodan.UU.NET id QQxmmb29587; Thu, 20 Oct 1994 16:23:58 -0400 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) IPv6 Terminology - Cluster Address To: ipng@sunroof.Eng.Sun.COM Date: Thu, 20 Oct 1994 16:23:57 -0400 (EDT) In-Reply-To: <19063.9410201320@raft.spider.co.uk> from "Andy Davis" at Oct 20, 94 02:20:18 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1463 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >But the problem with this is that, as I understand the semantics of a >cluster address, it does NOT identify a boundary router - so calling >it a "boundary router identifier" is bogus. My understanding is that >a packet addressed to the cluster address (or indirectly addressing >the cluster address, eg in a source route) will "match" whichever >boundary router it happens to hit first. Wouldn't it also match "any host" if it was sent from within the cluster it addresses? > If there are multiple paths >in the network, then a subsequent packet addressed the same way might >well be delivered to a DIFFERENT boundary router. Which behaviour >incidently is what makes me doubt the value of the mechanism in a >practical network - what protocol can use a semi-random destination >address mechanism? In any case, it doesn't address or identify a >particular router... When you don't care _where_ inside a routing domain you get, but just that you get there. The uses I have thought (or seen) for them: * Put them in source routes for mobile hosts * Manually route around network problems (one would hope this use would be rare, but I susspect not all failure modes will be automaticly routed around) * Network debugging (routing around parts of a net to see how that effects some failure mode) All three of these could be done with a "normal" address, but cluster addresses might be cleaner. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 17:01:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16189; Thu, 20 Oct 94 17:01:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16183; Thu, 20 Oct 94 17:01:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03529; Thu, 20 Oct 94 16:57:27 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA24561; Thu, 20 Oct 94 16:57:24 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 21 Oct 1994 09:52:30 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 21 Oct 1994 09:56:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 21 Oct 1994 09:58:17 +1000 Date: Fri, 21 Oct 1994 09:58:17 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941021 11:40:17 032] X400-Content-Type: P2-1984 (2) Content-Identifier: 941021 11:40:17 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941021 11:40:17*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) RE: RE: LINKS SUPERSET OF INTERNET? WAS SUBNETS AGAIN WAS RE: ( Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. re links and subnets.. agree with joel.. Is not the story just one of: IP (and CLNP) is an Internetworking protocol.. its addressing scheme is logically detached from carrier numbering plans and physical links. IP "maps" onto (with magic in some cases) to dependent networks (ATM,X.25) and their numbering plans .. or directly to "links" ATM PVCs, HDLC or MAC.. or IP through the network dependent level maps to the link.. and at the bottom we the physical 1s and 0s.. It follows that through the "magic mapping" that many IP addresses can be directed over the same dependent network connection or over the same link.. Therefore via protocol profiles and mapping one can have many IP subnets on the same physical MAC or just one very small IP subnet blasted across the whole planet... over ATM or tins and string... It seems that the layering Internetworking, Network, Link and Physical functions seem to have been lost in the discussion.. The issue that did surface was the subnet mask processing.. In X.400 routing MTAs now have the ability to use wildcard, OR, or substring equivalence rules for each routing level.. This enables the " = or bust" routing decision to be softened...and better flexibility in network design and administration.. An implementation issue I know but it is worth considering if one wants a 1000 "closely aligned" subnets on the same "wire"... Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 18:16:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16257; Thu, 20 Oct 94 18:16:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16251; Thu, 20 Oct 94 18:16:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09950; Thu, 20 Oct 94 18:11:54 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA09050; Thu, 20 Oct 94 18:11:39 PDT Received: from x400gw.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA05981; Fri, 21 Oct 1994 11:11:00 +1000 (from /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au) From: /G=ALAN/S=LLOYD/O=DCTHQ/P=DATACRAFT/A=TELEMEMO/C=AU/@x400gw.datacraft.com.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA03891; Fri, 21 Oct 94 10:52:01 +1000 Received: by x400gw.datacraft.com.au via Worldtalk with X400 (2.2.0/1.29.1.2) id WT03879; Fri, 21 Oct 1994 10:52:00 EST Date: 21 Oct 94 08:41:30 +1100 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) RE: RE: (IPNG) IPV6 TERMINOLOGY - CLUSTER ADDRESS Ua-Content-Id: 941021 10:28:00 P1-Recipient: ipng@sunroof.eng.sun.com Priority: normal Importance: normal P1-Message-Id: AU*TELEMEMO*DATACRAFT;dcpmel 941021 10:28:00 027 Original-Encoded-Information-Types: IA5-Text X400-Trace: AU*TELEMEMO*DATACRAFT; arrival 941021084130+1100 deferred 941021084130+1100 action Relayed Message-Id: <"941021 10:28:00"*/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@MHS> P1-Content-Type: P2 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday... agree with andy on this one .. hence my comments.. addresses SHOULD only indicate routing characteristics like node, subnet number, area number, domain number, organisation number, country number, etc.. Mobiles.. address forms should be ..terminal number and cell number ditto..I have a problem with the semantics of "providor" and "subscriber" which assigns operational characteristics to a routing scheme.. perhaps Organisation/Region (number), Cluster (number), Node (number) is all that is needed for the fixed Internet addressing and use the term "Cluster/Node" instead of just saying "cluster".. regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 21:13:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16391; Thu, 20 Oct 94 21:13:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16385; Thu, 20 Oct 94 21:13:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16959; Thu, 20 Oct 94 21:09:39 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA28360; Thu, 20 Oct 94 21:09:24 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 21 Oct 94 13:01:39 +0900 From: Masataka Ohta Message-Id: <9410210401.AA16911@necom830.cc.titech.ac.jp> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 21 Oct 94 13:01:38 JST In-Reply-To: <9410202028.AA04283@lobster.Newbridge.COM>; from "Joel Halpern" at Oct 20, 94 4:28 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Valdis Kletnieks asks about the security concern if a host were to > learn of a remote host by snooping, and then send to it. That's a valid concern. > Thus, I think that the increased security risk is negligble. Real > security comes through other mechanisms that are being included in > IPv6. I know you don't like firewalls. But why don't you admit LIS model is firewall hostile? > All I was observing was that for compliant hosts, in sites which > want inter-subnet same wire traffic to go through a router, it can go > through a router. Then, with LIS model, ATM connection is cut on the router and all the merit of ATM disappears. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 20 22:32:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16428; Thu, 20 Oct 94 22:32:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16422; Thu, 20 Oct 94 22:32:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19049; Thu, 20 Oct 94 22:28:09 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA04015; Thu, 20 Oct 94 22:28:05 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA13328; Fri, 21 Oct 94 01:23:42 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410210523.AA13328@pluto.dss.com> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 21 Oct 1994 01:23:39 -0400 (EDT) Cc: martillo@pluto.dss.com (Joachim Martillo) In-Reply-To: <9410210401.AA16911@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Oct 21, 94 01:01:38 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1255 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Then, with LIS model, ATM connection is cut on the router and all > the merit of ATM disappears. > Masataka Ohta Perhaps somewhat orthogonal to the current issue, but I thought ATM was a cell-switching based technology where details of individual paths to various end-points were known to end-hosts which made the fundamental path selection rather than leaving this choice to the comms subnet. As the ATM comms subnet is supposed to be reasonably intelligent, putting the onus of this choice on the end host seems wrong. As data customers (except for a small number of rapidly vanishing exceptional cases) need high performance packet switching and not cell switching, I have to ask what exactly the merit of ATM is and why anyone would worry about this pointless technology in the design of a high performance next generation packet switching technology. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 00:22:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16465; Fri, 21 Oct 94 00:22:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16459; Fri, 21 Oct 94 00:22:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21635; Fri, 21 Oct 94 00:17:51 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA15924; Fri, 21 Oct 94 00:17:43 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 21 Oct 94 16:09:19 +0900 From: Masataka Ohta Message-Id: <9410210709.AA18984@necom830.cc.titech.ac.jp> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 21 Oct 94 16:09:17 JST Cc: martillo@pluto.dss.com In-Reply-To: <9410210523.AA13328@pluto.dss.com>; from "Joachim Martillo" at Oct 21, 94 1:23 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Then, with LIS model, ATM connection is cut on the router and all > > the merit of ATM disappears. > > > Masataka Ohta > > Perhaps somewhat orthogonal to the current issue, Not so much. > but I thought ATM > was a cell-switching based technology where details of individual > paths to various end-points were known to end-hosts which made the > fundamental path selection rather than leaving this choice to the > comms subnet. If ATM is ever useful, transport end-points should be connected through cell-swiches only, which does not mean each end-host must do all the routing. Anyway, putting a firewall router to LIS model destroys everything, which is one of the reason why I developped another model of ATM to have cell-relaying routers. > As the ATM comms subnet is supposed to be reasonably intelligent, I don't think so. > putting the onus of this choice on the end host seems wrong. If source demand routing is the way to go, it's not wrong. Of course, if you use LIS model, you ,perhaps, have to use source demand L3 routing for normal trafic and source demand L2 routing for ATM. Wow! > As data customers (except for a small number of rapidly vanishing > exceptional cases) need high performance packet switching and not cell > switching, I have to ask what exactly the merit of ATM is and why > anyone would worry about this pointless technology in the design of a > high performance next generation packet switching technology. Hardware policable efficient and strict QoS guarantee at the link layer is the merit, I think, though other media in the future may be able to offer the same thing. As I don't like compression, it will be great if I can access 600Mbps video-on-depend at home. So, I don't think ATM is pointless, though I think LIS model of ATM WG is. So, with my model, no one have to worry about ATM in the design of a high performance next generation packet switching technology. Isn't it good enough for you? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 04:27:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16631; Fri, 21 Oct 94 04:27:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16625; Fri, 21 Oct 94 04:27:48 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29784; Fri, 21 Oct 94 04:23:36 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA09973; Fri, 21 Oct 94 04:23:35 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA00981; Fri, 21 Oct 1994 12:26:11 +0100 Message-Id: <199410211126.AA00981@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Terminology - Cluster Address In-Reply-To: Your message of "Thu, 20 Oct 1994 14:20:18 +0100." <19063.9410201320@raft.spider.co.uk> Date: Fri, 21 Oct 1994 12:26:10 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Andy, The "semi-random routing" which has you baffled is the very definition of today's IP service. When you send a packet through the Internet today, you generally do not know where it will go through. Routing tables may change, so that the next packet does not quite follow the same route as the preceeding one. Even if routing tables are stable, routers may do "load splitting" between "equal length routes" - both IGRP and OSPF have provision for that, one could in fact even do it with RIP. There are cases when the user wants to specify the routing. Today, this can be done via source routing mechanism, e.g "go from A to B through C". The problem is that, in many case, source routing through a host may be an overspecification: you want for example to say "use provider X", not "use router Y of provider X". SDRP includes a "routing through an AS" feature that is an example of a response to this problem. Cluster addresses are generalizations of this principle. They are primarily to be used as elements of source routes, to assert that you want to "route through cloud X". The source route will be "progressed" by the first router within cloud X that the packet reaches, effectively a "border of cloud X" since the previous router, by definition, was not a member of that cloud. Usage of cluster addresses within source routes, and the relation with "probe" and 'set up" procedures, should be discussed as part of "SDRP for IPv6". Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 06:29:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16666; Fri, 21 Oct 94 06:29:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16660; Fri, 21 Oct 94 06:29:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03970; Fri, 21 Oct 94 06:25:38 PDT Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA21989; Fri, 21 Oct 94 06:25:20 PDT Received: by pluto.dss.com (4.1/SMI-4.0) id AA03337; Fri, 21 Oct 94 09:21:08 EDT From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9410211321.AA03337@pluto.dss.com> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 21 Oct 1994 09:21:05 -0400 (EDT) Cc: martillo@pluto.dss.com In-Reply-To: <9410210709.AA18984@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Oct 21, 94 04:09:17 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 4597 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > but I thought ATM > > was a cell-switching based technology where details of individual > > paths to various end-points were known to end-hosts which made the > > fundamental path selection rather than leaving this choice to the > > comms subnet. > If ATM is ever useful, transport end-points should be connected > through cell-swiches only, which does not mean each end-host must > do all the routing. I thought the ATM was in the same class of technology with FR and ATM where the end host had to keep a mapping of end host to connection identifier in order to deliver packets to the comms subnet. This model can make sense for connecting hosts to terminals via a communications subnet which is basically presenting its service as a virtualization of synchronous or asynchronous terminal connections. Such is the model of X.25 or FR. > Anyway, putting a firewall router to LIS model destroys everything, I assume you mean because the router does packet switching (what the typical data customer needs) and not cell switching (which is not obviously useful for most data customers). > which is one of the reason why I developped another model of ATM > to have cell-relaying routers. But how do such routers interact with standard packet switching routers? > > As the ATM comms subnet is supposed to be reasonably intelligent, > I don't think so. OK. If you say so. > > putting the onus of this choice on the end host seems wrong. > If source demand routing is the way to go, it's not wrong. But how does this relate to internetworking via ATM? I can envision two hosts trying to communicate where a) 1 host is attached to an ATM comms subnet and the other isn't b) neither is attached to the ATM comms subnet which represents an intermediate hop c) both hosts are attached to different ATM comms subnets. Certainly in case (b) bandwidth requirements cannot be related in any simple way to end-to-end communications bandwidth requirements. In (a) and (b) you may be able to do make more effective use of the ATM communications subnet but only as long as intermediate paths provide bandwidth equal to or greater than the reserved bandwidth at the ATM comms subnet. > Of course, if you use LIS model, you ,perhaps, have to use source > demand L3 routing for normal trafic and source demand L2 routing for > ATM. Wow! > > As data customers (except for a small number of rapidly vanishing > > exceptional cases) need high performance packet switching and not cell > > switching, I have to ask what exactly the merit of ATM is and why > > anyone would worry about this pointless technology in the design of a > > high performance next generation packet switching technology. > > Hardware policable efficient and strict QoS guarantee at the link > layer is the merit, I think, though other media in the future may > be able to offer the same thing. But this is precisely why ATM is pointless. Internet routers throw away packets when they get congested or are you sugesting that the whole internet router model be modified to support to provide hardware policeable, efficient and strict QoS guarantees at the network layer. I think that would be a concession that ATM is not appropriate for current internetworking technology and formalism. Imposing ATM formalism on internetworking technology would then represent bad engineering because IP style internetworking is a proven effective technology while ATM is not. > As I don't like compression, it will be great if I can access 600Mbps > video-on-depend at home. So, I don't think ATM is pointless, though > I think LIS model of ATM WG is. > > So, with my model, no one have to worry about ATM in the design of a > high performance next generation packet switching technology. If there existed a technology which offered infinitely reliable, infinitely cheap infinite bandwidth over infinite distances, obviously we would not need to do internetworking at all. But ATM is not obviously the holy grail of networking technologies. > Isn't it good enough for you? ATM looks a lot like X.25 with the reliability stripped out of the host to switch interconnection. It is not my idea of a dream technology. > Masataka Ohta Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 07:23:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16704; Fri, 21 Oct 94 07:23:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16698; Fri, 21 Oct 94 07:23:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06228; Fri, 21 Oct 94 07:19:30 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA00525; Fri, 21 Oct 94 07:19:26 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 21 Oct 94 23:11:57 +0859 From: Masataka Ohta Message-Id: <9410211412.AA21216@necom830.cc.titech.ac.jp> Subject: Re: Subnets Again was Re: (IPng) Re: ARP To: ipng@sunroof.Eng.Sun.COM Date: Fri, 21 Oct 94 23:11:55 JST Cc: martillo@pluto.dss.com In-Reply-To: <9410211321.AA03337@pluto.dss.com>; from "Joachim Martillo" at Oct 21, 94 9:21 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > but I thought ATM > > > was a cell-switching based technology where details of individual > > > paths to various end-points were known to end-hosts which made the > > > fundamental path selection rather than leaving this choice to the > > > comms subnet. > > > If ATM is ever useful, transport end-points should be connected > > through cell-swiches only, which does not mean each end-host must > > do all the routing. > > I thought the ATM was in the same class of technology with FR and ATM > where the end host had to keep a mapping of end host to connection > identifier in order to deliver packets to the comms subnet. Without well known link layer address for broadcast, you are mostly right, I think. ATM people like to have some server, which takes care of configuration information of other hosts. I don't like the approach because it's fault-intolerant and auto-configuration of configuration server address is, obviously, impossible. > > Anyway, putting a firewall router to LIS model destroys everything, > > I assume you mean because the router does packet switching (what the > typical data customer needs) and not cell switching (which is not > obviously useful for most data customers). Agreed. > > which is one of the reason why I developped another model of ATM > > to have cell-relaying routers. > > But how do such routers interact with standard packet switching > routers? By packet switching (what the typical data customer needs). The cell-relaying router relays packets too. For further information see related Internet Drafts (*-ohta-ip-atm-*, *-ohta-shared-media-*, *-esaki-co-cl-*). > > > As the ATM comms subnet is supposed to be reasonably intelligent, > > > putting the onus of this choice on the end host seems wrong. > > > If source demand routing is the way to go, it's not wrong. > > But how does this relate to internetworking via ATM? Have link-state routing protocol, whose link state includes the information on remaining bandwidth. Choose the best route which satisfy the requirement. > I can envision two hosts trying to communicate where > > a) 1 host is attached to an ATM comms subnet and the other isn't > > b) neither is attached to the ATM comms subnet which represents > an intermediate hop > > c) both hosts are attached to different ATM comms subnets. > > Certainly in case (b) bandwidth requirements cannot be related in any > simple way to end-to-end communications bandwidth requirements. Agreed. So, in cases a) and b), it is wrong to request strict bandwidth requirement. It's like requesting to send data at 200Mbps over a FDDI link. > In (a) and (b) you may be able to do make more effective use of the > ATM communications subnet but only as long as intermediate paths > provide bandwidth equal to or greater than the reserved bandwidth at > the ATM comms subnet. What's wrong with it? > > Hardware policable efficient and strict QoS guarantee at the link > > layer is the merit, I think, though other media in the future may > > be able to offer the same thing. > > But this is precisely why ATM is pointless. Internet routers throw > away packets when they get congested or are you sugesting that the > whole internet router model be modified to support to provide hardware > policeable, efficient and strict QoS guarantees at the network layer. No, though I expect moderate QoS guarantee by almost all the routers, for which purpose flow ID is provided. > I think that would be a concession that ATM is not appropriate for > current internetworking technology and formalism. It is my understanding that flow is the mechanism to support various policies including various QoS types. Just as we can have QoS types of 64Kbps and 45Mbps, we can have "strict 1.5Mbps" and "loose 1.5Mbps". > Imposing ATM formalism on internetworking technology would then > represent bad engineering because IP style internetworking is a proven > effective technology while ATM is not. That's why I don't like LIS model. > > So, with my model, no one have to worry about ATM in the design of a > > high performance next generation packet switching technology. > > If there existed a technology which offered infinitely reliable, > infinitely cheap infinite bandwidth over infinite distances, obviously > we would not need to do internetworking at all. But ATM is not > obviously the holy grail of networking technologies. Agreed completely. As I wrote in my Internett Draft, it's IP, not ATM, which rules the world. So, let's ignore ATM specific issues and design ATM to fit IP. Still, I think we must design flow ID for moderate QoS. And then, if you use properly designed ATM, strict QoS will be available as an option. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 09:21:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16813; Fri, 21 Oct 94 09:21:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16807; Fri, 21 Oct 94 09:21:07 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15443; Fri, 21 Oct 94 09:16:54 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AB24676; Fri, 21 Oct 94 09:16:46 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17278; Fri, 21 Oct 1994 17:16:37 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16580; Fri, 21 Oct 1994 17:16:33 +0100 Message-Id: <9410211616.AA16580@dxcoms.cern.ch> Subject: Smoking guns (was: Re: (IPng) Re: ARP) To: ipng@sunroof.Eng.Sun.COM Date: Fri, 21 Oct 1994 17:16:33 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: jmg@dxcoms.cern.ch (Mike Gerard) In-Reply-To: <9410132025.AA02809@pluto.dss.com> from "Joachim Martillo" at Oct 13, 94 04:25:22 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5505 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IPv6ers, As promised here are some smoking guns concerning ARP and other broad/multicast horrors. Unfortunately Mike Gerard, who kindly put this together, is too busy fixing horrors to extend his list, but he has more. This is FYI, since I was challenged to do it, but I am not suggesting that we enter into further debate. Brian _ _ o | __ | jmg@dxcoms.cern.ch | | | | _ / \ _ __ _ __ _| gerard@cernvm.cern.ch | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. CN, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland Network broadcast and multicast horror stories ============================================== This is a little aide memoire about all sorts of ways that poor network software and clever/stupid users can create broadcast and multicast storms on our CERN general ethernet. The definition of a storm is when the rate of such packets reaches 500 or more per second for at least one second. Note that the CERN network is composed of numerous ethernet and FDDI segments interconnected by MAC-level bridges. It has around 8000 connected systems, almost all of which can run TCP/IP protocols over our Class B network, and many of which can run IPX, DECnet and Ethertalk protocols. However, the vast majority of storms are due to IP. Note also that storms may be due to one particular system repeatedly broadcasting or multicasting, to many systems broadcasting or multicasting in synchronisation due to some particular stimulus, or to a combination of the two. Finally, there are many cases of persistent rain which is not a storm, i.e. a high background level of multicast and broadcast traffic: this is not dealt with here but is nonetheless important to keep under control. ============================================================================ Many TCP/IP systems may send out an individual broadcast from a perfectly legal unix command. In the case where many other systems feel willing to respond then all these other systems have to ARP to find the origin. The process sending this original broadcast may have been written to exit immediately or after treating a single reply, or it may treat all of the replies. In the cases where the process does exit some unix systems will then treat the remaining replies by answering something indicating that the original process (port) is now unavailable. This, of course, implies ARPing everyone who replied! Some of the unix commands involved in the above are rdate, rstat, rusers, ruptime and probably a few more r. There are also such services as the IP "get address mask", to which everyone replies (and we hope that the first answer which arrives is correct). ============================================================================ It is frequent to see broadcasts which "accidentally" are addressed to the IP broadcast address, where they should normally have a specific IP destination address. Sometimes it is something like "ping .255.255", which may be a user having "fun" or part of some network testing program provided by some Unix systems. It is also possible for well-written programs to do this: one Mosaic browser can convert a bad hypertext URL into such an address, whilst one tftp client can switch to a broadcast address if it thinks it is having a problem. In many cases these broadcasts cause havoc. ============================================================================ X-terminals are often set by default to broadcast for any system willing to run xdm for them. One popular make of workstations is by default willing to do so: the X-terminal then gets several hundred replies and offers the user the first one. ============================================================================ Some multi-user games try to interrogate the IP network address by address to find if anyone is already playing. xpilot is the worst that we know (and it comes as standard with some unix systems), but there are others. ============================================================================ Use of Sun's RPC is fraught with danger ever since some systems try to make use of port 111 and version 3 of the portmapper. Most BSD-origin unix systems decide to reply that this version number is illegal, rather than simply ignoring it), which makes for many hundreds of replies (preceded, of course, by ARP broadcasts) here. Some Sun RPC systems then, in turn, ARP for all of the replying systems, which doubles the number of ARP broadcasts. ============================================================================ One particular model of X-terminal (now discontinued) can at any time (normally in the middle of the night when it is not being used) decide to fire off MOP-style multicasts asking to be reloaded. ============================================================================ One make of unix workstation has, by default, software which uses IP multicasts to find out what other like systems there are around. It may go so far as to exchange lots of information, including the list of names of all users as in the passwd file, so as to produce several hundred multicasts per second for seconds. ============================================================================ Multimedia products making use of IP multicast can completely swamp an ethernet. ============================================================================ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 09:54:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16863; Fri, 21 Oct 94 09:54:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16857; Fri, 21 Oct 94 09:54:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19198; Fri, 21 Oct 94 09:50:19 PDT Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA02448; Fri, 21 Oct 94 09:50:17 PDT Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04955; Fri, 21 Oct 94 11:52:24 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA13689; Fri, 21 Oct 94 11:49:59 CDT Date: Fri, 21 Oct 94 11:49:59 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9410211649.AA13689@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Smoking guns (was: Re: (IPng) Re: ARP) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Note that the CERN network is composed of numerous ethernet and FDDI > segments interconnected by MAC-level bridges. It has around 8000 > connected systems ... Do I read this right? CERN has a bridged network of eight THOUSAND end stations? This boggles the mind, and is the basic problem. Install some routers ;) Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 10:00:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16876; Fri, 21 Oct 94 10:00:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16870; Fri, 21 Oct 94 10:00:49 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19969; Fri, 21 Oct 94 09:56:36 PDT Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA03826; Fri, 21 Oct 94 09:56:32 PDT Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA07569; Fri, 21 Oct 1994 17:59:08 +0100 Message-Id: <199410211659.AA07569@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: Smoking guns (was: Re: (IPng) Re: ARP) In-Reply-To: Your message of "Fri, 21 Oct 1994 17:16:33 +0100." <9410211616.AA16580@dxcoms.cern.ch> Date: Fri, 21 Oct 1994 17:59:04 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Brian, I know that the CERN has good reasons to run a very large collection of bridged networks, but you certainly realize that bridging and multicast don't mix well. The multicast routing protocols (CBT, PIM, DVMRP) try to make sure that the packets are only multicast to those segments where at least one group member is present; they may have various rate of success, but at least they do try. Multicast routing protocols are normally run in routers; they will be a normal part of IPv6 operation. Bridges, on the other hand, have no clue. The membership information is provided by IGMP, an Internet-level protocol; that information is simply not available to bridges. The only option is to consider that "all multicast are broadcast to all segments". If the current trend continues, we will see more and more usage of multicast; I would not be surprised if, 5 years from now, it represents 50% of the average network's load. I would not like to rely on bridges then! Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 11:09:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17007; Fri, 21 Oct 94 11:09:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17001; Fri, 21 Oct 94 11:09:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28254; Fri, 21 Oct 94 11:05:00 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA17754; Fri, 21 Oct 94 11:02:56 PDT Subject: (IPng) Boot time intra-link unicast addresses To: addrconf@cisco.com, IPng Mailing list Date: Fri, 21 Oct 1994 14:01:18 -0500 (EST) From: Dan McDonald Cc: Dan McDonald , Ran Atkinson X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2968 Message-Id: <9410211901.aa02281@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Before I begin, this is a BSD-colored implementation. Please keep that in mind. I have just finished some mods to the ifconfig(8) binary such that the following will work on any interface: ifconfig in6 auto What that does is take and assign it an intra-link scoped local-use address. For the loopback interface, it simply assigns fe00::1/127 (i.e. 127 bits of netmask). For MAC-addressable interfaces, it assigns fe00::/80 (i.e. 80 bits of netmask). This will work for most normal cases, including: 1. Global internet -- Because the router/address server on the subnet will be called through multicast, which has to be joined by specifying an interface address. If I have a multi- homed node, I send intra-link m-casts to the router/address server over each *specified* interface. If packets are sent unicast to other local- use addresses, that's fine, because routers won't route with all 0's after the FE. (Unless there's a bug, poor router configuration, or my understanding is shot to hell.) 2. Private internet -- Same reason as global. 3. Dentist's office -- Single subnet means prefix is valid, and packets can go out interface. If multiple subnets, there should be a router, then see #2. The ONLY case where what I'm doing dies like a dog is a weird case of the dentist's office problem. I'll call it the experimental dentist's office problem. Consider a dentist who has her high-tech dentistry equipment on one subnet, and her office staff on another net. The dentist's machine itself is on both subnets, but does not route packets between the office equipment and the dentistry equipment (her secretary should not be handling the auto-drill, y'know). -------+-------+-------------------+--------- Office subnet | | | Secretary Payroll Dentist | ------+------------+----------+----+--------- Dentistry subnet | | | Automatic Chair Drill X-ray machine In this case, some manual configuration will be required, if all of these machines run our IPv6 implementation. Am I right in assuming the experimental dentist office will need manual configuration, or will I have to come up with a better solution. I looked through my trip notes (and granted I may have spaced on one or two things) but I didn't see anything suggesting what to do about prefix masks for the bootstrapping local-use address. Comments, praise, complaints, death threats, etc. to the address below: -- Daniel L. McDonald | Mail: danmcd@itd.nrl.navy.mil -------------------------+ Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html | Naval Research Lab | Phone: (202) 404-7122 #include | Washington, DC | "Rise from the ashes, A blaze of everyday glory" - Rush + ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 11:36:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17123; Fri, 21 Oct 94 11:36:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17117; Fri, 21 Oct 94 11:36:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00256; Fri, 21 Oct 94 11:32:17 PDT Received: from CLYNN.BBN.COM ([128.89.1.209]) by Sun.COM (sun-barr.Sun.COM) id AA22214; Fri, 21 Oct 94 11:30:10 PDT Message-Id: <9410211830.AA22214@Sun.COM> Received: by CLYNN.BBN.COM id aa00556; 21 Oct 94 14:18 EDT Date: Fri, 21 Oct 94 14:17:14 EDT From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Subject: Re: Smoking guns (was: Re: (IPng) Re: ARP) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian, > Bridges, on the other hand, have no clue. The membership information > is provided by IGMP, an Internet-level protocol; that information is > simply not available to bridges. The only option is to consider that > "all multicast are broadcast to all segments". I believe Alantec makes a bridge product ("brouter" ?) that can filter IP multicast similar to a router. Charlie ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 11:38:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17135; Fri, 21 Oct 94 11:38:28 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16207; Thu, 20 Oct 94 17:23:21 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05600; Thu, 20 Oct 94 17:19:09 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA28496; Thu, 20 Oct 94 17:18:58 PDT Received: from X400 by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04182; Fri, 21 Oct 1994 10:18:06 +1000 (from /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au) >From: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA03540; Fri, 21 Oct 94 10:01:31 +1000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 21 Oct 94 10:12:27 +0000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 21 Oct 94 10:12:27 +0000 X400-Received: by /ADMD=TELEMEMO/C=AU ; Relayed ; 21 Oct 94 10:12:27 +0000 Date: 21 Oct 94 10:01:31 +1100 Delivery-Date: 21 Oct 94 10:01:31 +1100 Message-Type: Multiple Part X400-Originator: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400 X400-Mts-Identifier: [/ADMD=TELEMEMO/C=AU;dcpmel 941021 09:47:21 033] X400-Recipients: ipng@sunroof.eng.sun.com Original-Encoded-Information-Types: IA5-Text Message-Id: <941021 09:47:21*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS> Importance: normal Subject: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS Autoforwarded: FALSE To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Priority: normal Conversion: Allowed Conversion-With-Loss: Allowed Content-Identifier: 941021 09:47:21 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM FORWARDED TO: X400@MIS@DCPMEL[C=AU;A=TELEMEMO;P=DATACRAFT;O=INTERNET;D.RFC-822*IPNG(A)SUNROOF.ENG.SUN.COM;] cc: Comments by: Alan Lloyd@Marketing@DCTHQ Comments: sorry this went to owner.. we are ditching the gateway for something that works a little better.. regards alan@Oz -------------------------- [Original Message] ------------------------- gday.. comments from masataka.. probably a bit of confusion has crept in with ATM.. I see a number of people refer to it as a Link protocol.. and no doubt we can debate this one to infinity... If X.25 (not the hdlc bit) is a "network layer protocol" (because it is set up with X.121 addresses) and then ROUTED on logical channel numbers.. why is not ATM ... if it is set up with Q.2931 (E164/NSAPs) and ROUTED on VPI/VCI?? Data Link = encoding of physical bits (frames) and traditionally was point to point.. However, Frx blew that one away.. ATM.. also screwed up the definition a bit by having its framing (Header +HEC) and its "network routing information" together as one protocol .. unlike hdlc and X.25.. the point.. ATM as a "link layer" to me sounds wrong because it is not point to point and it requires Network Level signalling to set it up..ie Q.2931 is a bit more complex than a SABM. (perhaps FRX is a network protocol?) regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 11:38:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17147; Fri, 21 Oct 94 11:38:46 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16267; Thu, 20 Oct 94 18:25:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10508; Thu, 20 Oct 94 18:21:19 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA10381; Thu, 20 Oct 94 18:21:12 PDT Received: from X400 by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA06254; Fri, 21 Oct 1994 11:20:54 +1000 (from /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au) >From: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA03981; Fri, 21 Oct 94 11:04:15 +1000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 21 Oct 94 11:19:23 +0000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 21 Oct 94 11:19:23 +0000 X400-Received: by /ADMD=TELEMEMO/C=AU ; Relayed ; 21 Oct 94 11:19:23 +0000 Date: 21 Oct 94 11:04:15 +1100 Delivery-Date: 21 Oct 94 11:04:15 +1100 Message-Type: Multiple Part X400-Originator: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400 X400-Mts-Identifier: [/ADMD=TELEMEMO/C=AU;dcpmel 941021 12:17:02 039] X400-Recipients: ipng@sunroof.eng.sun.com Original-Encoded-Information-Types: IA5-Text Message-Id: <941021 12:17:02*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS> Importance: normal Subject: (IPng) MOBILES..COMMENTS Autoforwarded: FALSE To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Priority: normal Conversion: Allowed Conversion-With-Loss: Allowed Content-Identifier: 941021 12:17:02 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM GDAY, COMMENTS ON THE MOBILITY- SUPP- 00. TXT DOC.. The main issue I have is one that the "model" used is "host node" oriented and not "network" oriented.. and once you do that the netwok will not scale well.. Simply because that all endpoint nodes in the network, mobile or otherwise (eg correspondents) have to maintain the mobiles information.. as more mobile terminals are introduced the network gets swamped and the end nodes get more and more updates...(software stability also becomes an issue) Mobile Telephones.. Cells and Discrete numbers + home and roam.. good concepts... AND the lump of iron i have at home.. with a dial on it can still access mobile phones...ie ..it does not need "mobile management" software in it to talk to a mobile.. THus in this case we have backward compatility between mobile devices and antiques. I believe the model should be developed in this way.. eg assign an IP prefix code for Mobiles. logically disperse these addresses into cells across the regions of administration. Have Cell management modules which talk over TCP/UDP to each other and provide the Home Function and/or the Agent Function.. That way the big Internet becomes.. A standard (static) routed scheme with its UNicast addresses and in addition the mobiles link into home or agent cells over this..However this does mean that address administration will have to be well managed.. Each IP "cluster" (i dont like this term) which represents the home network will also be assigned a set of mobile number IP addresses which relate to the logical cell that cluster is in. The mobile terminal can either have a fixed IP and a mobile IP address or just a mobile. Basic operation. Teminals IP address = Organisation/ Region, Cell Number/ Terminal Number Mobile Terminal .. does ICMP register on mobile multicast.. IP addrs: src= mobile number, dest =mobile agent mcast Mobile Agent Cell .. calls the home cell for verification of connection. IP addrs src = mobile agent, dest = mobile cell number.. ie the mobiles home cell Home Cell verifies mobile and a) passes back to the agent OK + authentication info and credit and bill ids as needed OR b) denies the call.. Agent Cell responds via ICMP with "Registration Accept"..or Deny ....... All packets from the terminal to its correspondents pass via the Agent and are thinly encapsualted as described in the document or just the source address is changed for that of the agent and the terminal address is placed in the end to end options. In this way the correspondent does very little with the dialogue with the mobile.. at worst it can check the mobiles address and return it in the end to end options for the agent to process when "stripping" the response packets to the mobile. Corresponents calling the mobile without any knowledge of its location will call the home cell..If the mobile is there then connection will be made directly.. If it has logged onto an agent, then the home cell forwards the packets to the agent cell for similar processing.. At worst a "dumb" IP node can just call the home of the mobile.. At the best it can insert the mobiles number in the End to End and sent the packet to the "known cell".. Route optimisation will have to be determined based on the knowledge that will have to be built into the agent and home cell interactions.. These issues can be dealt with as the cell / mobile count increases.. And via Cell Update protocols (similar to the RIP/OSPF set). Later.. smart end systems (eg mobile seeking devices.. groping) can be introduced.. What should be noted though is that the network can scale because new cell functions and quantities can be introduced as the numbers increase...ie. NOT more and more processing in the terminal endpoints which will have an N by N traffic effect on the network.. So I would like to see a different model which is underpinned by an addressing policy / strategy based on cells and cell functions which communicate over the IP network.. There are a few issues to be resolved i know (eg. contention of multiple cell agents on the same multicast address..) >From a router perspective.. its make no difference.. A Server will be used to do the cell processing.. and from an IP terminal point of view .. the old dumb ones will still work.. Thoughts please Regards Alan@Oz PS.. Bills spec for discovery.. Can some protocol behaviour be described as: a) I believe that service level discovery should be separate to network connection management. b) that some of the fields described.. there use is unclear.. and c) the mobile registry one.. contains the care of address, yet should that be in the reply? a brief description of interaction and behaviour would help.. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 11:39:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17159; Fri, 21 Oct 94 11:39:14 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16447; Thu, 20 Oct 94 23:14:20 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20105; Thu, 20 Oct 94 23:10:08 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA07487; Thu, 20 Oct 94 23:10:01 PDT Received: from X400 by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA17404; Fri, 21 Oct 1994 16:09:31 +1000 (from /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au) >From: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA04651; Fri, 21 Oct 94 15:52:59 +1000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 21 Oct 94 16:07:45 +0000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 21 Oct 94 16:07:45 +0000 X400-Received: by /ADMD=TELEMEMO/C=AU ; Relayed ; 21 Oct 94 16:07:45 +0000 Date: 21 Oct 94 15:52:58 +1100 Delivery-Date: 21 Oct 94 15:52:58 +1100 Message-Type: Multiple Part X400-Originator: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400 X400-Mts-Identifier: [/ADMD=TELEMEMO/C=AU;dcpmel 941021 17:43:22 055] X400-Recipients: ipng@sunroof.eng.sun.com Original-Encoded-Information-Types: IA5-Text Message-Id: <941021 17:43:22*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS> Importance: normal Subject: (IPng) RE: RE: SUBNETS AGAIN WAS RE: (IPNG) RE: ARP Autoforwarded: FALSE To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Priority: normal Conversion: Allowed Conversion-With-Loss: Allowed Content-Identifier: 941021 17:43:22 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM FORWARDED TO: X400@MIS@DCPMEL[C=AU;A=TELEMEMO;P=DATACRAFT;O=INTERNET;D.RFC-822*IPNG(A)SUNROOF.ENG.SUN.COM;] Comments by: Alan Lloyd@Marketing@DCTHQ Comments: sorry again.. this originally went to owner.... grrrrrr . -------------------------- [Original Message] ------------------------- gday .. re joachims note.. the point about an end system knowing the ATM path (number - VPI/VCI) will only apply to nailed up circuits (PVCs) and using a very simple interface. Otherwise the end system requests a circuit via signalling using the called / calling addresses, paths are then assigned in the network and the end system has no knowledge of the path taken to the other end system.. This all sounds a bit simple so I hope I am not saying the obvious here.. I agree that ATM in a LAN environment is a waste of time, ethernet or MAC switching serves a better purpose.. why cut something up when one does not need to.... and then also risk loosing a bit of it? In the WAN (carrier) environment ATM is a different story.. and oddly enough thats is what I thought it was designed for -- ITU I.150, I.36x, etc.. carrier recs for ISDN - WANs.. This is because one can take voice, data, etc and cut it up and switch it more effectively.. ie switching and multiplexing rates are determined by the cell size and address assignments (VPI/VCI ranges). Traffic peaks will have to be determined by buffereing, parallel processing, feed back channels and management signalling.. and this could be complex.. The LAN environment isnt complex nor does it have to be.. so why ATM in routers and LANs? I am buggered if I know.. Marketing is a wonderful thing isnt it? ATM trunks into carriers makes more sense, then one can multiplex PABXs, Routers, Cameras, etc into a common fibre/copper ATM/SDH pipe.. and the carriers can switch the ATM to their advantage. So ATM for LANs = " Any Thing Meaningful?" for WANs = " All Things Marvellous!" Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 13:19:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17336; Fri, 21 Oct 94 13:19:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17330; Fri, 21 Oct 94 13:19:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08949; Fri, 21 Oct 94 13:14:55 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA08524; Fri, 21 Oct 94 13:12:50 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA03022; Fri, 21 Oct 1994 13:08:53 -0700 Date: Fri, 21 Oct 1994 13:08:53 -0700 From: Tony Li Message-Id: <199410212008.NAA03022@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Packs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, As part of the ERP discussion, some of us were trying to understand how subnet addresses (the IPv4 flavor), routing domain identifiers, and cluster addresses would all play together as part of ERP. The result of this discussion is that we believe that it would be very beneficial to have a single encompassing abstraction. The following is a brief discussion of one possibility. Please note that this is still too fluid to be called a proposal. Especially note that the terminology is subject to change. Tony (and Yakov and Deborah and Peter) Definition: ----------- A subgraph (not necessarily connected) of a network forms a "pack" with an identifier "pack-id" if all the following conditions are satisfied: 1. Associated with each pack is a globally unique identifier (Pack Identifier). Syntactically, a Pack Identifier is a 16 octet unicast address. 2. There is an address administration (at least one, but maybe several) that is responsible for unicast address allocation for all the elements within the subgraph. A Pack Identifier (pack-id) is assigned by one such administration out of the unicast address block used by the administration for unicast address allocation within the subgraph. 3. All the routers that connect the subgraph (or its connected components) with the rest of the network are called "pack routers". The routers are preconfigured as "pack routers" with the Pack Identifier equal to pack-id. The configuration procedures are outside the scope of the definition. 4. At least some of the pack routers advertise into the routing system a prefix that matches (in the sense of the "longest match" algorithm) pack-id. In addition, a pack router may advertise into the routing system a prefix of pack-id only (i.e., a host route). All the hosts and routers within each connected component that forms a pack, including pack routers are said to be "members of the pack". Possible Applications: ---------------------- It is expected that the concept of a pack will be used for the following purposes: 1. Specify that a packet has to be destined to an element (either a router or a host) that is a member of a pack identified by a particular Pack Identifier (anycast). 2. Specify that a packet has to traverse through a pack identified by a particular Pack Identifier (transit). For this application it is assumed that a pack router knows (by some means) the pack identifiers of all other routers that share a common subnetwork with the router. Possible Realization of a pack: ------------------------------- A Routing Domain is a pack. The domain is identified by a Routing Domain Identifier (RDI), which is simply the Pack Identifier for the domain. Any Border Router of a domain is a pack router. A Routing Domain Confederation is a pack. The confederation is identified by a Routing Domain Confederation Identifier (RDCI), which is the Pack Identifier for the confederation. A Border Router of a domain within a confederation that peers with a Border router in a domain that is not in the confederation is a pack router. An OSPF area is a pack. The Pack Identifier of such a pack may be any unicast address that matches address prefixes within the area. An IS-IS area is a pack. The Pack Identifier of such a pack may be any unicast address that matches address prefixes within the area. An IPv4 subnet is a pack. The pack includes all the hosts and routers attached to the subnet. Any router attached to the subnet is a pack router. The Pack Identifier of such a pack is an address out of the subnet. Other useful (but not necessary) properties of a pack: ------------------------------------------------------ A router that is a pack router knows (by some means) pack Identifiers of all other routers that share a common subnetwork with the router. This is normally expected to be provided by unicast routing. This property is essential for the use of packs in ERP. ERP would operate by placing pack addresses in the ERP header as part of the explicit route. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 14:27:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17469; Fri, 21 Oct 94 14:27:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17463; Fri, 21 Oct 94 14:27:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15267; Fri, 21 Oct 94 14:23:01 PDT Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AB22161; Fri, 21 Oct 94 14:20:28 PDT Received: by nero.dcrc.com (4.1/1.34) id AA24846; Fri, 21 Oct 94 17:18:11 EDT Date: Fri, 21 Oct 94 17:18:11 EDT From: mad@nero.dcrc.com (Michael A. Davis) Message-Id: <9410212118.AA24846@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199410212008.NAA03022@lager.cisco.com> (message from Tony Li on Fri, 21 Oct 1994 13:08:53 -0700) Subject: Re: (IPng) Packs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have some questions about packs: 1) Must every pack include a router? Imagine a pack defined as "all hosts with copies of J. Random Archive." 2) If the answer to question #1 is 'no', then perhaps you need a new term for the union of the pack and the pack routers. You use "members of the pack," which is confusing if the pack router is not a member of the pack. Perhaps "gang" is a useful term? 3) You write that the Pack ID is, syntactically a 16-byte unicast address. What are its semantics? If a router or multihomed host is a member of the pack, is the Pack ID associated with an interface, or treated as a type of multicast? The latter interpretation seems natural, but complicates the code somewhat. Anyway, I haven't read the ERP document completely, so I don't know how packs apply in that context. It seems like a good idea to have such a concept, however. -mad -- - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + Mike Davis + Do not use the return address + + Penril Datability Networks + Use mike@dss.com + + 190 North Main Street +- -- -- -- -- -- -- -- -- -- -- -+ + Natick, MA 01760 + Assume the smiley + - -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 15:34:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17677; Fri, 21 Oct 94 15:34:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17671; Fri, 21 Oct 94 15:34:24 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20977; Fri, 21 Oct 94 15:30:11 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA04921; Fri, 21 Oct 94 15:29:57 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id PAA10403; Fri, 21 Oct 1994 15:29:53 -0700 Date: Fri, 21 Oct 1994 15:29:53 -0700 From: Tony Li Message-Id: <199410212229.PAA10403@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Michael A. Davis's message of Fri, 21 Oct 94 17:18:11 EDT <9410212118.AA24846@nero.dcrc.com> Subject: (IPng) Packs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have some questions about packs: 1) Must every pack include a router? Imagine a pack defined as "all hosts with copies of J. Random Archive." No, definitely not. Again, a pack is just a subgraph. There can be a pack for "local nameservers". 2) If the answer to question #1 is 'no', then perhaps you need a new term for the union of the pack and the pack routers. You use "members of the pack," which is confusing if the pack router is not a member of the pack. Perhaps "gang" is a useful term? Ok, the definition needs some wordsmithing here. The intent was that the pack routers are members of the pack. 3) You write that the Pack ID is, syntactically a 16-byte unicast address. What are its semantics? Sigh. Well, this is somewhat tricky as we haven't fleshed out enough of what the IPv6 subnet model is to make this very concrete. The intuitive intent here is that members of the pack will receive packets that they see with this destination address. No packets will be sourced with the pack id. If a router or multihomed host is a member of the pack, is the Pack ID associated with an interface, or treated as a type of multicast? The latter interpretation seems natural, but complicates the code somewhat. The latter. Thanks for your comments, Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 21 16:10:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17738; Fri, 21 Oct 94 16:10:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17732; Fri, 21 Oct 94 16:10:03 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24200; Fri, 21 Oct 94 16:05:50 PDT Received: from merit.edu ([35.1.1.42]) by Sun.COM (sun-barr.Sun.COM) id AA10878; Fri, 21 Oct 94 16:03:43 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm036-12.dialip.mich.net [141.211.7.54]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA16999 for ; Fri, 21 Oct 1994 19:00:02 -0400 Date: Fri, 21 Oct 94 21:31:05 GMT From: "William Allen Simpson" Message-Id: <3315.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) NBMA problems Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Having returned from my week vacation in the splendor of New England (this morning at 4:30 am EDT), I'm trying to catch up. I had hoped that more productive discourse would have occured in the 181 messages to this list (by this morning) since we convened the implementor's meeting. > From: bound@zk3.dec.com (replying to Joel Halperin) > >One suggestion I have heard is that routers be permitted, but not required, > >to advertise prefixes. This is a fine and useful thing. > > Its been in Simpsons drafts for a long time so I think its more than a > suggestion. I think its OK too. > Yes, Jim. It is quite apparent that several of the posters, most particularly Joel Halperin, have not bothered to actually read the drafts before commenting. It's so much easier to flame away on a mailing list.... > >If a host gets a > >redirect to an IPv6/MAC address pair, it should use that without regard > >to whether it matches a prefix the host knows about. (Note that the > >policy on whether to send such a redirection is a local matter, to allow > >the strict separation that some people want.) > > This is where we do not agree and you have outstanding mail on this > question from previous discussion so I will hold off respondiing. > Jim, as currently written, redirects do _NOT_ have to match a prefix that the host knows about. This is useful for mobility. A mobile node which has registered with a Foreign Agent will not have a prefix which matches any advertised prefixes. When a local host (such as a printer or DNS) responds to a message from the mobile node, it will initially send to its preferred router. That router will send a redirect to the mobile node. > >I believe that this allows the efficiency of prefix use without putting > >"smarts" in the host which get in the way of routing flexibility, > >particularly as it relates to large NBMA networks. > > We are not talking about routing flexibility. We all agree on that. > What we are talking about is sending to other hosts who are not attached > to a subnet I am not a member of and I believe this is a bad > thing to do. It interferes with the princpals of robustness and begs > the question of why the interface is not a member of the subnet in the > first place which I did not get into but others have. > As you know, Jim, we discussed this at the meeting. The interface _IS_ a member of _ALL_ advertised prefixes, unless specially configured. Each interface can have many addresses. But, the security folks want to be able to ignore non-authenticated advertisements, thereby limiting the number of prefixes which will be used. In that case, the prefixes advertised by the router will not be used for that interface. However, when a router receives a datagram destined to another node on the same link, it _WILL_ send a redirect, unless specifically configured. In my swift perusal, I don't understand why you wouldn't? > Please define in detail how this relates to NBMA networks? Its not > clear to me it applies. > Or to anybody else.... Joel seems to be under multiple misguided delusions: 1) That switching is somehow "faster" than routing. Since both switching and routing dynamically access some form of internal database or cache showing the connectivity of network, both switching and routing take exactly the same implementation effort. That the switched value is typically smaller (3 to 5 bytes) is just another argument for 8 byte IPng addresses. Proponents argue that "path setup" can be done once to make switching more efficient. This is fundamentally not robust, and has been disproven by the very existence of IP. In fact, path setup makes switching SLOWER than routing, since there is an extra bit of latency during setup which is not present for routing. Short duration connections are badly affected. This is not a problem when prefixes are used. The traffic just flows naturally, without extra latency, through the net to the last hop. 2) That switching will scale globally. Imagine a server with 100 clients. Think of the processing and memory requirements for maintaining the connection table for global switching of every client. This is much worse than (and in addition to) a TCP connection, and is required for UDP and other datagrams. This is required in hosts! Now imagine 100,000,000 DNS clients. We know that routing will scale globally. It scales because we use prefixes. Low memory use in hosts is a requirement of IPv6. Therefore, prefixes are essential for speed and for scaling. The concept of "bypassing" the subnets for direct connections is completely and fundamentally antithetical to IP principles. NBMA is supported by the current Neighbor Discovery, by relaxing the prefix requirements. We follow recommendation #1 of RFC-1620, which everyone should read before continuing this discourse. NB: Neighbor Discovery chose method #1 long before RFC-1620 was written. I am gratified that the IAB authors came to the same conclusions that we have. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 09:57:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00240; Mon, 24 Oct 94 09:57:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00220; Mon, 24 Oct 94 09:56:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23427; Sat, 22 Oct 94 09:31:53 PDT Received: from cps211.cps.cmich.edu by Sun.COM (sun-barr.Sun.COM) id AA25790; Sat, 22 Oct 94 09:28:06 PDT Received: (from wilson@localhost) by cps211.cps.cmich.edu (8.6.9/8.6.9) id MAA01695; Sat, 22 Oct 1994 12:28:03 -0400 From: Brad Wilson Message-Id: <199410221628.MAA01695@cps211.cps.cmich.edu> Subject: (IPng) IPv6 Sockets and source routing... To: ipng@sunroof.Eng.Sun.COM (IPng Discussion Group) Date: Sat, 22 Oct 1994 12:28:03 -0400 (EDT) Cc: bob.gilligan@Eng, set@thumper.bellcore.com, bound@zk3.dec.com X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 732 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It's a nitpick. ;-) On p12, the doc reads: "The array will hold two elements -- source and destination address -- when the UDP packet or TCP SYN packet does not carry a source route." I don't know if anyone will need to programatically figure out if a packet is source routed (and would be suspicious of any such need), but wouldn't a source routed packet to someone one hop away from you (ie, on your wire) also generate a two-element source route? Brad -- Brad Wilson Crucial Software Share and Enjoy! msg++; smiley++; Internet: wilson@cps201.cps.cmich.edu Speaking for myself and myself alone "We judge others by their actions; but we judge ourselves by our intentions." ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 09:57:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00239; Mon, 24 Oct 94 09:57:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00214; Mon, 24 Oct 94 09:56:40 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22613; Sat, 22 Oct 94 09:07:46 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA25041; Sat, 22 Oct 94 09:07:39 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 23 Oct 94 01:00:24 +0900 From: Masataka Ohta Message-Id: <9410221600.AA01199@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof.Eng.Sun.COM Date: Sun, 23 Oct 94 1:00:22 JST In-Reply-To: <941021 09:47:21*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS>; from ": /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au" at Oct 21, 94 10:01 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If X.25 (not the hdlc bit) is a "network layer protocol" (because it is set > up with X.121 addresses) and then ROUTED on logical channel numbers.. why is > not ATM ... Perhaps, to carry IP and other protocols over NSAP, it is necessary to say it link layer. > if it is set up with Q.2931 (E164/NSAPs) and ROUTED on VPI/VCI?? I have heard an idiom "L2 routing", routing at the link layer, which, to me, seems to be a fatal layering violation. > Data Link = encoding of physical bits (frames) and traditionally was point to > point.. However, Frx blew that one away.. Link layer is not necessarily point to point, if components have unique MAC addresses. Switched ether is something like a bridged link layer of point-to-point physical layers. > ATM as a "link layer" to me sounds wrong because it is not point > to point and it requires Network Level signalling to set it up..ie Q.2931 is > a bit more complex than a SABM. I agree with you that something is wrong with ATM. But, I think it wrong to do L2 routing based on NSAP address strcuture. If we stop doing so, and use NSAP addresses as flat MAC identifiers, we can use ATM as link layer. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 10:16:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00302; Mon, 24 Oct 94 10:16:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00292; Mon, 24 Oct 94 10:16:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07833; Mon, 24 Oct 94 08:20:40 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA17565; Mon, 24 Oct 94 08:20:30 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA28032; Mon, 24 Oct 94 08:05:11 -0700 Received: by xirtlu.zk3.dec.com; id AA08541; Mon, 24 Oct 1994 11:05:05 -0400 Message-Id: <9410241505.AA08541@xirtlu.zk3.dec.com> To: Dan McDonald Cc: addrconf@cisco.com, IPng Mailing list , Ran Atkinson Subject: (IPng) Re: Boot time intra-link unicast addresses In-Reply-To: Your message of "Fri, 21 Oct 94 14:01:18 CDT." <9410211901.aa02281@sundance.itd.nrl.navy.mil> Date: Mon, 24 Oct 94 11:04:58 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, -------+-------+-------------------+--------- Office subnet | | | Secretary Payroll Dentist | ------+------------+----------+----+--------- Dentistry subnet | | | Automatic Chair Drill X-ray machine >In this case, some manual configuration will be required, if all of these >machines run our IPv6 implementation. Not at all. I hope we come up with a way for the Dentist machine perform solicitation and receive advertisements from hosts on each subnet. What is needed are two addresses for the one interface, one way to start this is to ifconfig Iinterfrace one and Iinterface two. In that sense its manual but after that autoconfiguration should take place. >I looked through my trip notes (and granted I may have spaced on one or two >things) but I didn't see anything suggesting what to do about prefix masks >for the bootstrapping local-use address. Exactly and why your really doing experimental code you could throw away next Monday possibly. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 11:08:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00604; Mon, 24 Oct 94 11:08:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00598; Mon, 24 Oct 94 11:08:32 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22033; Mon, 24 Oct 94 01:47:03 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA07749; Mon, 24 Oct 94 01:47:02 PDT Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Oct 1994 08:46:54 +0000 To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Smoking Guns (was blah blah blah ARP) In-Reply-To: Your message of "Fri, 21 Oct 94 12:26:10 BST." <199410211126.AA00981@mitsou.inria.fr> Date: Mon, 24 Oct 94 08:46:54 +0000 Message-Id: <700.782988414@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM this arp stuff that CERN keep having go wrong on them, what on earth is wrong with caching and randomness...? surely they simply need to increase their cache timesouts, and rely on random startups of conversations, and then if they really have to move a machine or change ether card on a machine that doesnt do the gratuitous unsolicited ARP top self at boot time, run rdist to flush the arp table entry for that moved machine i mean the convenience of ARP is so high to us that with 3-4000 machines (65 routers a ferw hundred bridges and subnet server/routers, etc etc) we still would not part with it... on another matter, i note that Mike Gerard's note ends with "Multimedia Products making use of IP multicast can completely swamp an ethernet" this is a daft remark - if you want to send audio/video to n machines on an ethernet, NOT USING multicast is VERY bad for its health... anyhow, like someone said, there's all that particle accelrator money, why can't they afford a multiprotocol router infrastructure? cheers jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 11:15:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00660; Mon, 24 Oct 94 11:15:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00629; Mon, 24 Oct 94 11:15:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10804; Sun, 23 Oct 94 19:24:54 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA14815; Sun, 23 Oct 94 19:24:54 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-07.dialip.mich.net [35.1.48.88]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA08432 for ; Sun, 23 Oct 1994 22:24:51 -0400 Date: Mon, 24 Oct 94 01:12:46 GMT From: "William Allen Simpson" Message-Id: <3323.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) LL Multicast Last Hop Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: sob@harvard.edu (Scott Bradner) > I'd like to get an understanding about how much saving this > latency means. > > As I see it since there will generally be traffic between > backbone & local LAN routers this feature will only reduce the latency > for the 1st packet in a stream on its last hop and then only if > there is no cached arp entry. > > how important is this? how much is it worth adding in > complexity in order to reduce this latency? > The elimination of latency is only _part_ of the problem. As I was working on the Discovery today, I remembered another over-riding reason for using link-layer multicast to forward the IPv6 unicast datagram without waiting for Media Address resolution. Here's the scenario: 1) When I start my client, it asks the DNS for an IP address. 2) The DNS request is sent to the first server on my list. 3) The request goes a couple of hops, and at the last hop needs ARP resolution. 4) The Cisco throws away the request, and ARPs. 5) I eventually time out (6 seconds later), and make a request of the second server on my list. 6) That same Cisco throws away the new request while ARPing for the new server. 7) Eventually, I reach a server that already has an ARP cache entry, or I recycle through the list, and hit an ARP cache entry that my earlier request generated. Frequently, the server that I finally get a response from is not the nearest, but instead is located somewhere such as Kansas. FYI: Yes, the Cisco should hold the request. Every router _I_ have worked on does it right. But people keep buying Cisco anyway! The problems: - During late night, it takes as long as 2 minutes to get a DNS reply. My guess is this is because all ARP cache entries have timed out, and I have a long list of DNS servers. - During busy times of the day, I never get to a server! This may be because the ARP cache is too small, and gets flushed by one of the other hundred nodes on the link with the DNS, causing ARP thrashing. - Sometimes the above mean that I can't FTP or telnet. Many servers inverse-resolve my IP address, and timeout when they can't get the answer quickly (15 seconds or so). Internic is a problem here. - Even if the router did the right thing and held the DNS request until the ARP reply came back, that won't scale to 100 nodes. There isn't enough memory for holding 100 buffers after startup. Some will be dropped. - In a datagram environment (UDP and others), there is no retransmission strategy like TCP. It's not the "1st packet in a stream". It's the _only_ packet! - In the common case of client-server, all those clients will fire packets which will clog the router, at just the time when the router is already busy ARPing, and holding buffers! The solution: Send the unicast data as a "link-layer" multicast (as written), followed by the Where-Are-You. Saves memory. Eliminates latency. Reduces link traffic. Reduced processing at both hosts and routers. Nothing else will scale! (I will wait for the firestorm a few days.) Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 11:17:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00685; Mon, 24 Oct 94 11:17:12 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00391; Mon, 24 Oct 94 10:37:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04718; Mon, 24 Oct 94 07:30:05 PDT Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA08718; Mon, 24 Oct 94 07:30:03 PDT Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA15678; Mon, 24 Oct 94 09:32:14 CDT Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA00548; Mon, 24 Oct 94 09:29:43 CDT Date: Mon, 24 Oct 94 09:29:43 CDT >From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9410241429.AA00548@anubis.network.com> To: bill.simpson@um.cc.umich.edu, ipng@sunroof.Eng.Sun.COM Subject: (IPng) Some comment on Neighbor discovery in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlepeople, Some thoughts I had after reading the documents: [Si-Di] draft-simpson-ipv6-discov-process-00.txt and [Si-Fo] draft-simpson-ipv6-discov-formats-00.txt. In [Si-Di] page 6, the third alinea specifies: "on receipt of a General Advertisement, all nodes....". When reading the rest I can never find when a general advertisement should go to a single node or to multiple nodes. The second alinea on this page is the only one I can find that specifies sending "General Adv." but to me it is not clear wheter we want to send this (a) to the node sending the general soll. (b) to all routers (c) to all nodes. I agree that reading the rest of the IPv6 specifications, (c) violates the idea of don't bother stations that don't communicate with you. (b) saves the non-routers, but enlarges host tables on routers without any need (the host already talks to one specific router). (a) is the one I prefer and to my feeling agrees the the basic design idea of IPv6. [Si-Di] page 21: The use of the "Other Identifier" in a Routing Avertisement is explained: The sentence "The Other-Identifier extension ....... Cluster-prefix" was not immediate clear to me. It took me some time to understand it advertisements the other defined IPv6 addresses of this router. I kindly ask you to add as a second sentence of this paragraph: "That is: it advertises either the IPv6 addresses defined on the other physical interfaces or other IPv6 addresses on the same interface but outside the Cluster-prefix." [Si-Di] page 19: I don't understand the exact working of this Change-Identifier: If my end-node (non-router!) receives a change-identifier with Cluster- prefix equals zero, does it mean: This advertizements changes my(!) address? Is it then send as a (layer two) unicast to me? If so: What should happen if a router sends it out and the packet is lost If not: I don't understand the meaning .... If the prefix-size is non zero, and multiple Cluster-prefixes do exist on the link: How do I know it is for me? (a) Is it send as unicast? (b) Is it send to the cluster address (c) Is it send as all node/host multicast (d) Is it allowed to send such a message as a all-node intra-community multicast???? (If someone wants to play games with the Internet). On (a): Then it takes many messages to change the whole link, leaving a link with two cluster-prefixes for a while. On (b): According to "draft-hinden-ipng-addr-00.txt", page 13 a non- router does NOT have to listen to the cluster address. On (c): With multiple cluster-prefixes on a link, how do I pick out the right one. On (d): I don't dare to discuss that. Still on [Si-Di] page 19, but also page 20 The last paragraph on page 19: "The IPv6 Address and prefix ..... " ? This IPv6 never matches any address already defined, since it should change my address. First and second paragraph on page 20: Does it mean I get a temporary address on my station, so my address for a while is the one that was advertised and after a while I have to forget my own address? [Si-Fo] page 27: Transit Information, the first paragraph: "For advertisements, this indicates that a router ......" When reading page 8 of the same document, the "Transit Information"- extension is not specified as a possible extension in the Router Advertisement (neither in the Service Adv, nore in the General Adv). [Si-Fo] page 28: If an IPv6 header is 40 octets, why are the values on this page: length 54 and IPv6 header 48 octets? In general I would like more explicitly things as: when does a non-router send: general solicitation router solicitation service solicitation general advertisement router advertisement (I know,never.... but to be complete) service advertisement mobile registration request mobile registration reply when does a router send: .... same list Also what to do on receiving each of those, I agree that much of that information is already in the documentation, but I would like to see it more explicitly in seperated paragraphs. On the use "Local Use Addresses" as discussed in [Si-Di] and draft-hinden-ipng-addr-00.txt As far as I read it, a unit with no preconfigured IP address should: use prefix: fe00:: and use its Ethernet (or TR or FDDI) address as lowest 48 bits resulting in: fe00::mac-address Now if a router comes alive it starts sending router advertisements, from that the end-node should learn the Cluster-prefix size and value and change its address, ..... but .... what is several IPv6 addresses and cluster-prefixes are configured on the router on the same physical interfaces, which one to take? What if the routers advertisement tells me to make the Cluster-prefix size lets say 120 bits, leaving me with a "auto-configured" eight bit "unique" address? If you want me to clearify my comment, please E-mail me on: fredr@anubis.network.com I appriciate the work done so far on IPv6, to me it looks like it will be a great protocol. Regards Fred Rabouw Network Systems Netherlands. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 11:33:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00930; Mon, 24 Oct 94 11:33:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00920; Mon, 24 Oct 94 11:33:15 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04892; Sun, 23 Oct 94 15:44:48 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA03873; Sun, 23 Oct 94 15:44:46 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 24 Oct 1994 08:39:56 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 24 Oct 1994 08:43:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 24 Oct 1994 08:45:36 +1000 Date: Mon, 24 Oct 1994 08:45:36 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941024 10:15:48 070] X400-Content-Type: P2-1984 (2) Content-Identifier: 941024 10:15:48 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941024 10:15:48*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) RE: (IPNG) PACKS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. this pack stuff... "a RD is a pack, an area is a pack, a subnet is a pack".... the Internet in total is a pack.. the subdivisions and different levels of an NSAP is a pack.. I must have lost the plot.. an address is an address -- it indicates location.. it is subdivided for the purposes of administration and logical network design and therefore implies routing levels.. at any point (eg a defined field) in the address form.. the items that are "below it" are the responsibility of that point, the routing levels below it are the responsibility of that point.. the number of routers (zero or otherwise) making up the network (below the point) are the responsibility of that point.. to say that the various levels of an address are abstracted to a "pack" is curious.. What is wrong to use the terms as defined eg Country/Organisation/ Region, RD, Area, Subnet, SystemId, etc as components of the address routing hierarchy? and leave it at that.... If the address fields used by a network cannot be bolted down, then neither can the network design nor its administration. Provider / Subscriber.... Cluster.. and now "pack"... Please lets drop this one... Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 11:59:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01116; Mon, 24 Oct 94 11:59:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01094; Mon, 24 Oct 94 11:59:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13032; Sun, 23 Oct 94 01:59:02 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA05593; Sun, 23 Oct 94 01:59:02 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24367; Sun, 23 Oct 1994 09:58:58 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15692; Sun, 23 Oct 1994 09:58:56 +0100 Message-Id: <9410230858.AA15692@dxcoms.cern.ch> Subject: Re: Smoking guns (was: Re: (IPng) Re: ARP) To: ipng@sunroof.Eng.Sun.COM Date: Sun, 23 Oct 1994 09:58:56 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410211830.AA22214@Sun.COM> from "Charles Lynn" at Oct 21, 94 02:17:14 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 441 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, We all agree that 8000 is a bit big :-) for a bridged network but I will not bore you with all the good reasons why we got there. We are not crazy and our goal is to insert many routers over the next two years. Now I think we should drop this topic on this list and get on with IPv6 discovery - I've just made the point that ARP don't scale, and since IPv6 will be classless, there is no natural 254 host limit on subnets. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 12:15:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01221; Mon, 24 Oct 94 12:15:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01172; Mon, 24 Oct 94 12:15:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07440; Sat, 22 Oct 94 19:22:51 PDT Received: from ns.Novell.COM by Sun.COM (sun-barr.Sun.COM) id AA21187; Sat, 22 Oct 94 19:22:50 PDT Received: from by ns.Novell.COM (4.1/SMI-4.1) id AB29675; Sat, 22 Oct 94 20:22:23 MDT Date: Sat, 22 Oct 94 20:22:23 MDT Message-Id: <9410230222.AB29675@ns.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Dan McDonald From: greg_minshall@Novell.COM Subject: (IPng) Re: Boot time intra-link unicast addresses Cc: addrconf@cisco.com, IPng Mailing list , Ran Atkinson Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, Sounds good. One machine on two subnets with autoconfig *can* be made to work assuming that the goal is *not* to allow that machine to provide routing services between the two subnets. *And* assuming that there is some way (in the service discovery protocol, for example) to distinguish between the two networks when initiating a connection. That is a big assumption; if you decide to accept it, there is *still* a lot of work to be done (you end up having two networks with the same "address"). (Apple, for example, has this problem with people who are connected to one un-configured ethernet network with file servers, other machines, etc., and to one appletalk network with a laserwriter on it.) Greg Minshall ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 13:08:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01479; Mon, 24 Oct 94 13:08:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01473; Mon, 24 Oct 94 13:08:00 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08765; Mon, 24 Oct 94 13:03:43 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA09973; Mon, 24 Oct 94 13:03:36 PDT Subject: (IPng) Re: Boot time intra-link unicast addresses To: bound@zk3.dec.com Date: Mon, 24 Oct 1994 13:54:08 -0500 (EST) From: Dan McDonald Cc: addrconf@cisco.com, ipng@sunroof2.Eng.Sun.COM, atkinson@sundance.itd.nrl.navy.mil In-Reply-To: <9410241505.AA08541@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Oct 24, 94 11:04:58 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1640 Message-Id: <9410241854.aa04644@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > -------+-------+-------------------+--------- Office subnet > | | | > Secretary Payroll Dentist > | > ------+------------+----------+----+--------- Dentistry subnet > | | | > Automatic Chair Drill X-ray machine > > Not at all. I hope we come up with a way for the Dentist machine > perform solicitation and receive advertisements from hosts on each > subnet. Greg Minshall mentioned something like this earlier. It is not easy. If I understand correctly, the Dentist machine would have to have a table for each possible destination it discovered, and... wait a minute. Doesn't Bill's discovery docs do just that? If I have equal prefix matches for interfaces, I send discovery messages out BOTH of them. Hmm, in that case, provided I have a correct DISCOVERY implementation, the above problem does not require manual configuration. Cool! > What is needed are two addresses for the one interface, one way Two addresses for one interface? Yes it's a good idea, but I can't see how it will help the problem illustrated above. The Dentist machine has TWO interfaces, one on each net. If I had all of the machines (both administrative and dental types) on one net, then the LONE interface would have two addresses. (And IMHO would still require manual configuration because of two prefixes on a single non-routable subnet.) Let's make sure we're in synch on this topic. I think we are in the same ballpark, heck, maybe even the same part of the ballpark (I play RF myself :). Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 15:40:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01713; Mon, 24 Oct 94 15:40:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01706; Mon, 24 Oct 94 15:40:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23451; Mon, 24 Oct 94 15:36:32 PDT Received: from clix.aarnet.edu.au ([130.102.128.59]) by Sun.COM (sun-barr.Sun.COM) id AA07334; Mon, 24 Oct 94 15:36:05 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 25 Oct 1994 08:23:05 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 25 Oct 1994 08:27:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 25 Oct 1994 08:28:22 +1000 Date: Tue, 25 Oct 1994 08:28:22 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941025 09:41:18 102] X400-Content-Type: P2-1984 (2) Content-Identifier: 941025 09:41:18 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941025 09:41:18*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) FLOW LABELS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, masataka's reply.. thanks.. agree with most.. comment on using NSAPs for L2 routing.. It is ok to take a component of the NSAP and use it for L2 routing hence the system ID can be a MAC address if using the ICD or DCC forms.. ie the packet is routed on every thing above the system ID at the CLNP/IP layer and then when it hits the subnet, the router directs it with the mac address from the NSAP. However, once an ICD (or DCC org) is assigned.. what goes in the NSAP address is the responsibility of that organisation.. It is just numbers to the outside world. Other NSAP forms can carry a DSP which is other information that can be used for all sorts eg hosts, front ends, terminals, and links.. Therefore the mapping from an NSAP (network service) to a network or to a link protocol address can be direct or indirect.. Its a question on how they are used. The same follows for IP6 addresses if the last 6 bytes is dedicated for MAC addresses then the MAC address can be carried.. However the form needs to understood.. Say there is an E.164 subnetwork, then given that E.164 (and X.121) could only use 16 digits.. then 8 bytes could be set aside for that.. May be the area we are touching on is the issue where IP addressing has traditionally been independent of underlying addresses, but because it was "LAN" originated, the ARP mechanism served well to deal with MAC addresses and their mapping to IP.. In the case of new IP.. I suppose the issue now arrises where it is desirable to deal with X.121, E.164 and MAC addresses, either by mechanisms such as ARP.. although there are problems because of the switched nature of these circuits (X.25. Frx and ATM) or optionally carry such information in the IP address that can be mapped directly or indirectly to the lower layer addressing.. Again my philosophy here is a small network that is stable can carry its lower layer addresses as the system Id.. Larger networks that could use one or more underlying network services.. map the system Ids (logical) to one or more carrier numbering plans.. ie this is a product suppliers feature.. So.. the question .. address forms and carrier numbering plans.. We just need a few address format Ids beyond that of natural IP6 eg Format Prefix a) = IP6 + IP4 b) = IP6 + IP4 + MAC c) = IP6 + IP4 + E.164 d) = IP6 + IP4 + X.121 e) = IP6 + MAC f) = IP6 + E.164 g) = IP6 + X.121 It is possible to get national X.121 and E.164 numbers into 6 bytes as per MAC.. therefore the IP address format could be similar for all addresses. it just needs an ID up the front to say what is being carried as the last few bytes.. Unfortunately I am getting a bit "NSAP ish" with this one.. so comments would be welcome.. However, the issue is still one of having the flexibility from the provider level down to use the address form to their advantage. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 17:30:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01824; Mon, 24 Oct 94 17:30:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01809; Mon, 24 Oct 94 17:30:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06544; Mon, 24 Oct 94 17:25:59 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA02652; Mon, 24 Oct 94 17:24:07 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA11446; Mon, 24 Oct 1994 17:23:35 -0700 Date: Mon, 24 Oct 1994 17:23:35 -0700 From: Tony Li Message-Id: <199410250023.RAA11446@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: ALAN.LLOYD@DCTHQ.datacraft.telememo.au's message of Mon, 24 Oct 1994 08:45:36 +1000 <"941024 10:15:48*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Subject: (IPng) RE: (IPNG) PACKS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. this pack stuff... "a RD is a pack, an area is a pack, a subnet is a pack".... the Internet in total is a pack.. the subdivisions and different levels of an NSAP is a pack.. an address is an address -- it indicates location.. it is subdivided for the purposes of administration and logical network design and therefore implies routing levels.. And we only know how to subdivide it hierarchically, so we do that. And then, because we don't want to always route hierarchically, we don't distribute routing information hierarchically. We trust this to scale because we keep people "informed" of the issues and put in some safeguards so that non-hierarchical information is constrained. At the same time, we also find that we need similar flexibility in our abstractions. Hierarchical addressing does give us one abstraction mechanism, but it turns out that for multiple applications (routing domain confederations, anycast, multicast groups), it is not an appropriate abstraction. Thus, we add another, more flexible abstraction to our tool chest. We again realize that we depend on reasonably informed humans and basic safeguards to insure that we have some prospect of scaling. What is wrong to use the terms as defined eg Country/Organisation/ Region, RD, Area, Subnet, SystemId, etc as components of the address routing hierarchy? and leave it at that.... If the address fields used by a network cannot be bolted down, then neither can the network design nor its administration. You're missing the point. What happens when I want an abstraction which does not fit this hierarchy? How do I address a packet to "one of the routers at MAE-East or MAE-East+"? Provider / Subscriber.... Cluster.. and now "pack"... Please lets drop this one... Better yet, let's drop 'cluster'. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 17:30:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01823; Mon, 24 Oct 94 17:30:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01806; Mon, 24 Oct 94 17:30:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06544; Mon, 24 Oct 94 17:25:59 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA02652; Mon, 24 Oct 94 17:24:07 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id RAA11446; Mon, 24 Oct 1994 17:23:35 -0700 Date: Mon, 24 Oct 1994 17:23:35 -0700 From: Tony Li Message-Id: <199410250023.RAA11446@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: ALAN.LLOYD@DCTHQ.datacraft.telememo.au's message of Mon, 24 Oct 1994 08:45:36 +1000 <"941024 10:15:48*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Subject: (IPng) RE: (IPNG) PACKS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. this pack stuff... "a RD is a pack, an area is a pack, a subnet is a pack".... the Internet in total is a pack.. the subdivisions and different levels of an NSAP is a pack.. an address is an address -- it indicates location.. it is subdivided for the purposes of administration and logical network design and therefore implies routing levels.. And we only know how to subdivide it hierarchically, so we do that. And then, because we don't want to always route hierarchically, we don't distribute routing information hierarchically. We trust this to scale because we keep people "informed" of the issues and put in some safeguards so that non-hierarchical information is constrained. At the same time, we also find that we need similar flexibility in our abstractions. Hierarchical addressing does give us one abstraction mechanism, but it turns out that for multiple applications (routing domain confederations, anycast, multicast groups), it is not an appropriate abstraction. Thus, we add another, more flexible abstraction to our tool chest. We again realize that we depend on reasonably informed humans and basic safeguards to insure that we have some prospect of scaling. What is wrong to use the terms as defined eg Country/Organisation/ Region, RD, Area, Subnet, SystemId, etc as components of the address routing hierarchy? and leave it at that.... If the address fields used by a network cannot be bolted down, then neither can the network design nor its administration. You're missing the point. What happens when I want an abstraction which does not fit this hierarchy? How do I address a packet to "one of the routers at MAE-East or MAE-East+"? Provider / Subscriber.... Cluster.. and now "pack"... Please lets drop this one... Better yet, let's drop 'cluster'. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 19:07:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01934; Mon, 24 Oct 94 19:07:43 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01928; Mon, 24 Oct 94 19:07:35 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id TAA14135; Mon, 24 Oct 1994 19:03:18 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA06542; Mon, 24 Oct 1994 19:04:21 +0800 Date: Mon, 24 Oct 1994 19:04:21 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9410250204.AA06542@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) re: IPv6 Sockets and source routing... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > On p12, the doc reads: > > "The array will hold two elements -- source and destination address -- > when the UDP packet or TCP SYN packet does not carry a source route." > > I don't know if anyone will need to programatically figure out if a > packet is source routed (and would be suspicious of any such need), We added the feature primarily so that UDP applications could reverse the source route when generating replies to packets that were source routed. > but wouldn't a source routed packet to someone one hop away from you > (ie, on your wire) also generate a two-element source route? The API just returns what is in the packet. So, if a packet is received that contains a source route, that source route will be passed up to the application. It doesn't matter where the intermediate hops are located. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 19:23:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01950; Mon, 24 Oct 94 19:23:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01944; Mon, 24 Oct 94 19:23:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17862; Mon, 24 Oct 94 19:18:44 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA24340; Mon, 24 Oct 94 19:18:40 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 25 Oct 94 11:11:05 +0900 From: Masataka Ohta Message-Id: <9410250211.AA09780@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof.Eng.Sun.COM Date: Tue, 25 Oct 94 11:11:03 JST In-Reply-To: <"941025 09:41:18*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS>; from "ALAN.LLOYD@DCTHQ.datacraft.telememo.au" at Oct 25, 94 8:28 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Other NSAP forms can carry a DSP which is other information that can be used > for all sorts eg hosts, front ends, terminals, and links.. > Therefore the mapping from an NSAP (network service) to a network or to a > link protocol address can be direct or indirect.. Its a question on how they > are used. To make the mapping direct, the target network layer address has similar structure as NSAP, that is, as inefficient as NSAP, which is an unnecessary restriction to IPv6. > May be the area we are touching on is the issue where IP addressing has > traditionally been independent of underlying addresses, It's not mere tradition but just a proper layering. > Again my philosophy here is a small network that is stable can carry its > lower layer addresses as the system Id.. Larger networks that could use one > or more underlying network services.. map the system Ids (logical) to one or > more carrier numbering plans.. ie this is a product suppliers feature.. One or more carrier numbering plan? If the WAN industry is not monopolized, there will be a lot of carriers each having their own numbering plans. Moreover, users will subscribe to several carriers. So, user's addressin plan should NOT be affected by carriers. > So.. the question .. address forms and carrier numbering plans.. > We just need a few address format Ids beyond that of natural IP6 > > eg Format Prefix a) = IP6 + IP4 > b) = IP6 + IP4 + MAC > c) = IP6 + IP4 + E.164 > d) = IP6 + IP4 + X.121 > e) = IP6 + MAC > f) = IP6 + E.164 > g) = IP6 + X.121 It should just be IP6 = (carrier dependent, hierarchical routing part) + (carrier independent, user controlled part) > It is possible to get national X.121 and E.164 numbers into 6 bytes as per > MAC.. therefore the IP address format could be similar for all addresses. > it just needs an ID up the front to say what is being carried as the last few > bytes.. I don't mind what format each user think the user part have. So, I don't think we need format prefix. > Unfortunately I am getting a bit "NSAP ish" with this one.. so comments would > be welcome.. I think you aren't, while those people who think they need 128bit routing hierarchy are. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 21:20:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01967; Mon, 24 Oct 94 21:20:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01961; Mon, 24 Oct 94 21:20:53 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22644; Mon, 24 Oct 94 21:16:33 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA09263; Mon, 24 Oct 94 21:16:28 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 25 Oct 1994 14:11:29 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 25 Oct 1994 14:14:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 25 Oct 1994 14:15:17 +1000 Date: Tue, 25 Oct 1994 14:15:17 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941025 13:31:41 014] X400-Content-Type: P2-1984 (2) Content-Identifier: 941025 13:31:41 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941025 13:31:41*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday, masataka.. not sure I understand your comments again.. particularly.. carrier numbering plans.. just because deregulation has occured.. it does not mean that my telephone has 20 different numbers.. And I am afraid all the CPE and switches on this planet make designing and revamping numbering plans quite a task.. so I dont think that there will be too many of these.. in fact E.164, X.121 and Telex is about it.. In fact it is essential for carriers in a competitive market place to keep the same numbering systems so they can: a) Interwork across the world b) Identify callers and Cross charge c) Act as Transit networks and: d) Pinch each others customers .. easily The use of an address format Id is to permit the equipment that implements a protocol profile the ability to extract/ map address fields from one layer to the lower one..with explicit action.. not just let "grab a field" and then let the protocol go off into hyper space..So in terms of fool proof engineering.. it is best that where a union of multiple formats exist, they are explicitly identified.. I wont go into the efficiency of NSAPs as that is a separate debate..( I can be tempted for money of course!) But the points already made are that there is a distinction between: a) IP6 definition which can support a number of addressing schemes. b) The internetworking product features that enable IP4/IP6/CLNP(NSAPs) to interwork and; c) The Internet as a service network. a) can embrace elements of NSAPs to make b) more consistent. It is expected that native IP6 addresses will run in the Internet. Anyway.. the point is still open... what is the IP6 address format for dealing/ mapping with carrier numbering plans and MAC addresses and what is the best way of representing these? Is this a December issue? Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 21:29:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01979; Mon, 24 Oct 94 21:29:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01973; Mon, 24 Oct 94 21:29:02 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23418; Mon, 24 Oct 94 21:24:44 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA11060; Mon, 24 Oct 94 21:24:36 PDT Received: from X400 by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04115; Tue, 25 Oct 1994 14:24:15 +1000 (from /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au) From: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA06855; Tue, 25 Oct 94 14:22:35 +1000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 25 Oct 94 14:23:37 +0000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 25 Oct 94 14:23:37 +0000 X400-Received: by /ADMD=TELEMEMO/C=AU ; Relayed ; 25 Oct 94 14:23:37 +0000 Date: 25 Oct 94 14:22:35 +1100 Delivery-Date: 25 Oct 94 14:22:35 +1100 Message-Type: Multiple Part X400-Originator: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400 X400-Mts-Identifier: [/ADMD=TELEMEMO/C=AU;dcpmel 941025 10:43:58 015] X400-Recipients: ipng@sunroof.eng.sun.com Original-Encoded-Information-Types: IA5-Text Message-Id: <941025 10:43:58*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS> Importance: normal Subject: (IPng) ATM..MASATAKA'S COMMENTS Autoforwarded: FALSE To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Priority: normal Conversion: Allowed Conversion-With-Loss: Allowed Content-Identifier: 941025 10:43:58 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM GDAY, MASATAKA'S COMMENT RE ATM AND SOMETHING WRONG WITH IT.. of the ITU ISDN program.. but with traditional ISDN only bandwidth was switched via cross connects.. where bandwidth becomes bursty and statistical, then multiplexing is required (hence VPI/VCIs) and where deterministic switching is needed .. fixed length things (cells) are needed..small cells make faster switching and could optimise switch utilisation based on "understood" switch distribution scenarios.. Note carriers grow their switch services over time.. but LANs and LAN devices go the whole hog when they feel like it.. so the distribution profiles and growth rates are quite different. Also B-ISDN is a "integrated services" network which may use ATM if multiplexing and switching is required over raw TDM bandwidth (SDH). So ATM in a LAN where one has control over distribution and switching and oodles of bandwidth... AND one is not an "Integrated Services Digital Network" Why?.. Ask the router / hub vendors because .. if one is taking ATM to the desk top .. one should also take the signalling.. and running Q.2931 around a building when there is no need .. not running it means nailed up ATM.. which serves little purpose in a high - over provisioned bandwidth environment. If one is taking Q.2931 to the desktop (and toasters), then we need some convenient way of mapping or incorporating E.164 (or the numbering plans in NSAPs) into the IP addresses.. as per my previous posting.. In the longer term... Perhaps the evolution is the merging of the Toasters, (Dentist's Appliances?), Telephones with the Television with the data network terminal.. so what is the addressing scheme and the carrier numbering plans then.. It will be this that makes ATM in the "LAN" environment useful.. and once circuits are connection oriented and on demand then oddly enough... billing and service agreements creep in. One thing for sure E.164 will be there.. Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 24 21:49:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02023; Mon, 24 Oct 94 21:49:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02017; Mon, 24 Oct 94 21:49:25 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25276; Mon, 24 Oct 94 21:45:07 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA15171; Mon, 24 Oct 94 21:45:05 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 25 Oct 1994 14:40:15 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Tue, 25 Oct 1994 14:44:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Tue, 25 Oct 1994 14:45:18 +1000 Date: Tue, 25 Oct 1994 14:45:18 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941025 14:26:26 016] X400-Content-Type: P2-1984 (2) Content-Identifier: 941025 14:26:26 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941025 14:26:26*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) RE: (IPNG) RE: (IPNG) PACKS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. tony.. yes.. yes.. we design addressing in a hierarchic fashion so that we can have big lumps that decompose? into smaller lumps in all directions and uniformally.. but we may operate between the small lumps without going up to the big lumps.. eg If i get a letter for my neighbour.. I walk next door.. I dont send it back to the post office... So what is wrong with accepting a formalised hierarchic structure and knowing that the operational model for that structure will "short circuit" the hierarchy.. Thats the way of the world..and networking.. It happens with Post, X.25, IP, phones, X.400.....etc. Its not a question of abstraction.. its a question of realisation. So lets formalise the hierarchy.. or as it already been done.. and then look at the points where logical "short circuits" can occur... its tieing the administrative needs and the operational needs. Were you serious about "cluster".. whats the procedure.. do I have to say "seconded".... Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 00:04:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02155; Tue, 25 Oct 94 00:04:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02149; Tue, 25 Oct 94 00:03:54 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02386; Mon, 24 Oct 94 23:59:36 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA29435; Mon, 24 Oct 94 23:59:31 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28842; Tue, 25 Oct 1994 07:59:29 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19300; Tue, 25 Oct 1994 07:59:27 +0100 Message-Id: <9410250659.AA19300@dxcoms.cern.ch> Subject: Re: (IPng) Re: Smoking Guns (was blah blah blah ARP) To: ipng@sunroof.Eng.Sun.COM Date: Tue, 25 Oct 1994 07:59:27 +0100 (MET) From: "Brian Carpenter CERN-CN" Cc: jmg@dxcoms.cern.ch (Mike Gerard) In-Reply-To: <700.782988414@cs.ucl.ac.uk> from "Jon Crowcroft" at Oct 24, 94 08:46:54 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1802 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Can't let that go, Jon... >--------- Text sent by Jon Crowcroft follows: > > > this arp stuff that CERN keep having go wrong on them, what on earth is > wrong with caching and randomness...? > > surely they simply need to increase their cache timesouts, and rely on > random startups of conversations, and then if they really have to move > a machine or change ether card on a machine that doesnt do the gratuitous > unsolicited ARP top self at boot time, run rdist to flush the arp table > entry for that moved machine > What's wrong is BADLY IMPLEMENTED PRODUCTS and my thesis is that the ARP model of the universe has demonstrably led many programmers to implement sloppy software. > i mean the convenience of ARP is so high to us that with 3-4000 > machines (65 routers a ferw hundred bridges and subnet server/routers, etc etc) > we still would not part with it... > Well, we haven't yet seen a large scale deployment of an address resolution server as in RFC 1577. IMO this will be just as convenient and less bug-prone. We shall see. > on another matter, i note that Mike Gerard's note ends with > "Multimedia Products making use of IP multicast can completely swamp > an ethernet" > > this is a daft remark - if you want to send audio/video to n machines > on an ethernet, NOT USING multicast is VERY bad for its health... Well, compared with N unicast streams that is of course true. The point is that on a big network, N multicast streams can also swamp you. This is mainly an argument against big networks though. Or for ethernet switches. > > anyhow, like someone said, there's all that particle accelrator money, > why can't they afford a multiprotocol router infrastructure? > Beleive it or not we are broke. But I do have a budget request in for lotsa routers. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 00:08:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02167; Tue, 25 Oct 94 00:08:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02161; Tue, 25 Oct 94 00:08:27 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02566; Tue, 25 Oct 94 00:04:10 PDT Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA03176; Tue, 25 Oct 94 00:04:08 PDT Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA24818; Tue, 25 Oct 1994 00:04:07 -0700 Date: Tue, 25 Oct 1994 00:04:07 -0700 From: Tony Li Message-Id: <199410250704.AAA24818@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) RE: (IPNG) RE: (IPNG) PACKS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM So what is wrong with accepting a formalised hierarchic structure and knowing that the operational model for that structure will "short circuit" the hierarchy.. Thats the way of the world..and networking.. It happens with Post, X.25, IP, phones, X.400.....etc. Its not a question of abstraction.. its a question of realisation. It's a question of bringing the abstraction to meet the realization. By improving the abstraction mechanisms such that we can abstractly discuss and manipulate entities which only used to be grody hacks as part of the imperfect realization, we improve the scope of the abstraction and introduce more flexibility and utility to the basic model. An example of this is variable length prefixes. Not so long ago, the basic abstraction was that of a single length for all network numbers. By introducing variable length prefixes, we allowed the model to more closely fit actual usage (which was people doing hacks) leading to the (hopeful) end of dreadful hacks, better addressing efficiency and the flexibility of CIDR. Were you serious about "cluster".. whats the procedure.. do I have to say "seconded".... Yes, I was very serious. I don't see that "cluster" in the current instantiation provides anything over "subnet", and is a particular instance of a pack. While I have no objection to having "cluster" as part of the terminology, we should certainly make it clear that it is the derivative abstraction. As to procedure, we have to obtain rough consensus. I've been working in the IETF for 4 years now, and I have less of clue as to how to do this than the day I started. ;-) It used to be the case that one proposed an idea, and when all of the reasonable people agreed, that was sufficient. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 02:28:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02334; Tue, 25 Oct 94 02:28:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02328; Tue, 25 Oct 94 02:28:43 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09692; Tue, 25 Oct 94 02:24:25 PDT Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA14169; Tue, 25 Oct 94 02:24:24 PDT Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Oct 1994 09:24:06 +0000 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: Smoking Guns (was blah blah blah ARP) In-Reply-To: Your message of "Tue, 25 Oct 94 07:59:27 +0100." <9410250659.AA19300@dxcoms.cern.ch> Date: Tue, 25 Oct 94 09:24:05 +0000 Message-Id: <1358.783077045@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Can't let that go, Jon... thats ok - i still want you to explain (not merely evidence) how ARP casting leads to bad implementations cheers > >>--------- Text sent by Jon Crowcroft follows: >> >> >> this arp stuff that CERN keep having go wrong on them, what on earth is >> wrong with caching and randomness...? >> >> surely they simply need to increase their cache timesouts, and rely on >> random startups of conversations, and then if they really have to move >> a machine or change ether card on a machine that doesnt do the gratuitous >> unsolicited ARP top self at boot time, run rdist to flush the arp table >> entry for that moved machine >> >What's wrong is BADLY IMPLEMENTED PRODUCTS and my thesis is that the >ARP model of the universe has demonstrably led many programmers >to implement sloppy software. > >> i mean the convenience of ARP is so high to us that with 3-4000 >> machines (65 routers a ferw hundred bridges and subnet server/routers, etc etc) >> we still would not part with it... >> >Well, we haven't yet seen a large scale deployment of an address >resolution server as in RFC 1577. IMO this will be just as convenient >and less bug-prone. We shall see. > >> on another matter, i note that Mike Gerard's note ends with >> "Multimedia Products making use of IP multicast can completely swamp >> an ethernet" >> >> this is a daft remark - if you want to send audio/video to n machines >> on an ethernet, NOT USING multicast is VERY bad for its health... > >Well, compared with N unicast streams that is of course true. The point >is that on a big network, N multicast streams can also swamp you. >This is mainly an argument against big networks though. Or for >ethernet switches. >> >> anyhow, like someone said, there's all that particle accelrator money, >> why can't they afford a multiprotocol router infrastructure? >> >Beleive it or not we are broke. But I do have a budget request >in for lotsa routers. > > Brian >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >Unsubscribe: unsubscribe ipng (as message body, not subject) >Direct all administrative requests to majordomo@sunroof.eng.sun.com jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 05:35:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02486; Tue, 25 Oct 94 05:35:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02480; Tue, 25 Oct 94 05:35:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16546; Tue, 25 Oct 94 05:31:27 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00561; Tue, 25 Oct 94 05:31:27 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA17834; Tue, 25 Oct 94 05:26:31 -0700 Received: by xirtlu.zk3.dec.com; id AA06588; Tue, 25 Oct 1994 08:26:21 -0400 Message-Id: <9410251226.AA06588@xirtlu.zk3.dec.com> To: Dan McDonald Cc: bound@zk3.dec.com, addrconf@cisco.com, ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Re: Boot time intra-link unicast addresses In-Reply-To: Your message of "Mon, 24 Oct 94 13:54:08 CDT." <9410241854.aa04644@sundance.itd.nrl.navy.mil> Date: Tue, 25 Oct 94 08:26:15 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > -------+-------+-------------------+--------- Office subnet > | | | > Secretary Payroll Dentist > | > ------+------------+----------+----+--------- Dentistry subnet > | | | > Automatic Chair Drill X-ray machine > > What is needed are two addresses for the one interface, one way >Two addresses for one interface? Yes it's a good idea, but I can't see how >it will help the problem illustrated above. The Dentist machine has TWO >interfaces, one on each net. If I had all of the machines (both >administrative and dental types) on one net, then the LONE interface would >have two addresses. (And IMHO would still require manual configuration >because of two prefixes on a single non-routable subnet.) OK I thought your subnets were on the same link per other discussions, my mistake (which would work too). But if they are two links with two Ethernets (or whatever) yes then you can have two addresses and you would ifconfigipv6 both interfaces. Now if you do have one interface with two addresses you will have to perform solicit and advertise on each interface it would be like ships passing in the night on the link. Each address would have a prefix from the ifconfigipv6 command (hence the only part of manual config) and wolla you then have autoconfig. I read Bills doc that I can do this with a host per caveats that the discussion of routerless environments are in process. I want to solicit and advertise as a hos in this environment and did back with one 'p' in SIP. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 06:01:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02521; Tue, 25 Oct 94 06:01:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02515; Tue, 25 Oct 94 06:01:29 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18215; Tue, 25 Oct 94 05:57:10 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03285; Tue, 25 Oct 94 05:57:11 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA19236; Tue, 25 Oct 94 05:51:56 -0700 Received: by xirtlu.zk3.dec.com; id AA08478; Tue, 25 Oct 1994 08:51:50 -0400 Message-Id: <9410251251.AA08478@xirtlu.zk3.dec.com> To: Dan McDonald , bound@zk3.dec.com, addrconf@cisco.com, ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Re: Boot time intra-link unicast addresses In-Reply-To: Your message of "Tue, 25 Oct 94 08:26:15 EDT." <9410251226.AA06588@xirtlu.zk3.dec.com> Date: Tue, 25 Oct 94 08:51:44 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, Also if you operate two or one interfaces the host vendors will be able to forward packets as they do today from one subnet to the other but it will be done different and need new logic. That "function" will still be possible in IPv6 as in your bsd code today. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 07:18:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02621; Tue, 25 Oct 94 07:18:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02615; Tue, 25 Oct 94 07:18:04 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24540; Tue, 25 Oct 94 07:13:46 PDT Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA13843; Tue, 25 Oct 94 07:13:44 PDT Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA24705; Tue, 25 Oct 94 09:15:53 CDT Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA15472; Tue, 25 Oct 94 09:13:21 CDT Date: Tue, 25 Oct 94 09:13:21 CDT From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9410251413.AA15472@anubis.network.com> To: bob.gilligan@Eng, hinden@Eng, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6/IPv4 host address? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlepeople, When comparing draft-hinden-ipng-addr-00.txt (page 9) and draft-gilligan-ipv6-sit-overview-00.txt (page 11) I noticed that these documents do not agree on the prefix of an IPv6/IPv4 host. The first document uses 0:0:0:0:0:ffff as prefix, the second one uses 0:0:0:0:ffff:ffff as prefix. I have no urgent reason to prefer either of the two, but the final documents should agree on one of them. Regards Fred Rabouw (fredr@anubis.network.com) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 07:25:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02638; Tue, 25 Oct 94 07:25:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02632; Tue, 25 Oct 94 07:25:17 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25043; Tue, 25 Oct 94 07:20:59 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15027; Tue, 25 Oct 94 07:20:58 PDT Received: from muggsy.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00199; Tue, 25 Oct 94 07:15:03 -0700 Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA07889; Tue, 25 Oct 1994 10:11:30 -0400 Received: by netrix.lkg.dec.com; id AA04832; Tue, 25 Oct 1994 10:14:34 -0400 Date: Tue, 25 Oct 1994 10:14:34 -0400 From: Dan Harrington Message-Id: <9410251414.AA04832@netrix.lkg.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RE: RE: (IPNG) FLOW LABELS Cc: ALAN.LLOYD@dcthq.datacraft.telememo.au, dan@netrix.lkg.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A comment by Alan@OZ requires a response... > It is ok to take a component of the NSAP and use it for L2 routing hence the > system ID can be a MAC address if using the ICD or DCC forms.. ie the packet > is routed on every thing above the system ID at the CLNP/IP layer and then > when it hits the subnet, the router directs it with the mac address from the > NSAP. You cannot assume that the Node/System ID field in an NSAP has any correspondence with that system's MAC address. My workstation has one NSAP of 41:45418715:00-41:08-00-2B-18-B5-33:21, and the two datalinks are configured as 08-00-2b-be-62-60 and aa-00-04-00-21-30. You're suggesting a routable version of the Inactive Subset of CLNP, which is also known as Null Internet. It's fine for a restricted LAN environment, but it's not something worth introducing into IP6. My experiences with CLNP and CONS over X.25 subnets indicates that the automatic X.121 mapping of NSAP to DTE address is used sparingly. Of course, my experiences in this area are limited, but I can't see this whole concept scaling well... What is needed is a Network address to Media address mechanism, such as ARP or ES-IS...that should be the focus of the effort here. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 10:00:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02746; Tue, 25 Oct 94 10:00:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02740; Tue, 25 Oct 94 10:00:26 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10391; Tue, 25 Oct 94 09:56:07 PDT Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA16707; Tue, 25 Oct 94 09:55:08 PDT Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA05102; Tue, 25 Oct 94 09:47:30 -0700 Received: by xirtlu.zk3.dec.com; id AA25865; Tue, 25 Oct 1994 12:47:28 -0400 Message-Id: <9410251647.AA25865@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Shared Media IPv6 Architecture Date: Tue, 25 Oct 94 12:47:22 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill Simpson is correct in saying discussing the subnet model and NBMA without reading RFC 1620 "Internet Architecture Extensions for Shared Media" is not a good idea. Much of our discourse on subnets et al is directly discussed via 4 methods in 1620: 1. Hop-by-Hop Redirection 2. Extended Routing 3. Extended Proxy ARP 4. Route Query Messages Good examples with diagrams that are very clear to discuss this problem. In addition the Hop-by-Hop (the one I prefer unless an updated version can reduce the time in an updated fashion to discover a media address) is the one I am leaning towards in my thoughts. This option would have a need for my suggestion previously of the "push-advertisement redirect" message. Also in this document it points out why redirects of this nature are dropped (or should be) in IPv4 from RFC 1122: A redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination. My proposal for a "push" would permit the host to accept the redirect and would be added to the network lookup on the host at the ipv6 layer and be delivered to the media address resolved at the link layer. The method for discovery would be the hop-by-hop as proposed in RFC 1620. p.s. thanks bill for that pointer it was very useful. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 10:07:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02767; Tue, 25 Oct 94 10:07:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02761; Tue, 25 Oct 94 10:07:33 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11194; Tue, 25 Oct 94 10:03:12 PDT Received: from dxmint.cern.ch ([128.141.1.113]) by Sun.COM (sun-barr.Sun.COM) id AA17807; Tue, 25 Oct 94 10:01:51 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18111; Tue, 25 Oct 1994 18:00:17 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18873; Tue, 25 Oct 1994 18:00:16 +0100 X-Delivered: at request of brian on dxcoms.cern.ch Received: from dxmint.cern.ch by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA21425; Tue, 25 Oct 1994 16:22:25 +0100 Received: from ietf.cnri.reston.va.us by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA21933; Tue, 25 Oct 1994 16:10:19 +0100 Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03978; 25 Oct 94 11:02 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03973; 25 Oct 94 11:01 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-carpenter-ipng-nosi-00.txt Date: Tue, 25 Oct 94 11:01:14 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-Id: <9410251101.aa03973@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Discussion paper for nosi BOF Author(s) : B. Carpenter Filename : draft-carpenter-ipng-nosi-00.txt Pages : 8 Date : 10/24/1994 This note is intended as a discussion draft for the "Next generation and OSI (nosi)" BOF at the San Jose IETF. It outlines requirements, scenarios, and mechanisms for OSI to IPv6 conversion. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-carpenter-ipng-nosi-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-carpenter-ipng-nosi-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19941024092206.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-carpenter-ipng-nosi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-carpenter-ipng-nosi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941024092206.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 11:33:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02880; Tue, 25 Oct 94 11:33:05 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02222; Tue, 25 Oct 94 01:28:09 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06854; Tue, 25 Oct 94 01:23:51 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA10362; Tue, 25 Oct 94 01:23:51 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08790; Tue, 25 Oct 1994 09:23:48 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23071; Tue, 25 Oct 1994 09:23:42 +0100 Message-Id: <9410250823.AA23071@dxcoms.cern.ch> Subject: Re: (IPng) Re: Smoking Guns (was blah blah blah ARP) To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Tue, 25 Oct 1994 09:23:42 +0100 (MET) >From: "J. Michael (Mike) Gerard, CERN-CN/CS" Cc: ipng@sunroof.Eng.Sun.COM, jmg@dxcoms.cern.ch (Mike Gerard) In-Reply-To: from "Brian Carpenter CERN-CN" at Oct 25, 94 07:59:27 am #Return-Receipt-To: jmg@dxcoms.cern.ch X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Can't let that go, Jon... Nor can I. > > >--------- Text sent by Jon Crowcroft follows: > > > > > > this arp stuff that CERN keep having go wrong on them, what on earth is > > wrong with caching and randomness...? > > > > surely they simply need to increase their cache timesouts, and rely on > > random startups of conversations, and then if they really have to move > > a machine or change ether card on a machine that doesnt do the gratuitous > > unsolicited ARP top self at boot time, run rdist to flush the arp table > > entry for that moved machine > > > What's wrong is BADLY IMPLEMENTED PRODUCTS and my thesis is that the > ARP model of the universe has demonstrably led many programmers > to implement sloppy software. Has anyone asked how come a (the?) major manufacturer of Unix workstations has made such a complete screw-up of their arp cache code? Ask me privately for details if you want the gory bits. You might also ask how easy it is to change things like cache timeouts and cache size, to which the answer is "not always easy, sometimes impossible". Don't forget, either, that we are dealing with over a thousand different Unix workstations, of different types, with users (= system managers) that don't understand these things and don't want to! In other words, if you have to fiddle around with such things you are already in trouble. As for throwing out a vague statement like "randomness" my observation is that things are not that way. There was a very good paper that I read which showed that in networks things which ought to be random actually have a tendency to synchronise in time, and I see exactly that! > > i mean the convenience of ARP is so high to us that with 3-4000 > > machines (65 routers a ferw hundred bridges and subnet server/routers, etc etc) > > we still would not part with it... Which does not mean that it is perfect! Many things in life are convenient, when looked at in an isolated manner, but cause inconvenience when seen in a global context or when carried to excess. > Well, we haven't yet seen a large scale deployment of an address > resolution server as in RFC 1577. IMO this will be just as convenient > and less bug-prone. We shall see. > > > on another matter, i note that Mike Gerard's note ends with > > "Multimedia Products making use of IP multicast can completely swamp > > an ethernet" > > > > this is a daft remark - if you want to send audio/video to n machines > > on an ethernet, NOT USING multicast is VERY bad for its health... I do not appreciate being called daft for making a true statement. What is daft is to ignore unpleasant truths because they do not happen to fit the case being argued. The preamble to my document clearly stated the context (a large bridged network) in which all multicasts go everywhere and have to be treated by everyone (and what is the overhead on systems which don't want the multicast: even if they can throw away the packet based upon multicast ethernet address there is still work involved). > Well, compared with N unicast streams that is of course true. The point > is that on a big network, N multicast streams can also swamp you. > This is mainly an argument against big networks though. Or for > ethernet switches. > > > > anyhow, like someone said, there's all that particle accelrator money, > > why can't they afford a multiprotocol router infrastructure? This shows a complete lack of understanding of why one might actually want bridged networks. Is what I call "Don't bother me with the facts, my mind is made up". In fact, it is an interesting thought that with LAN switches and ATM we are perhaps moving back towards a form of bridged networking again. We should be looking for a software and hardware infrastructure which combines the strengths of both philosophies. Actually, yes, we do want to go routing (and not just for IP), but we don't want to lose out on all the advantages of bridging. However, even given the sort of sums that you (wrongly) think we have available, routing is bl**dy expensive! Compare something like a "FDDI + 6*ethernet" bridge with the same as a router from Cisco, say, and you might understand. Consider also the "plug and play" style of a bridge with the "must have a specific configuration, possibly quite complex" style for a router. It is also a true remark that the switch to routing is far more difficult for IP than for such as IPX, appletalk or DECnet. After all, where else do I have to try to understand such things as variable length subnetting, helpers, routing etc., as well as considering how to let people move equipment around the site with a minimum of fuss. -- _ _ o | __ | jmg@dxcoms.cern.ch | | | | _ / \ _ __ _ __ _| gerard@cernvm.cern.ch | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. CN, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 13:41:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03090; Tue, 25 Oct 94 13:41:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03084; Tue, 25 Oct 94 13:41:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04578; Tue, 25 Oct 94 13:36:58 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA28907; Tue, 25 Oct 94 13:36:55 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA02866 for ; Tue, 25 Oct 1994 16:36:37 -0400 Date: Tue, 25 Oct 94 18:27:30 GMT From: "William Allen Simpson" Message-Id: <3330.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Some comment on Neighbor discovery in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) > In [Si-Di] page 6, the third alinea specifies: "on receipt of a General > Advertisement, all nodes....". When reading the rest I can never find > when a general advertisement should go to a single node or to > multiple nodes. Thank you for the consistency check. In the formats document, you will find field contents, rather than processing. The General Advertisement is (currently) merely reversed from the Solicitation. [formats p 7] However, this is a matter of debate. In trying to reduce the number of messages, it would be better to send the General Advertisement to all-nodes. This would prevent other nodes from soliciting as quickly. The most common pattern is client-server. One client solicits, and the server answers. If we unicast, then only that client will update its cache, and each other client will also solicit. This won't scale well to 1000 clients. Fixed. > I agree that reading the rest of the IPv6 specifications, (c) violates the > idea of don't bother stations that don't communicate with you. Which is why the current text reads: "... all nodes which have a Hop Cache entry for the Source update the cache entry .... Only those nodes communicating with the server will have a cache entry. > [Si-Di] page 21: > The use of the "Other Identifier" in a Routing Avertisement is > explained: > The sentence "The Other-Identifier extension ....... Cluster-prefix" was > not immediate clear to me. It took me some time to understand it > advertisements the other defined IPv6 addresses of this router. I kindly > ask you to add as a second sentence of this paragraph: > "That is: it advertises either the IPv6 addresses defined on the other > physical interfaces or other IPv6 addresses on the same interface but > outside the Cluster-prefix." > How about: The Other-Identifier extension is used to indicate IPv6 addresses bound to other interfaces of the node, or other IPv6 addresses on the same interface which are not subsumed by the same Cluster-prefix. > [Si-Di] page 19: > I don't understand the exact working of this Change-Identifier: Not surprising. It was originally for changing identifers for current TCP connections. The text on how to do this has not been written (it was waiting for the API, and for autoconfiguration). > If my end-node (non-router!) receives a change-identifier with Cluster- > prefix equals zero, does it mean: This advertizements changes my(!) > address? Yes, all your TCP connection blocks should change their address. > Is it then send as a (layer two) unicast to me? No. See formats. > If so: What should happen if a router sends it out and the packet is lost It will be sent until the LifeTime for that address expires. (The router won't know whether you have changed. There is no reply.) > If the prefix-size is non zero, and multiple Cluster-prefixes do exist on > the link: How do I know it is for me? Please read the formats.... > (c) Is it send as all node/host multicast Yes. > (d) Is it allowed to send such a message as a all-node intra-community > multicast???? (If someone wants to play games with the Internet). No. > On (c): With multiple cluster-prefixes on a link, how do I pick out the > right one. Huh? I think you may have missed the concept that every interface can have many (many many) addresses. > First and second paragraph on page 20: > Does it mean I get a temporary address on my station, so my address for > a while is the one that was advertised and after a while I have to forget > my own address? > All IPv6 addresses are temporary, and can change at any time. > [Si-Fo] page 27: > Transit Information, the first paragraph: > "For advertisements, this indicates that a router ......" > When reading page 8 of the same document, the "Transit Information"- > extension is not specified as a possible extension in the Router > Advertisement (neither in the Service Adv, nore in the General Adv). > Thank you for the careful reading. We eliminated this feature some time ago, and I missed the deletion. > [Si-Fo] page 28: > If an IPv6 header is 40 octets, why are the values on this page: > length 54 and > IPv6 header 48 octets? > An IPv6 header _is_ 48 octets! But that should be >= 54. Fixed. > In general I would like more explicitly things as: > when does a non-router send: > general solicitation > router solicitation > service solicitation > general advertisement > router advertisement (I know,never.... but to be complete) > service advertisement > mobile registration request > mobile registration reply Goodness, and some folks think there is too much detail.... Right now, all that is in the processing draft. Only formats are in the formats draft. Once upon a time, they were all in one draft, but people found that heavy going. This is the "byte-sized chunk" approach. > Also what to do on receiving each of those, I agree that much of that > information is already in the documentation, but I would like to see it > more explicitly in seperated paragraphs. > I could swear that there was a "validity checks" section for each type.... > what is several IPv6 addresses and cluster-prefixes are configured on > the router on the same physical interfaces, which one to take? ALL of them. > What if the routers advertisement tells me to make the Cluster-prefix > size lets say 120 bits, leaving me with a "auto-configured" eight bit > "unique" address? > HUH? You don't configure your own addresses -- the configuration server configures your addresses. (We learned from Novell's and Apple's mistakes.) The router tells you the size of the cluster so that you can make the local/remote hop decision. (See "Next Hop Decision" section). Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 25 20:39:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03416; Tue, 25 Oct 94 20:39:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03410; Tue, 25 Oct 94 20:39:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08340; Tue, 25 Oct 94 20:35:25 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA12553; Tue, 25 Oct 94 20:35:25 PDT Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA00969; Tue, 25 Oct 1994 23:35:21 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA21934; Tue, 25 Oct 1994 23:35:20 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA14074; Tue, 25 Oct 1994 23:11:53 -0400 Message-Id: <9410260311.AA14074@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, bsimpson@morningstar.com Subject: Re: (IPng) LL Multicast Last Hop In-Reply-To: Your message of "Mon, 24 Oct 94 01:12:46 GMT." <3323.bill.simpson@um.cc.umich.edu> Date: Tue, 25 Oct 94 23:11:53 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: sob@harvard.edu (Scott Bradner) > I'd like to get an understanding about how much saving this > latency means. > >..... > how important is this? how much is it worth adding in > complexity in order to reduce this latency? > The elimination of latency is only _part_ of the problem. As I was working on the Discovery today, I remembered another over-riding reason for using link-layer multicast to forward the IPv6 unicast datagram without waiting for Media Address resolution. Here's the scenario: ..... In resolving names that are in complete different and far away domain names, the resolutions is done at several levels away, which ensures that many if not the majority of querries get pretty much the same treatment. How come then, you see the problem apparently more often than others? Bad implementations, insufficient resources, bad configuring can happen separately or all together, and I wonder how much in your case is in reality the first, the second, the third, or various combinations of them. Did you try to debug this at any extent? We ran through all these arguments and more at the implementors meeting and the majority of people there and here on the mailing list thought that given the side effects of the written specification and of the other proposals, the old model can be considered as working OK, and therefore used in specifications. The solution: Send the unicast data as a "link-layer" multicast (as written), followed by the Where-Are-You. .... (I will wait for the firestorm a few days.) And then what? We know and discussed that basing the IPv6 reliability - which we can control at specification level - on the link layer reliability - which we do not control - IS BAD because it is braking the IPv6 self-contained robustness. The unorthodox combination of link-layer multicast with IP unicast as destination from your solution is BAD because it is opening the door for negative effects, in case of bad link adapters, or bad link layer implementations. Anyways, since you put this again up for discussion, we can discuss again also the model that has the advantages of the solution you described, but unlike that solution does not introduce any problems at addressing level - it uses link layer multicast with IP intra-link multicast for destination. This solution as the one I described at the implementors meeting, and here on the mailing list, is based on an "IPv6 extension header" and ICMP, allowing data pigyybacking on the 'solicitation message', but it has a very simple mechanism of avoiding the MTU related issue (the issue is that inserting the "IPv6 hop by hop option 'media address resolution request'" (MARR) may make the size of the IPv6 packet grow larger than the MTU). The mechanism consists in sending the user data and the solicitation extension header in one packet only when the total size of the packet is smaller than the MTU size. Small messages are the majority for the beginning of a communication, so sending the data and solicitation in one packet will occur in most cases. When the total size would be larger than the MTU, (packet size between MTU-Lext and MTU - see Lext definition bellow) the solicitation is sent without data, and the data packet gets queued to the address resolution cache entry for transmission when the media address response is received, similarly to the current IPv4 model. This case occurs with large messages, at the beginning of a communication, which in general is much more seldom than the previous case. Discussion: ---------- The inserting of the IPv6 MARR option adds to the size of the IPv6 packet: - a minimum of 20 bytes: 2 bytes - IPv6 hop by hop extension header (next hdr, and hdr ext len) 2 bytes - IPv6 option header (option type, and option data len) 16 bytes - target IPv6 address if the source media address is not sent with the request. - a maximum of 20 + 2 + (n) bytes: 2 bytes - IPv6 hop by hop extension header (next hdr, and hdr ext len) 2 bytes - IPv6 option header (option type, and option data len) 16 bytes - target IPv6 address 1 byte - media type 1 byte - media address length (n) bytes - media address (length specified by previous field) if the source media address is sent with the request. Considering: - the length of the extension header is: 20 =< Lext =< 22+n - the length of the IPv6 datagram is: L then the algorithm of sending a datagram is : if (L+Lext <= MTU) then send solicitation and IPv6 datagram in one packet. else send solicitation queue the IPv6 datagram for sending when the media address is resolved. endif .... receive_advertisment: if queue not empty then dequeue datagrams FIFO, and send endif The strategy for queueing the IPv6 packet should/could be similar to what good ARP implementations do or should do - Joachim Martillo enumerated a set of guide lines in an earlier message: - maintain a queue of a maximum number of data packets, per "unresolved" media address resolution cache entry (one per IPv6 destination). - a new data packet can be added to the queue, if the queue didn't reach its maximum size, or if it did, if the oldest data packet is dequeued, and deallocated. - when the "unresolved" entry times out, the queue of data packets is deallocated. - when the "unresolved" entry is transitioned to "resolved" state - upon receiving the media address reply, the data packets are sent FIFO to the destination IPv6 address. The packet formats would be: 1. Packet that contains both solicitation and data: IPv6: dst: IPv6 all nodes multicast with intra-link scope src: IPv6 address of interface NOTE: using the link-layer multicast and IPv6 intra-link all nodes multicast removes any confusion and/or problems related to unorthodox combination of destination link layer address/destination IP address. IPv6 ext hop by hop option: option: media address resolution request: target IPv6 address (source Media address) ... Transport header User data 2. Packet that contains only solicitation: IPv6: dst: IPv6 all nodes multicast with intra-link scope src: IPv6 address of interface IPv6 ext hop by hop option: option: media address resolution request: target IPv6 address (source Media address) The recipient of the IPv6 "media address resolution request" (MARR) hop by hop extension header, among other things, returns to the sender an ICMP message indicating the media address of the target IPv6 address, and then replaces the "all-nodes IPv6 multicast" address in the received IPv6 main header, with the destination "IPv6 unicast" from the MARR extension header for further processing, which continues as if the packet were sent with a unicast address. If the packet contains no data, then the processing ends. If the packet contains data, then tha processing continues at transport level - checksum calculation at source and destination is performed appropriately - and so on. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 05:45:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03580; Wed, 26 Oct 94 05:45:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03574; Wed, 26 Oct 94 05:45:30 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23359; Wed, 26 Oct 94 05:41:11 PDT Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA27873; Wed, 26 Oct 94 05:41:11 PDT Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Wed, 26 Oct 1994 05:41:10 -0700 From: bmanning@ISI.EDU Posted-Date: Wed, 26 Oct 1994 05:40:15 -0700 (PDT) Message-Id: <199410261240.AA05389@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 26 Oct 1994 05:40:15 -0700 Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof.Eng.Sun.COM Date: Wed, 26 Oct 1994 05:40:15 -0700 (PDT) In-Reply-To: <9410221600.AA01199@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Oct 23, 94 01:00:22 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 347 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Link layer is not necessarily point to point, if components have > unique MAC addresses. > but MAC addresses are not unique and can be changed at will. DECsupports this for DECnet, Sun supports this via the ifconfig setup, MAC and PCs have this ability for overriding the PROM... You can not assume an invariate, unique MAC address. --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 08:10:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03681; Wed, 26 Oct 94 08:10:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03675; Wed, 26 Oct 94 08:09:50 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29843; Wed, 26 Oct 94 08:05:30 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA16224; Wed, 26 Oct 94 08:05:30 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-21.dialip.mich.net [35.1.48.102]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA05116 for ; Wed, 26 Oct 1994 11:05:26 -0400 Date: Wed, 26 Oct 94 14:04:30 GMT From: "William Allen Simpson" Message-Id: <3340.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) LL Multicast Last Hop Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ah, a comment. Not a very helpful comment, but at least a comment. It would be best if people would not send to both the list and to a person on the list. Just clogs my link, and forces comparison of the messages before hitting the delete key. And new topics should be in separate messages with new subject lines. This one is supposed to be about "LL Multicast Last Hop". > From: conta@zk3.dec.com > In resolving names that are in complete different and far away domain > names, the resolutions is done at several levels away, which ensures that many > if not the majority of querries get pretty much the same treatment. How come > then, you see the problem apparently more often than others? > Because, my dear fellow, as I already explained, I am _only_ querying a list of default DNS servers. Those resolvers may go elsewhere for other domains, but _I_ always query the ones on my list. It's repeatable. > Bad implementations, insufficient resources, bad configuring can > happen separately or all together, and I wonder how much in your case > is in reality the first, the second, the third, or various combinations of > them. Did you try to debug this at any extent? > Sure Alex, over several years. Why else do you think that I can described the problem so thoroughly? How is it that everybody else's ideas must be because of "bad implementations, insufficient resources, bad configuring"? By this reasoning, the entire IP community must be incompetent. And as I said in my message, this only seems to occur with Cisco routers on high traffic links. Lots of people buy Cisco. Let me put it another way -- whatever we do has to be easy to implement, deal with few resources, and have no configuration what-so-ever. > We ran through all these arguments and more at the implementors meeting > and the majority of people there and here on the mailing list thought that > given the side effects of the written specification and of the other proposals, > the old model can be considered as working OK, and therefore used in > specifications. > No, we did not talk about the problems I raised here. The only issue raised was when YOU (and nobody else) complained that using link layer multicast with network layer unicast might, in a bad implementation, cause re-transmission to the unicast address when received by a router. (The unicast/multicast confusion issue was already noted in every draft since the first.) Several people pointed out that this was already forbidden in IPv4. It is not a problem! We agreed, however, that if the only issue was latency, it was not worth the trouble. Latency was also the issue raised on this list. I have raised new issues here (actually, remembered old issues): - link traffic - memory utilization - scaling Please stick to the issues. > We know and discussed that basing the IPv6 reliability - which we can > control at specification level - on the link layer reliability - which we > do not control - IS BAD because it is braking the IPv6 self-contained > robustness. The unorthodox combination of link-layer multicast with IP > unicast as destination from your solution is BAD because it is opening > the door for negative effects, in case of bad link adapters, or bad link > layer implementations. > Huh? This has nothing to do with the link layer implementation. The forwarding problem is entirely an IP implementation issue. Every link layer is required to indicate to the network layer the receipt of a braodcast or multicast address. Every router _I_ have worked on correctly passes this indication. This is _only_ an issue for routers. It makes no difference to hosts, since they don't forward. And this was Christian Huitema's idea. He contributed this to the draft long ago. Read the archives. (Also, Dino Farinacci suggested something similar to me privately.) Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 09:13:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03729; Wed, 26 Oct 94 09:13:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03723; Wed, 26 Oct 94 09:12:51 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04829; Wed, 26 Oct 94 09:08:31 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27624; Wed, 26 Oct 94 09:08:31 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-19.dialip.mich.net [35.1.48.100]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA10136 for ; Wed, 26 Oct 1994 12:08:24 -0400 Date: Wed, 26 Oct 94 15:01:24 GMT From: "William Allen Simpson" Message-Id: <3342.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) piggybacking Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: conta@zk3.dec.com > This solution as the one I described at the implementors meeting, and here on > the mailing list, is based on an "IPv6 extension header" and ICMP, > allowing data pigyybacking on the 'solicitation message', but it has a very > simple mechanism of avoiding the MTU related issue (the issue is that inserting > the "IPv6 hop by hop option 'media address resolution request'" > (MARR) may make the size of the IPv6 packet grow larger than the MTU). > Alex, you raised this twice at the meeting. It was initially rejected by general murmer, and then you asked reconsideration at the end of the meeting. It was rejected again more vociferously. On the surface, it is seductive to me, since it reduces traffic. Reducing traffic is a primary evaluation criteria for Discovery, right after multicast. But there were too many fatal flaws: 1) IPv6 architecture: It is contrary to the IPv6 design to add an intervening header at a router. We don't do this for Fragmentation anymore, or anything else. It would have to be done at the source. This would only work for local traffic at the first hop. The source doesn't know when the lifetime expires at a remote link. 2) Authentication: Adding an intervening header at a router would break the current authentication proposal, and open the door to many abuses. 3) MTU Discovery: Adding an intervening header at a router would break MTU discovery. Your solution to only add the header on shorter than MTU sized packets is based on faulty reasoning. You assume that streamed (TCP) packets are the dominant form of traffic, and that most initial packets are less than MTU sized. In fact, most traffic (at the final hop) is UDP, not TCP. NFS and DNS account for over half the traffic on a Unix or PC LAN. Multicast is largely UDP at this time. Also, good TCP implementations for years have carried data in the SYN packet. They are already MTU sized. 4) Extension size: Your maximum estimation is simply wrong. You assume that we don't use the Discovery extensions. Whether you like them or not, they are each and every one required in some environment with which we have practical experience. I was complimented by several folks on my flexibility for including or changing features in Discovery. But, entirely dropping these years of work would _really_ set me off.... 5) Holding packets: holding the datagram while waiting for the ARP reply has never worked well. Holding packets takes memory. The criteria clearly state that the solution must have "low" storage overhead. This will not scale to hundreds or thousands of nodes. 6) Loss of data: when the Hop Cache is thrashing, say on Brian's 2000 node bridged LAN talking through one router, no data is sent. The entire LAN consists of nothing but resolution requests. 7) Excessive congestion: buffering multiple packets until the reply is received causes massive congestion on receipt of the reply. Even those ARP implementations which buffer anything today, buffer no more than one packet. 8) Uses "all-nodes" multicast on the request: this will cause too many problems with sleeping mobiles. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 17:27:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04585; Wed, 26 Oct 94 17:27:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04579; Wed, 26 Oct 94 17:27:22 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01119; Wed, 26 Oct 94 17:23:01 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA08724; Wed, 26 Oct 94 17:22:50 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 10:17:33 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 27 Oct 1994 10:21:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 12:22:18 +1000 Date: Thu, 27 Oct 1994 12:22:18 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941027 11:17:52 061] X400-Content-Type: P2-1984 (2) Content-Identifier: 941027 11:17:52 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941027 11:17:52*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday.. dan.. totally agree... I did say its is A way of using an NSAP carrying a MAC.. but as you say it is not the best.. I also agree that some ARP/ ICMP address resolution mechanisim is needed for X.25/ISDN and MAC networks needs to be developed.. hence some of my previous comments on the ARP debate.. Thanks .. Agreeable Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 18:00:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04637; Wed, 26 Oct 94 18:00:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04631; Wed, 26 Oct 94 18:00:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03272; Wed, 26 Oct 94 17:56:17 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA14350; Wed, 26 Oct 94 17:56:10 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 10:49:59 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 27 Oct 1994 10:53:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 12:53:58 +1000 Date: Thu, 27 Oct 1994 12:53:58 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng@sunroof2.Eng.Sun.COM X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941027 11:01:59 065] X400-Content-Type: P2-1984 (2) Content-Identifier: 941027 11:01:59 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941027 11:01:59*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng@sunroof2.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) RE: (IPNG) RE: (IPNG) RE: (IPNG) PACKS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM gday tony .. I understand.. the abstraction bit.. And Subnet instead of cluster is fine by me As a newcomer to the IETF (and having a long working history with "Kings and Votes" .. and still do) I am still in "observing mode" and trying to participate..hopefully more positively than I did a few months ago.. I am still curious why putting in comments on documents (some of which I feel are quite fundamental - eg flow ids, addressing, etc) do get little response..anyway..chin up and keep smiling.. I would still like to know if this addressing business (re terms and administration) is resolved.. or is on the agenda for December.. You never know I might be brave enough to come... Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 19:45:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04709; Wed, 26 Oct 94 19:45:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04703; Wed, 26 Oct 94 19:45:01 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09063; Wed, 26 Oct 94 19:40:40 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA28435; Wed, 26 Oct 94 19:40:10 PDT Received: from X400 by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA09848; Thu, 27 Oct 1994 12:39:15 +1000 (from /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au) From: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au Received: by cms.datacraft.com.au (5.65/1.2-eef) id AA15985; Thu, 27 Oct 94 12:37:59 +1000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 27 Oct 94 14:36:36 +0000 X400-Received: by mta dcpmel in /ADMD=telememo/C=au ; Relayed ; 27 Oct 94 14:36:36 +0000 X400-Received: by /ADMD=TELEMEMO/C=AU ; Relayed ; 27 Oct 94 14:36:36 +0000 Date: 27 Oct 94 12:37:59 +1100 Delivery-Date: 27 Oct 94 12:37:59 +1100 Message-Type: Multiple Part X400-Originator: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400 X400-Mts-Identifier: [/ADMD=TELEMEMO/C=AU;dcpmel 941027 12:30:15 069] X400-Recipients: ipng@sunroof.eng.sun.com Original-Encoded-Information-Types: IA5-Text Message-Id: <941027 12:30:15*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS> Importance: normal Subject: (IPng) NOSI BOF - STRONG COMMENTS Autoforwarded: FALSE To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Priority: normal Conversion: Allowed Conversion-With-Loss: Allowed Content-Identifier: 941027 12:30:15 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM GDAY.. BRIAN, EVERYONE.. I HAVE JUST RXD COPIES OF STRONG EXCHANGES - RE General: I am concerned that if all that IP6 will offer "is a convergence path from NSAPs to IP6 addressing"... I for one will get the message about the collaboration.. If others would like to see interoperation between the NSAPs and IP6 (which I keep stating WILL have to be implemented anyway) then the direction must be one of "interoperation of IP6 addresses with NSAPs"..and let those who deal with NSAPs know how this is best served. So I would like to participate in the BOF.. but if the directive is one of "take what you get" ..then what is the point.. COMMENTS on the NOSI It is easy to talk of layers and bytes of addressing and the way tunnels can be used....However, we are talking of GLOBAL ADDRESSING SCHEMES here.. not just a pack of bytes on the wire and the best way of bending them .. Addressing schemes DICTATE how networks are designed.. their design methodology, their administration and the way in which they can be deployed across this planet. My previous comments:: There is no point in having an addressing scheme for global addressing that cannot be administered globally.. AND is recognised globally and is KNOWN to be SAFE..... One cannot build infrastructure networks, defence networks, aviation networks, maritime networks that have to operate on the basis of a "cluster".... One needs strong allocation of address fields, universal recognition of numbering plans and allocation methodology, formal procedures... other wise.. a pile on unusable, unmanageable, unsafe, unaccountable technology will result... Nobody wants that today.... The nosi document does not mention the fact that NSAPs include carrier numbering plans which we ALL rely on.. The nosi document does not indicate that there are official procedures and registration mechanisms all over this planet for administering NSAPs, X.400 MDs, OIDs, and X.500 MDs.. WHICH ARE BEING USED......FOR BIG NETWORKS.. The nosi document does not detail how aircraft, shipping and transport networks might work.. without the globally administrered addressing schemes and procedures already in place.. (devices that rely on "Organisation" "Geography" "Regions" ) Nor does the nosi document say what it is going to do about incorporating carrier numbering plans and NSAPs that are used in ISDN, B-ISDN signalling.. and their mapping.. Yes the document is a discussion document.. and Yes the Internet will run native IP6... But...if the dream is to promote the scrapping of NSAPs and carrier numbering plans and replace them with IP6 addressing.. some reality (and costs) should be considered.. not just the view of 16 vs 20.. It would be nice if IP6 = the internetworking service and there is a choice of address administration ie.. Internet followers use native IP6 addressing.. Others .. use NSAPs. Responses are welcome.. emotional or otherwise.. simply because if this area is a "bytes on the wire debate" God help us...any bodies god.... Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 20:30:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04721; Wed, 26 Oct 94 20:30:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04715; Wed, 26 Oct 94 20:30:18 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11193; Wed, 26 Oct 94 20:25:58 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA04459; Wed, 26 Oct 94 20:25:58 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA02215; Wed, 26 Oct 94 20:20:09 -0700 Received: by xirtlu.zk3.dec.com; id AA01322; Wed, 26 Oct 1994 23:20:03 -0400 Message-Id: <9410270320.AA01322@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NOSI BOF - STRONG COMMENTS In-Reply-To: Your message of "27 Oct 94 12:37:59 +1100." <941027 12:30:15*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS> Date: Wed, 26 Oct 94 23:19:57 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, Here is my impression of what is happening here, and Brian can correct me (please) if I am misunderstanding anything. I am coming to that BOF with the intent we have two issues: 1) What can be done from IPv6 regarding the present allocation of NSAP addressing allocation? We have several ideas on the table. 2) Is there a need for a CLNP to IPv6 transition plan? Each point will have discussion and I hope the two issues are not discussed as one issue. I for one will want to know why in each of the above cases it needs to be discussed too. Then we can discuss the technical approaches outlined in Brian's draft of the BOF as background information too (which is very good to have for a meeting of this nature). But I doubt anyone will dictate anything and this BOF only determines if future work in the IETF is required. It is not to make a decision. So by coming you have the option of influencing whether future work is to be pursued in the IETF regarding CLNP Transition. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 21:00:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04743; Wed, 26 Oct 94 21:00:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04737; Wed, 26 Oct 94 21:00:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12076; Wed, 26 Oct 94 20:56:22 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA07332; Wed, 26 Oct 94 20:56:18 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 13:51:23 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 27 Oct 1994 13:55:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 13:57:38 +1000 Date: Thu, 27 Oct 1994 13:57:38 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Oct 27 13:57:37 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 375713271094 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <375713271094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: (IPng) NOSI BOF - STRONG COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 ---------------------------- Forwarded with Changes --------------------------- From: /DT=RFC-822/DV=owner-ipng%sunroof2@Sun.COM/O=AARN/ADMD=TELEMEMO/PRMD=OZ.AU/C=AU at DOF-X400 Date: 10/27/94 12:37PM To: Jeff Latimer at DOF-ITB Subject: (IPng) NOSI BOF - STRONG COMMENTS ------------------------------------------------------------------------------- ------------------------------ Start of body part 2 >GDAY.. BRIAN, EVERYONE.. I HAVE JUST RXD COPIES OF STRONG EXCHANGES - RE >General: >I am concerned that if all that IP6 will offer "is a convergence path from >NSAPs to IP6 addressing"... I for one will get the message about the >collaboration.. I would take the point further and say that work needs to cover how to take CLNP out and replace it with IP6. It should be able to operate in a native IP6 network as well as interoperate with OSI networks (using the dreaded NSAP). For that matter, my thoughts on collaboration were to sort these issues out while strengthening the results in both areas. >If others would like to see interoperation between the NSAPs and IP6 (which I >keep stating WILL have to be implemented anyway) then the direction must be >one of "interoperation of IP6 addresses with NSAPs"..and let those who deal >with NSAPs know how this is best served. The focus on the 20 byte NSAP issue may well be of the moment. Good work has been done to try and resolve the issue somewhat, Hop-by-Hop etc. I have a concern that if there is not a means to carry other addressing formats then we are, today, constraining networks of the future. >Regards Alan@Oz Regards Jeff ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 23:22:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04785; Wed, 26 Oct 94 23:22:24 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04690; Wed, 26 Oct 94 19:01:06 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07078; Wed, 26 Oct 94 18:56:46 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA24018; Wed, 26 Oct 94 18:56:40 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA27231; Wed, 26 Oct 94 18:51:07 -0700 Received: by xirtlu.zk3.dec.com; id AA00504; Wed, 26 Oct 1994 21:51:01 -0400 Message-Id: <9410270151.AA00504@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RE: (IPNG) RE: (IPNG) RE: (IPNG) PACKS Date: Wed, 26 Oct 94 21:50:55 -0400 >From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan spawned something I am noticing. We are moving very very slowwwwww. But one help is something Bill Simpson and I keep trying to do anyway and I want to repeat it one more time. If sub-topics enter a discussion move it to a different subject title. And please again do not copy folks on the cc list unless your sure they are not on the ipngwg list and please do not cc the ipngwg list again. Reduced mail inboxes (I use MH) will help me keep moving at a good pace. )---> thanks sorry for the rhetoric. >I am still curious why putting in comments on documents (some of which I feel >are quite fundamental - eg flow ids, addressing, etc) do get little >response..anyway..chin up and keep smiling.. I think we are stuck on a few basics that I think are about to break through. System Discovery, Autoconfig, and the topology model and who has knowledge of it in IPv6 as far as nodes. This is core technology. Transition is very quiet on ngtrans and I am not sure what that means but I hope it means we are very close to consensus on the overview document. The API document seems to be fairly solid now a few of us need to implement it but we need the lower layers to make that have purpose. Flows. This is new territory IMHO. >I would still like to know if this addressing business (re terms and >administration) is resolved.. or is on the agenda for December.. I think the architecture and plan (Yakov and Bob H) is fairly specified but administering it has only been suggested as part of Yakov et als work. >You never know I might be brave enough to come... I find the tigers on the mail to be very bright and gentle people for the most part in person except for me I am always intense (just kidding). You should come as your doing the real homework for the meetings. I hate when people come to meetings and have not read the specs. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 23:24:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04801; Wed, 26 Oct 94 23:24:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04795; Wed, 26 Oct 94 23:24:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15880; Wed, 26 Oct 94 23:20:21 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA17519; Wed, 26 Oct 94 23:20:19 PDT Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA25416; Thu, 27 Oct 1994 02:20:16 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA02737; Thu, 27 Oct 1994 02:20:14 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA14873; Thu, 27 Oct 1994 01:56:47 -0400 Message-Id: <9410270556.AA14873@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, bsimpson@morningstar.com Subject: Re: (IPng) piggybacking In-Reply-To: Your message of "Wed, 26 Oct 94 15:01:24 GMT." <3342.bill.simpson@um.cc.umich.edu> Date: Thu, 27 Oct 94 01:56:47 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: "William Allen Simpson" Subject: (IPng) piggybacking > From: conta@zk3.dec.com > This solution as the one I described at the implementors meeting, and here > the mailing list, is based on an "IPv6 extension header" and ICMP, > allowing data pigyybacking on the 'solicitation message', but it has a very > simple mechanism of avoiding the MTU related issue (the issue is that inser > the "IPv6 hop by hop option 'media address resolution request'" > (MARR) may make the size of the IPv6 packet grow larger than the MTU). > Alex, you raised this twice at the meeting. It was initially rejected by general murmer, and then you asked reconsideration at the end of the meeting. It was rejected again more vociferously. Not that it is important technically, but your recallection is not accurate. I raised once the issue of IPv6 robustness, which is what I care the most about, and because of the time constraints at the end of the first day, we continued the discussion before the end of the meeting. The first time well after Steve's remark related to the "leaky routers", which he made when he heard your multicast/unicast combination. I offered an alternative which would not create a problem like yours does. Steve D. mentioned he thought about using encapsulation. We didn't finish the discussion because we had to leave the room, so we continued towards the end of the meeting, which you call it the second time. Fine, the second time, I said that if we dont't solve the robustness problem, we should stick with a model that we know works well in most if not all cases, You forced the questions in such a way that the answer would imply automatically your choice, to which I refused to answer. Scott B. reformulated the question, and the majority of people in the room considered that the ICMP request/reply with queueing of the data packet is OK. ... In fact I do not understand you Bill! You complained so many times about and built your case on CISCO's not following RCF1122 in queueing data on ARP requests, and you think that relying on correct link adapters, and link implementations in routers for IPv6 address resolution robustness, based on RFC1122 is just fine. This is ridiculous! On the surface, it is seductive to me, since it reduces traffic. Reducing traffic is a primary evaluation criteria for Discovery, right after multicast. Traffic, memory consumption, latency. But there were too many fatal flaws: You raise a couple of issues that need attention, but none are fatal IMO: 1) IPv6 architecture: It is contrary to the IPv6 design to add an intervening header at a router. We don't do this for Fragmentation anymore, or anything else. IPv6 architecture is the IP architecture. We are in the process of working on the IPv6 design. Hop by hop options can be extended to allow options that can be inserted anywhere in transit, and dropped at the next hop right after their first processing. This type of options could be useful in the future for other things than address resolution. It would have to be done at the source. This would only work for local traffic at the first hop. The source doesn't know when the lifetime expires at a remote link. In light of the previous it would work anywhere. 2) Authentication: Adding an intervening header at a router would break the current authentication proposal, and open the door to many abuses. Wrong. I was so tempted to paraphrase you "DID YOU READ MY SPECCCC?", but I didn't (-:. Page 8 of the IPv6 Specification states that setting the 3-rd highest bit would exclude the hop by hop option from integrity computation, when an Authentication header is present. Abuses? What abuses? The IPv6 layer (system) generates such hop by hop extension headers. Noone else. An unprivileged user would not have direct access to issueing a packet with such a header. A privileged user should be allowed - similar to current ARP implementations - indirectly, through a system call the sending of a "media address resolution solicitation". 3) MTU Discovery: Adding an intervening header at a router would break MTU discovery. You don't say how. In any case I strongly disagree. You perhaps didn't read carefully what I wrote - no paraphrase. The inserting of a hop by hop extension header is done only on packets on which the inserting does not make the packet exceed the MTU. So, the size increase of the packet does not touch "the forbiden fragmentation zone". Your solution to only add the header on shorter than MTU sized packets is based on faulty reasoning. You assume that streamed (TCP) packets are the dominant form of traffic, and that most initial packets are less than MTU sized. That's my conclusion, and not assumption, that most first packets are small packets. That is based on facts and not faulty reasoning, see bellow. I add the header to packets shorter than MTU - extension header size. In fact, most traffic (at the final hop) is UDP, not TCP. NFS and DNS account for over half the traffic on a Unix or PC LAN. Multicast is largely UDP at this time. Only the first packets are relevant for this discussion. And you are wrong in both DNS and NFS case. The majority of DNS first packets are small - if we talk name resolution, or not; zone transfers may be large packets. but that is TCP, so first packets are small. NFS first packets are also small - because its stateless nature, the start of an NFS operation requires several small packets, before the pure data transfer (disk blocks) which may involve large packets may occur. The large packets are not relevant for this discussion, because large packets as first packets are an exception rather than the rule. Furthermore, they are usually sent in a burst, which is usually shorter in time than a media address resolution cache entry lifetime, which makes also the address resolutionin the middle of a large packet communication more an exception than a rule. And by the way, were you talking about your network? For any type of packets, in general, I can talk about several engineering LANs that abund in large systems, workstations and PCs. In number of packets, the TCP traffic is heavier than UDP - lots of control packets for unidirectional TCP traffic, and small packets. Statistically, if you monitor packets from 0 to MTU size, there is a larger peak of small packets (about 40-50%), a smaller peak of large packets (about 25-35%), and a very small peak of medium size packets (5-15%). Also, good TCP implementations for years have carried data in the SYN packet. Wrong. Good TCP implementations should always carry SYN in a control packet - no data. Becuse applications transmits are expensive, in system time, and in a multi-user system, you do not to spend system time and network bandwidth - in transmits and retransmits - before you know that a TCP connection is successfuly established. One packet lived TCP connections are exceptions, and a bad choice for TCP communications. They are already MTU sized. Are you talking about TCP implementations that hold transmit data in MTU size buffers that are pre-prepared TCP segments? I know one that when the receive window advances in small amounts, the data from the beginning of the buffer is transmitted each time a new chunck of data smaller than the size of the buffer fromwithin the buffer has to be transmitted, regardless of how much data from the front of the buffer was acknowledged before? This is wrong! The TCP is stream oriented not record oriented, and so the sizing of how much user data is put in a TCP segment is done dynamically, based on available receiver window, and other criteria, without any pre-set sizes. In a good TCP implementations it should not matter how you hold the data. In the middle of a TCP connection, the window size, or the IP options may vary - I can define and redefine IP options such as source routing - in such a way that the amount of user data may be different from one TCP segment to another. Adding a 'solicitation hop by hop header' in case the address resolution cache does not have information about the destination host, to the criteria of calcu- lating how much user data is put in the TCP segment is quite easy. The existence of the other extension headers have to be checked for each TCP segment, or rather the size of the IPv6 extension headers has to be part of the TCP segment user data size calculation formula anyways, so just add the "address resolution extension header" when it is needed. 4) Extension size: Your maximum estimation is simply wrong. You assume that we don't use the Discovery extensions. Whether you like them or not, they are each and every one required in some environment with which we have practical experience. In an address solicitation you need to put the minimum, which is the destination IP address, and the media address of the sender interface. Anything else that you put in your general solicitation, i.e. system heard can go separately in an ICMP packet. I was complimented by several folks on my flexibility for including or changing features in Discovery. But, entirely dropping these years of work would _really_ set me off.... Bill, I complemented you too. You were flexible with many of the things I suggested in our work off-line. I complemented for the work too! Didn't I have several "Excellent" in my comments sent to you? And we agree in most if not all of the discovery criteria - where we disagreed you heard me, since we spent quite a bit of time off-line on this, or you bitched at me for my mail clogging your poor links (-:. At a personal level I understand, and am with you. There is a lot of good or excellent work there. But objectively, there is a lot more work to do. and the amount of time spent before, should not matter when we talk about the quality and reliability of the NEXT GENERATION of the INTERNET PROTOCOL. Besides, nobody asks you to change anything else than what has to be changed to make sure that IPv6 is ROBUST at least as IPv4. 5) Holding packets: holding the datagram while waiting for the ARP reply has never worked well. I have and had many years of a different experience than yours in this respect. I know plenty of people that share the same exprience as mine. Holding packets takes memory. The criteria clearly state that the solution must have "low" storage overhead. This will not scale to hundreds or thousands of nodes. My solution requires for packets smaller than "MTU - size of extension header" NO MORE memory than the solution specified in your draft - this is for the first packets which is by enlarge the absolute majority of packets - I would say more than 80%. My solution requires for packets that are larger than "MTU - size of extension header", which are the minority of packets, NO MORE memory than the current IPv4 ARP solution. THis is for the first packets, which is the minority of packets - less than 20%. Ad sumum, and statistically, the memory required is less than 20% halph current IPv4 ARP. I think that getting about 80% or more of what you would get with the specified solution, but with no impact on robustness, I think it is a much better deal than getting all the memory for loss of robustness. Nota bene that for the majority at the implementors meeting - with your exception - the ARP memory consumption was OK, while loss of robustness was not. 6) Loss of data: when the Hop Cache is thrashing, say on Brian's 2000 node bridged LAN talking through one router, no data is sent. The entire LAN consists of nothing but resolution requests. I do not understand what you're trying to say, and heard Brian and his collegue complaining about ARP broadcast storms - which is fixed in IPv6. If you are talking about bad configured networks, it is common sense not to cram a family of 10 in a Trabant. 7) Excessive congestion: buffering multiple packets until the reply is received causes massive congestion on receipt of the reply. Even those ARP implementations which buffer anything today, buffer no more than one packet. I disaagree with your ABSOLUTE statement. It MAY cause congestion for foreign destinations. For local destinations, according to many, it is better to send as much data as you can, preferable at a packet gap equal to the packet gap allowed by the link protocol. I do not have strong feelings about this though, therefore, and for your liking of ARP with 1 queued packet, I agree to make the number of packets buffered a paremater with a default value of 1, or if it comes to that, simpler always 1. Actually I liked the setable parameter because it would allow those who prefer a certain router behavior you mentioned rightfully so many times, to set it to 0 (-: (by the way Cisco will fix it, I was told in version 10.2). 8) Uses "all-nodes" multicast on the request: this will cause too many problems with sleeping mobiles. You're right, we know better than that. Since we know that a packet goes to a local destination or a foreign destination, we can use intra-link all hosts for local destination, and intra-link all routers for foreign destination. The usefullnes versus costs of the hashing was questioned by many, including Steve D., so I hope you recall that. Bill.Simpson@um.cc.umich.edu I want to make this clear once more. I want the IPv6 discovery specifications to be correct and have as result a robust IPv6 implementation. I agree with most of the discovery requirements, but so far the mechanism suggested is not robust to a level I can consider satisfactory. Between a packet loss, ala Cisco router, and packet duplication in case of bogus forwarding, I chose the packet loss, because I can correct it with retransmission. Packet duplication I can correct only with a reliable protocol. The impact on unreliable protocols, on certain applications can be null, on others can be drastic. Therefore in my view, packet loss is acceptable, while accidental duplication is unacceptable. In this respect, and others there is more work to do on the discovery specifications, and I hope that that work will be completed. Alex Conta P.S. Trabant used to be before 1989, the cheapest and a very popular car in Eastern Europe, manufactured in East Germany. Of a sub-compact size, it could sit 4 (better 2 adults and 2 children), it was powered by a 2 cylinder, 600cc, 2 stroke engine, that developed about 30HP/DIN, 4 speed, front wheel drive. It had also apparently a military version. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 23:44:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04846; Wed, 26 Oct 94 23:44:14 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04840; Wed, 26 Oct 94 23:44:07 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA27364; Wed, 26 Oct 94 23:39:48 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA19057; Wed, 26 Oct 94 23:39:44 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 16:34:59 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 27 Oct 1994 16:38:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 18:39:07 +1000 Date: Thu, 27 Oct 1994 18:39:07 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941027 17:01:59 076] X400-Content-Type: P2-1984 (2) Content-Identifier: 941027 17:01:59 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941027 17:01:59*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) NOSI BOF - STRONG COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM jim, thanks for the response. The points you raise again seem biassed toward NSAPs migrating to IPv6. However, I take the point that the NSAP / IP6 issue should be discussed and then the follow on issues dealt with. Is the point of developing IPv6 as a common Internetworking protocol (with its supporting mechanisms such as ARP, ICMP, Discovery, etc) and permitting the two address forms of Internet 16 and NSAPs out of the question. If it is not then I feel can participate in this issue and also in the transistion/ integration issues of IP4 to IP6, CLNP/NSAPs to IP6, IP4 to CLNP/NSAPs and IP6 to CLNP/NSAPs without bias of who's technology is the best. I prefer this balanced approach because these are the networking issues that will have to be dealt with. Specifically registration and mapping. A dream I have is that the IP 6 addresses could be administered through the ISO channels for the IETF along with NSAPs. Just a dream. The topics of the BOF (for your first point) could be: The address forms, their administration issues, their syntax and mapping. Followed on by routing issues, tunnelling, router profiles, etc. Will the scope or agenda for the BOF be firmed up in any way? Regards Alan PS your other mail arrived. re tigers. grr! PPS I suppose a (new/hidden) rule of BOFs is the Aussies buy the beers. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 26 23:57:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04894; Wed, 26 Oct 94 23:57:33 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04888; Wed, 26 Oct 94 23:57:27 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA27669; Wed, 26 Oct 94 23:53:08 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA19907; Wed, 26 Oct 94 23:52:57 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 16:48:15 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 27 Oct 1994 16:52:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 27 Oct 1994 18:54:07 +1000 Date: Thu, 27 Oct 1994 18:54:07 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941027 17:44:55 079] X400-Content-Type: P2-1984 (2) Content-Identifier: 941027 17:44:55 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941027 17:44:55*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) PIGGYBACKING Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This one I agree with bill. I think that having native protocols (not gateways functions) which are instigated from one point in the network, operate at two different levels, are directed at two different functions which may or may not be in the same machine and where there is an option of responses arriving in different order and a possibility that none, one or both may error / fail to arrive at the originator, does not make good network engineering. This may be over stating the problems of the piggyback mechanism but piggybacking protocol interactions makes the cure worse than the problem. regards alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 00:30:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04958; Thu, 27 Oct 94 00:30:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04952; Thu, 27 Oct 94 00:30:28 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17309; Thu, 27 Oct 94 00:26:07 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA25541; Thu, 27 Oct 94 00:26:00 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16114; Thu, 27 Oct 1994 08:25:58 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21186; Thu, 27 Oct 1994 08:25:56 +0100 Message-Id: <9410270725.AA21186@dxcoms.cern.ch> Subject: Re: (IPng) NOSI BOF - STRONG COMMENTS To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Thu, 27 Oct 1994 08:25:56 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410270320.AA01322@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Oct 26, 94 11:19:57 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 766 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Let's bash the agenda before we bash the issues. > The order of discussion should be > > 1 - agree on general conversion requirements > 2 - agree on major network layer scenarios. > 3 - only then, identify which mechanisms are useful. Can we please concentrate on 1) for now? I too fell into the trap of going straight to 3), e.g. wondering how to handle NSAP addresses. But this is not good engineering and it doesn't address the bottom line, i.e. finding the most cost-effective solution for the customer. So if you want to start the BOF here, please comment on the general conversion requirements. BTW I will be off-net from tonight for 10 days. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 03:10:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05101; Thu, 27 Oct 94 03:10:42 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05095; Thu, 27 Oct 94 03:10:34 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA05715; Thu, 27 Oct 94 03:06:15 PDT Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA10110; Thu, 27 Oct 94 03:05:58 PDT Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27729 Thu, 27 Oct 1994 20:05:30 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.Sun.COM Subject: (IPng) IPv6 sample implementations Date: Thu, 27 Oct 1994 20:04:10 +1000 Message-Id: <11061.783252250@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Can someone point me to an IPv6 implementation (as far as anything exists so far, of course) that's available for one of the unix variants for PC (ie: [34]86) class machines? I'd like to do some experimenting with some ideas before everything is totally set in concrete (ie: in the next month or so). I'd prefer not to have to start from nothing though. I'd kind of prefer a BSD/OS (BSDi) base, but NETbsd or whatever will do if that's what people have been using. Private replies probably make most sense here (so you'll have to edit the headers to undo the nonsense that majordomo does). Thanks, kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 06:01:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05144; Thu, 27 Oct 94 06:01:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05138; Thu, 27 Oct 94 06:01:39 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01023; Thu, 27 Oct 94 05:57:17 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA21896; Thu, 27 Oct 94 05:56:50 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA03203; Thu, 27 Oct 94 05:50:36 -0700 Received: by xirtlu.zk3.dec.com; id AA27798; Thu, 27 Oct 1994 08:50:28 -0400 Message-Id: <9410271250.AA27798@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RE: RE: (IPNG) NOSI BOF - STRONG COMMENTS In-Reply-To: Your message of "Thu, 27 Oct 94 18:39:07 +1000." <"941027 17:01:59*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Date: Thu, 27 Oct 94 08:50:21 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, First - I agree with Brian the 1st order of business is to agree on general conversion requirements. > thanks for the response. The points you raise again seem biassed toward >NSAPs migrating to IPv6. However, I take the point that the NSAP / IP6 issue >should be discussed and then the follow on issues dealt with. I agree with your order. As far as biased thats not really the right word. We have learned that most of the NSAP allocations have not been deployed. Hence, a point of discussion is the migration to IPv6 addresses. The cost to do this will be cheaper than the cost to translated NSAPs into IPv6. But I am not convinced this is the right view and look forward to the BOF. >Is the point of developing IPv6 as a common Internetworking protocol (with >its supporting mechanisms such as ARP, ICMP, Discovery, etc) and permitting >the two address forms of Internet 16 and NSAPs out of the question. I don't understand your question? If NSAPs are mapped into IPv6 addresses then by default they are used by the rest of the protocol suite. I agree and outstanding question is what that mapping looks like and how will it affect discovery and autoconfig. But I don't want to spend cycles on this until we have the BOF. >If it is not then I feel can participate in this issue and also in the >transistion/ integration issues of IP4 to IP6, CLNP/NSAPs to IP6, IP4 to >CLNP/NSAPs and IP6 to CLNP/NSAPs without bias of who's technology is the best. I can't parse this sentence? I don't get the concern or the meaning of the above sentence? >I prefer this balanced approach because these are the networking issues that >will have to be dealt with. Specifically registration and mapping. >A dream I have is that the IP 6 addresses could be administered through the >ISO channels for the IETF along with NSAPs. Just a dream. Well I assume Jack Houldsworth is working with the Chairs of the Internet Society and the IESG and the IETF-INET liaison to SC6 on administration. That I don't think should be part of a technical discussion. >The topics of the BOF (for your first point) could be: >The address forms, their administration issues, their syntax and mapping. >Followed on by routing issues, tunnelling, router profiles, etc. Well the topics may drift this way but as I said in the beginning I agree with Brian what are the conversion requirements. And maybe there are none after we hear all the input is another position. But we need to hear all voices and their concerns. >Will the scope or agenda for the BOF be firmed up in any way? FYI we are way ahead of the game for most BOFs and Brian has given us a good start. Welcome to the IETF BOF world. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 06:16:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05156; Thu, 27 Oct 94 06:16:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05150; Thu, 27 Oct 94 06:16:31 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01562; Thu, 27 Oct 94 06:12:10 PDT Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA23276; Thu, 27 Oct 94 06:12:11 PDT Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA04253; Thu, 27 Oct 94 06:07:30 -0700 Received: by xirtlu.zk3.dec.com; id AA29657; Thu, 27 Oct 1994 09:07:21 -0400 Message-Id: <9410271307.AA29657@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RE: RE: (IPNG) PIGGYBACKING In-Reply-To: Your message of "Thu, 27 Oct 94 18:54:07 +1000." <"941027 17:44:55*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Date: Thu, 27 Oct 94 09:07:15 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, >This one I agree with bill. I think that having native protocols (not >gateways functions) which are instigated from one point in the network, >operate at two different levels, are directed at two different functions >which may or may not be in the same machine and where there is an option of >responses arriving in different order and a possibility that none, one or >both may error / fail to arrive at the originator, does not make good network >engineering. This may be over stating the problems of the piggyback mechanism >but piggybacking protocol interactions makes the cure worse than the problem. Could you be technically more specific why you agree with Bill. I am following Bill and Alex discussion very carefully trying to understand the implementation issues. We have piggybacking in either case: hash unicast into multicast or unicast as hop-by-hop in all hosts multicast in some cases. So I can take your vote more seriously could you talk to the technical statements Bill vs Alex. I know this is hard and I am not trying to be difficult, but we have two very good IP lower-layer implementors debating about actual engineering code implementations and support pro or con on this subject I would like to see reflect the technical points made in the discusion. Otherwise I must dismiss it as "hand waving" (this means its just a feeling as opposed to concrete technical analysis). Its OK to express feelings IMHO but I just need to separate the two kinds of input for this discussion. Thanks. I won't go into the architectural philosophy of piggybacking in general, but I believe there are times to implement a function that way but you must be careful it will perform and be de-capsulated enroute in all places as required, and that at each point where it is seen it can be managed (meaning that which needs to technically be aware of the overload will understand the affect of the data piggybacked). This would be another subject line for the mail list and I am not sure useful. Or I would be glad to discuss this with you offline and how its used in various places for TCP/IPv4 protocol suite on a host as a backgrounder for you if needed. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 07:14:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05221; Thu, 27 Oct 94 07:14:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05215; Thu, 27 Oct 94 07:14:34 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03680; Thu, 27 Oct 94 07:10:13 PDT Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA00195; Thu, 27 Oct 94 07:10:09 PDT To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Alan's comments on NOSI Date: Thu, 27 Oct 94 15:08:38 GMT From: Ran Atkinson Message-Id: <9410271508.aa07974@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, I believe that your assertion that "one cannot build infrastructure networks, defence networks, ... that have to operate on the basis of a cluster" is not technically solid at present. If you desire to convince others of your positions, you need to present a solid TECHNICAL rationale as to why you believe that some approach won't work. I and some others are not impressed by your handwaving, regardless of how vocal it is. I have some modest experience running IP in military environments, including IP over 2.4 Kbps RF channels that CLNP simply will not work over (hint: good people did try to make it work). I believe that your assertion is incorrect based on my small experience. Because you have not explained the TECHNICAL basis for your claim, it is difficult to discuss this on this list. I personally would be greatly obliged if you'd try very hard to refrain from the gratuitous OSI-Internet slaps and I'd be even more obliged if you'd bother to ftp down and actually read and familiarise yourself with how the Internet is currently setup, run, and managed before claiming tha its procedures won't work. It is possible or even likely that there are open issues or problems, but these wild unsubstantiated claims you have been making are simply not useful in a technical working group. To be more constructive, please make SPECIFIC and DETAILED comments describing WHICH PART of the current method you think is broken, WHY you think the current method is broken, and HOW in specific you would propose to change things. It has never been clear to me (and I have some small experience with ATM and some small experience with the ATM Forum addressing) WHY one would desire to embed a link/subnet layer address in an IP address. I've asked this question of various people in the past and not gotten good answers. If you have a good technical explanation of why this is desirable, I, for one, would like to hear it. I have no interest in explanations which are at heart political, however. Brian Carpenter, Might it be appropriate to setup a more focused discussion list for the NSAP/IPv6 discussions and leave the ipng list to the other work ? Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 07:39:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05233; Thu, 27 Oct 94 07:39:50 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05227; Thu, 27 Oct 94 07:39:43 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA21031; Thu, 27 Oct 94 07:35:24 PDT Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA03892; Thu, 27 Oct 94 07:35:15 PDT Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11346; Thu, 27 Oct 1994 15:35:12 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13767; Thu, 27 Oct 1994 15:35:10 +0100 Message-Id: <9410271435.AA13767@dxcoms.cern.ch> Subject: Re: (IPng) Alan's comments on NOSI To: ipng@sunroof Date: Thu, 27 Oct 1994 15:35:10 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9410271508.aa07974@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Oct 27, 94 03:08:38 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 536 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, > Brian Carpenter, > Might it be appropriate to setup a more focused discussion list for > the NSAP/IPv6 discussions and leave the ipng list to the other work ? Excellent idea, but I am leaving my office and the network for ten days in two hours from now. Anybody at Sun: is it possible to set up a nosi@sunroof list with majordomo? It makes no sense to set it up in Europe when you look at traffic patterns. If yes, please include me as an initial member and everybody please divert nosi-related mail to that list. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 08:00:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05276; Thu, 27 Oct 94 08:00:52 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05270; Thu, 27 Oct 94 08:00:45 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA22003; Thu, 27 Oct 94 07:56:25 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07373; Thu, 27 Oct 94 07:56:23 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA01128; Thu, 27 Oct 94 07:52:49 -0700 Received: by xirtlu.zk3.dec.com; id AA05990; Thu, 27 Oct 1994 10:52:20 -0400 Message-Id: <9410271452.AA05990@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) Alan's comments on NOSI In-Reply-To: Your message of "Thu, 27 Oct 94 15:08:38 GMT." <9410271508.aa07974@sundance.itd.nrl.navy.mil> Date: Thu, 27 Oct 94 10:52:14 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, ACK on your mail to Alan, but I do think its fair for folks to come to this list and as you say familiarize themsevles with the Internet model (which I hope Alan will do), but we must have patience with new IETF members too. But your right in your mail to Alan IMHO. >Brian Carpenter, > Might it be appropriate to setup a more focused discussion list for >the NSAP/IPv6 discussions and leave the ipng list to the other work ? My input to Brian and as co-author to the ONLY ID specification to map NSAPs into IPv6 is that this is part of the IPng base Working Group. The subject line has always been clear and folks can hit delete if they want to. If folks want this discussion and topic out of the IPng base working group then that is something to take up with the ADs and Chairs of the IPng working group. Right now this is very critical to many customers with large dollars to spend on the Internet and software and not just government agencies. Resolution on NSAPs and CLNP are important part of this working group and are valid on this mail list. Yes there are only 800,000 CLNP hosts deployed but many of the fortune 500 worldwide companies have considered CLNP and NSAPs in their large network plans. Most of these plans have not been implemented, but the plans exist and what is not clear to the market is do they have to scrap all those plans and just use IPv6. Maybe this is the answer and this needs to be discussed at the BOF too. As far as I can tell the most critical part is making sure those customers with 800,000 hosts can use the applications now running over CLNP (OSI and DECnet Apps) can still use those applications over IPv4 and also IPv6. If you have not noticed a colleague of mine just put out a draft RFC 1006+ (Pouffary). Which will permit this to happen and there is code in process and working to make this happen for customers who want thafunctionality. The next issue is what to with all the NSAP allocation plans in the U.S., Europe, and to some extent Pacrim. This is valid work for IPng WG. What I don't want this to become is a continuation of the standards gravy train track for ISO or the IETF for work that is not needed and represents no real customer, and is bogged down in complete politics which further supports the standards gravy train. Standards gravy train is the funding, expenses, et al to support standards tracks that have life of themselves with no apparent chance of success in the market or no real customers. Nor do I want to see this topic impede the work on IPv6 addressing plans which are very close to completion IMHO, using NSAPs or CLNP as a political volley ball. There could be very serious technical work for host kernels and routers if we are to map NSAPs or transition CLNP to IPv6 other than those applications. For this we need to have a serious requirements discussion. If that turns out to be we need it then we need serious design and implementation discussions. I agree political discussions are not useful. Determining the agenda for the BOF and topics is valid too, so all folks input his heard in the IPng working group, of which this topic is part. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 09:47:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05390; Thu, 27 Oct 94 09:47:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05378; Thu, 27 Oct 94 09:47:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14429; Thu, 27 Oct 94 09:43:15 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA28228; Thu, 27 Oct 94 09:43:07 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm012-03.dialip.mich.net [35.1.48.204]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA16476 for ; Thu, 27 Oct 1994 12:43:04 -0400 Date: Thu, 27 Oct 94 15:12:59 GMT From: "William Allen Simpson" Message-Id: <3346.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) NOSI BOF - STRONG COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: /PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au > Addressing schemes DICTATE how networks are designed.. their design > methodology, their administration and the way in which they can be deployed > across this planet. > This is utterly and egregiously wrong! Network design dictates the addressing scheme. Addressing is a means, not an end. The addressing must follow the routing, which follows the deployment. Please read my "deployment" draft. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 09:48:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05397; Thu, 27 Oct 94 09:48:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05384; Thu, 27 Oct 94 09:47:45 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14457; Thu, 27 Oct 94 09:43:23 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AB28292; Thu, 27 Oct 94 09:43:19 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm012-03.dialip.mich.net [35.1.48.204]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA16482 for ; Thu, 27 Oct 1994 12:43:06 -0400 Date: Thu, 27 Oct 94 15:18:49 GMT From: "William Allen Simpson" Message-Id: <3347.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) LL Multicast Last Hop Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Sender: conta@zk3.dec.com > If you have a problem with clogs on your poor links, then my advice would > be to get faster links, or to write a mail filter, that automatically would > do for you, what otherwise you do manually. > One of the technical problems we have had in this debate is whether we should design for CURRENTLY deployed links. Some think that all 10 Mbps and below links are soon to be replaced, everywhere on the planet. Please remember that experience shows that slower links will be with us for a very long time. International treaties, for example, take a long time to change. The target life of IPv6 is 30 years, and I don't expect that every home on the planet will be re-wired in that timeframe. I will take your advice seriously when it is accompanied by $20,000. > In what concerns your DNS resolver setup, if you adapted the list of default > servers, and timeout intervals to the type of problems you encounter, > you could have had a better response time. I tried in the last several days > to get a bahavior like yours, and I couldn't, but I have a list of two > DNS servers, and a time-out interval that starts at 2 seconds. In your case > if you wanted you could have done a different if not a better setup job. > Fascinating. Your advice is to speed up the timeout interval. This is exactly the user behaviour that I predicted, which would cause congestion. I used to have a initial DNS RTT of 5 seconds. The dns2.itd.umich.edu server routinely takes 4.601 seconds (on average), although the ping SRTT is only 600 ms. So, I raised my initial DNS RTT to 6 seconds, which results in fewer timeouts. > > Bad implementations, insufficient resources, bad configuring can > > happen separately or all together, and I wonder how much in your case > > is in reality the first, the second, the third, or various combinations of > > them. Did you try to debug this at any extent? > > > Sure Alex, over several years. Why else do you think that I can > described the problem so thoroughly? How is it that everybody else's > ideas must be because of "bad implementations, insufficient resources, > bad configuring"? By this reasoning, the entire IP community must be > incompetent. > > Bill, I do not understand what you are trying to say, but if you imply that > I was derogatory to the Internet community you're absolutely wrong. You "wonder" that the DNS administrators, the network administrators, the router vendor, and myself, are incompetent. Thus the word "community". > If you assume > that when you say that the data and solicitation goes in one packet, I > do not understand immediately that you address latency, buffer queueing, > and network load, you are damn wrong. > I have not, at any time, advocated putting data and solicitation in one packet. Therefore, I do not understand your reference as to my assumptions about your understanding. My assumptions are clearly spelled out in the Discovery Requirements draft. > And then you state loudly that relying IPv6 address resolution robustness > on correct link adapters, and link implementations in routers, partially > based on RFC 1122 is not a problem! > I have not, at any time, advocated "relying IPv6 address resolution robustness on correct link adapters, and link implementations in routers" [sic]. I have clearly stated repeatedly that the design for discovery MUST be done at the internetwork layer for exactly that reason, as below: > The forwarding problem is entirely an IP implementation issue. Every > link layer is required to indicate to the network layer the receipt of a > braodcast or multicast address. > > And what if the link layer implementation does not set properly the broadcast > or multicast flag? What if the link adapter does not filter correctly a > multicast address, and what if the link layer software does not filter > correctly a multicast for a certain protocol?, and so on... > In which case, the implementation will not support IPv6, which requires support for multicast addresses. I am only concerned about IPv6 protocols. > Host don't create but suffer the effects. They receive duplicate packets, > if a packet is mistakenly forwarded by a bogus router. I do not want to > allow this to happen. > IPv4 and IPv6 require a host to correctly process duplicate datagrams. > 10-20 years > from now, when Internet will nolonger > be a privilege but rather the trivial all over the world, and thousands > and thousands of link adapters, and link layer imbeded implementations > will be like any minor appliance produced everywhere on this planet, > would you bet your income that everyone will follow ad literam RFC xxxx? > I would not bet my income that _you_ would follow "ad literam" RFC xxxx. The scenario of which you are frightened will not happen in a correct implementation. We cannot design around all possible incorrect implementations. > Why don't you do a better job and be more respectfull with other contributors > and the readers, and mention other people's contribution such as Christian's > or Dino's or others', in the "acks" section of your draft? There is a lot of > collective work that is being done here, so you could do a lot more better than > you do in that respect, you know my opinion on that. > The design credits are in the design document acknowledgements: The document was initially composed of selections of text contributed by Fred Baker (ACC), Dino Farinacci (Cisco), Christian Huitema (INRIA), Frank Kastenholz (FTP Software), Tony Li (Cisco), Dave Piscitello (Bellcore), and Garrett Wollman (UVM?). If anyone were to have contributed a substantial amount of text to the processing document, they would have been cited. It currently reads: The document was initially composed of quotations from the RFC-1122 "Requirements for Internet Hosts -- Communication Layers", and RFC- 1256 "ICMP Router Discovery Messages". Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 09:48:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05403; Thu, 27 Oct 94 09:48:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05391; Thu, 27 Oct 94 09:47:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14476; Thu, 27 Oct 94 09:43:34 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA28304; Thu, 27 Oct 94 09:43:22 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm012-03.dialip.mich.net [35.1.48.204]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA16487 for ; Thu, 27 Oct 1994 12:43:17 -0400 Date: Thu, 27 Oct 94 16:02:55 GMT From: "William Allen Simpson" Message-Id: <3348.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) piggybacking Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: conta@zk3.dec.com > 1) IPv6 architecture: It is contrary to the IPv6 design to add an > intervening header at a router. We don't do this for Fragmentation > anymore, or anything else. > > IPv6 architecture is the IP architecture. We are in the process of working on > the IPv6 design. Hop by hop options can be extended to allow options that can > be inserted anywhere in transit, and dropped at the next hop right after > their first processing. This type of options could be useful in the future > for other things than address resolution. > On the contrary. We are no longer working on the "design". We are working on the details, and we are tasked to be finished in a few more weeks. The hop-by-hop option header is always inserted at the source. I disagree that insertions by routers of such options would ever be useful. We use tunnels for such information. > 2) Authentication: Adding an intervening header at a router would break > the current authentication proposal, and open the door to many > abuses. > > Wrong. I was so tempted to paraphrase you "DID YOU READ MY SPECCCC?", but > I didn't (-:. Page 8 of the IPv6 Specification states that setting the 3-rd > highest bit would exclude the hop by hop option from integrity computation, > when an Authentication header is present. > ??? What does this have to do with anything? > Abuses? What abuses? The IPv6 layer (system) generates such hop by hop > extension headers. Noone else. An unprivileged user would not have direct > access to issueing a packet with such a header. A privileged user should be > allowed - similar to current ARP implementations - indirectly, through a > system call the sending of a "media address resolution solicitation". > What are these "privileged user" beings, and how do they affect IPv6? > 3) MTU Discovery: Adding an intervening header at a router would break > MTU discovery. > > You don't say how. That's an odd statement, as it seems to be in the next paragraph: > Your solution to only add the header on shorter than MTU sized > packets is based on faulty reasoning. You assume that streamed > (TCP) packets are the dominant form of traffic, and that most > initial packets are less than MTU sized. > > That's my conclusion, and not assumption, that most first packets are small > packets. That is based on facts and not faulty reasoning, see bellow. > I add the header to packets shorter than MTU - extension header size. > ... > And by the way, were you talking about your network? > Well, I don't know where you got your facts. Last year, I got mine from the Merit/MichNet/NSF NOC, which is/was within a brief walking distance of my apartment. > In fact, most traffic (at the final hop) is UDP, not TCP. NFS and > DNS account for over half the traffic on a Unix or PC LAN. > Multicast is largely UDP at this time. > > Only the first packets are relevant for this discussion. And you are wrong in > both DNS and NFS case. The majority of DNS first packets are small - if we > talk name resolution, or not; zone transfers may be large packets. but that > is TCP, so first packets are small. > There are several fallacies here, but I am getting tired of the tirade, and will address the first: Discovery does not only take place for the first datagram. It takes place every time the cache entry times out. > Also, good TCP implementations for years have carried data in the > SYN packet. > > Wrong. > Good TCP implementations should always carry SYN in a control packet - no data. I have stated a fact of history and practice. But as above, you are happy to brand the internet community as "wrong". > 4) Extension size: Your maximum estimation is simply wrong. You assume > that we don't use the Discovery extensions. Whether you like them > or not, they are each and every one required in some environment > with which we have practical experience. > > In an address solicitation you need to put the minimum, which is the > destination IP address, and the media address of the sender interface. > Anything else that you put in your general solicitation, i.e. system heard can > go separately in an ICMP packet. > If we now have 2 packets, then there is no reason to pursue your idea any further. Therefore, I won't. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 10:29:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05438; Thu, 27 Oct 94 10:29:46 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05432; Thu, 27 Oct 94 10:29:39 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA00837; Thu, 27 Oct 94 10:25:20 PDT Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA08482; Thu, 27 Oct 94 10:25:14 PDT Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) LL Multicast Last Hop To: ipng@sunroof Date: Thu, 27 Oct 1994 17:25:27 +0100 (GMT) In-Reply-To: <3347.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Oct 27, 94 03:18:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1444 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Sender: conta@zk3.dec.com > > If you have a problem with clogs on your poor links, then my advice would > > be to get faster links, or to write a mail filter, that automatically would > > do for you, what otherwise you do manually. > > > One of the technical problems we have had in this debate is whether we > should design for CURRENTLY deployed links. Some think that all 10 Mbps > and below links are soon to be replaced, everywhere on the planet. > > Please remember that experience shows that slower links will be with us > for a very long time. International treaties, for example, take a long > time to change. The target life of IPv6 is 30 years, and I don't expect > that every home on the planet will be re-wired in that timeframe. Also remember that as fast links expand into the west parts of the world are just discovering the slow link. A lot of the world is going to be held together by modems and string for many many years yet. Other areas like radio links have bounded upper limits as bandwidth is limited, or costs large amounts. One of the great things about IP v4 is that it works on 10Mb/sec ethernet and 1200 baud radio links. IP v6 needs to be as good at both. I've no problems with the fact TCP needs massive work for >10Mb/second and for fast links with slow RTT's, nor that TCP has trouble with 1200 baud unreliable links. TCP is going to get fixed. IP v4 isn't broken - IP v6 shouldn't be broken. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 11:40:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05519; Thu, 27 Oct 94 11:40:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05513; Thu, 27 Oct 94 11:40:14 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25738; Thu, 27 Oct 94 11:35:51 PDT Received: from sal.acomp.usf.edu by Sun.COM (sun-barr.Sun.COM) id AA24060; Thu, 27 Oct 94 11:35:31 PDT Received: (ted@localhost) by sal.acomp.usf.edu (8.6.9/8.6.5) id OAA02676 for ipng@sunroof.Eng.Sun.COM; Thu, 27 Oct 1994 14:35:28 -0400 Date: Thu, 27 Oct 1994 14:35:28 -0400 From: Ted Netterfield Message-Id: <199410271835.OAA02676@sal.acomp.usf.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Bill... The Motif stuff is there!!!! I remade one of the links to the include files, but it should work.... Let me know if you have any problems.... Ted ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 12:12:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05557; Thu, 27 Oct 94 12:12:32 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05008; Thu, 27 Oct 94 02:05:05 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20473; Thu, 27 Oct 94 02:00:44 PDT Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA02195; Thu, 27 Oct 94 02:00:44 PDT Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.4/8.6.4) with ESMTP id FAA16581 for ; Thu, 27 Oct 1994 05:00:40 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.4/8.6.4) with SMTP id FAA04583 for ; Thu, 27 Oct 1994 05:01:42 -0400 Received: from sg5382na.eng.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AB12069; Thu, 27 Oct 94 05:09:56 EDT Message-Id: <9410270909.AB12069@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 1.4.3b4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Oct 1994 04:58:42 -0500 To: ipng@sunroof.Eng.Sun.COM >From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Host prefix Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have a couple concerns about not having hosts know their prefix. First, I want devices to be able to talk with each other on a 'segment' without involving another device. This is important on factory floor environments where we run with 255.255.254.0 masks today and they want larger subnets for the next go-around. Second, I do not like an advertisment protocol, that means a chaty protocol. I've got too many of these now! Think about 'green machines'. The vendors are finally working out how adapter cards can notify the system about their state. If I've got chatty protocols the answer is never. If not, then a system might not have to process anything that is not directly addressed to it. Of course, I do not understand multicast well enough, I suppose. If multicast is delivered on an ethernet as an ethernet broadcast, I've gained nothing :( Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 12:27:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05608; Thu, 27 Oct 94 12:27:30 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05602; Thu, 27 Oct 94 12:27:19 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA09190; Thu, 27 Oct 94 12:22:59 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA04831; Thu, 27 Oct 94 12:21:20 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-02.dialip.mich.net [35.1.48.83]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA24611 for ; Thu, 27 Oct 1994 14:26:11 -0400 Date: Thu, 27 Oct 94 18:03:38 GMT From: "William Allen Simpson" Message-Id: <3355.bill.simpson@um.cc.umich.edu> To: ipng@sunroof Subject: (IPng) NOSI Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > My input to Brian and as co-author to the ONLY ID specification to map > NSAPs into IPv6 is that this is part of the IPng base Working Group. I respectfully disagree. NSAP to IPv6 convergence is no more a part of the IETF than IPX to IPv6 convergence or AppleTalk to IPv6 convergence. These should be dealt with in their respective communities. That's why we need the BOF. To decide what if anything needs to be done in the IETF.... > Right now this is very critical to many customers with large dollars to > spend on the Internet and software and not just government agencies. So what? SNA is also "very critical to many customers with large dollars", but we don't try to specify that here. What's so special about NSAPs? Let's get to NSAPs sometime after NetBEUI, shall we? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 14:28:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05714; Thu, 27 Oct 94 14:28:25 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05708; Thu, 27 Oct 94 14:28:18 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA27331; Thu, 27 Oct 1994 14:23:36 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA09886; Thu, 27 Oct 1994 14:24:41 +0800 Date: Thu, 27 Oct 1994 14:24:41 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9410272124.AA09886@kandinsky.Eng.Sun.COM> To: fredr@anubis.network.com Subject: (IPng) re: IPv6/IPv4 host address? Cc: ipng@sunroof Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > When comparing > draft-hinden-ipng-addr-00.txt (page 9) and > draft-gilligan-ipv6-sit-overview-00.txt (page 11) > I noticed that these documents do not agree on the prefix > of an IPv6/IPv4 host. The first document uses 0:0:0:0:0:ffff as > prefix, the second one uses 0:0:0:0:ffff:ffff as prefix. > I have no urgent reason to prefer either of the two, > but the final documents should agree on one of them. Thanks for noticing that! My document is in error. Bob Hinden's is correct. The correct prefix for an IPv4-compatible IPv6 address is 0:0:0:0:0:ffff. I'll fix this in the next revision of my document. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 19:10:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06152; Thu, 27 Oct 94 19:10:03 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06146; Thu, 27 Oct 94 19:09:56 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA04932; Thu, 27 Oct 94 19:05:35 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA16721; Thu, 27 Oct 94 19:05:30 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 12:00:33 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 28 Oct 1994 12:04:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 14:05:48 +1000 Date: Fri, 28 Oct 1994 14:05:48 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941028 12:20:49 001] X400-Content-Type: P2-1984 (2) Content-Identifier: 941028 12:20:49 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941028 12:20:49*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) NOSI BOF - STRONG COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM bill. re your response. Please read the words. A theoretical network design must be based on the formation of an addressing structure. This underpins the NETWORK SPECIFICATION and ALL its protocols. AND the address structure must be capable of being administered. The Actual DEPLOYMENT of a real network will use this addressing structure as the basis for the networks implementation. Including that of assigning real values to things like: country codes, subnet numbers, areas, organisational references, terminal numbers. THIS HAS TO BE DONE FIRST BEFORE THE IRON IS INSTALLED and this process is BASED on the addressing philosophy of the networks theoretical address specification. This network design / implementation process also implicity deals with dimensioning, routing, performance, etc. So I totally disagree with your perception of the addressing issues and your comments about NSAPs and carrier plans and doing eg. SNA, Appletalk instead of NSAPs. If the 16 bytes is all you see as the IPv6 addressing issue, then perhaps you should state your views with government agencies. Certainly saying Government Agencies (and NSAPs/carrier numbering plans) will be ignored in preference of others (who ever these people are) should be brought to their attention. Is it that you believe you can build a city and then go and slap street and building address on afterwards? ( because if you do, how did you get the building materials to the sites for the work?) I am afraid the documents on mobiles, discovery and address assignments, etc still have more holes than substance hence my (and others) comments on them. All I see at the moment is that 16 bytes has been chosen and can be divided up to "what ever subnet size" you want.. However, your corrections to this statement will be welcomed. As you ask what is special about NSAPs (and carrier numbering plans I assume), perhaps you might want to take a look at the ITU/ISO based communications infrastructure that supports the Internet and ask why the carriers and large organisations who want commercial global networks are starting to adopt them. "The first action of a network design (theoretical or deployment) is to determine its naming and addressing scheme." Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 20:50:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06208; Thu, 27 Oct 94 20:50:22 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06202; Thu, 27 Oct 94 20:50:15 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA07990; Thu, 27 Oct 94 20:45:54 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26296; Thu, 27 Oct 94 20:45:27 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA09637; Thu, 27 Oct 94 20:43:44 -0700 Received: by xirtlu.zk3.dec.com; id AA08235; Thu, 27 Oct 1994 23:43:14 -0400 Message-Id: <9410280343.AA08235@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) RE: RE: (IPNG) NOSI BOF - STRONG COMMENTS In-Reply-To: Your message of "Fri, 28 Oct 94 14:05:48 +1000." <"941028 12:20:49*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Date: Thu, 27 Oct 94 23:43:08 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM First for those who do not want to work on NSAPs then don't read this mail. This is part of our charter for IPng under addressing. Its in Bob Hinden's (draft-hinden-ipng-addr-00.txt) ID. This is an IPng Working Group ID. If someone does not want it in our working group then take it up with Steve Deering, Ross Callon, Bob Hinden, Scott Bradner, and Allison Mankin. Until those folks tell me its not part of our work I will continue to have the discussions needed to resolve this topic, as I do on all IPng Base Working Group topics. Please do not use this mail list to continually object to a topic in this Working Group take it up with the proper folks who can move it to another area in the IETF. The NOSI BOF is not to move the work on NSAP addressing plans elsewhere in the IETF. The NSAP BOF is to present the various ideas on how or if we should even bother with NSAPs. If we don't bother from the BOF and then the working group, chairs, and ADs agree then I can stop spending time on this subject. Thats for NSAPs. The other agenda item for NOSI is what or should we do anything for CLNP Transition in the IETF. This part Bill is correct about in that if the BOF says yes then it will be moved to another part of the IETF. I don't enjoy the extra work but the reality is that something has put this on our shoulders. Obviously because its here I have to work on it. >"The first action of a network design (theoretical or deployment) is to >determine its naming and addressing scheme." I agree with Alan. And why I am so glad Yakov et al put out the addressing document which is positive, at least for unicast. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 20:50:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06220; Thu, 27 Oct 94 20:50:56 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06214; Thu, 27 Oct 94 20:50:48 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA08002; Thu, 27 Oct 94 20:46:28 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA26394; Thu, 27 Oct 94 20:46:22 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 13:41:38 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 28 Oct 1994 13:45:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 15:46:38 +1000 Date: Fri, 28 Oct 1994 15:46:38 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941028 14:32:05 007] X400-Content-Type: P2-1984 (2) Content-Identifier: 941028 14:32:05 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941028 14:32:05*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) ALAN'S COMMENTS ON NOSI Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM re this post. thanks for the response. I do not have all the docs at my disposal and I will try to digest them in priority order. So advice is sought on what the documents are that must be read before the meeting. We do not have FTP yet because of the Internet security implications, but I can get the necessary ones through other parties. I do not believe I am handwaving, because of issues I deal with like - insufficient IP address space, fixing up duplicate address networks, mapping IP to NSAPs, installing X.400 and X.500 technologies, installing ISDN and ATM equipment, etc as well as IPS and having to sort out numbering plans, address mapping, gateways, configuration management, naming and addressing policies, etc.. And participate in our own product strategy that embraces SNA, TCP/IP, OSI, TMN, SNMP, X.400, X.500, etc. Anyway, lets have a nosi list and if jim/ran can respond to what should be read (12 or so docs) before the BOF I will do so. Mailing them to me will also be appreciated. I have to fly.. and will be back next wednesday. Many Thanks and Regards Alan Lloyd ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 21:19:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06338; Thu, 27 Oct 94 21:19:20 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06332; Thu, 27 Oct 94 21:19:13 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA08645; Thu, 27 Oct 94 21:14:53 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29216; Thu, 27 Oct 94 21:14:52 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA11617; Thu, 27 Oct 94 21:11:11 -0700 Received: by xirtlu.zk3.dec.com; id AA08514; Fri, 28 Oct 1994 00:10:41 -0400 Message-Id: <9410280410.AA08514@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) RE: RE: (IPNG) ALAN'S COMMENTS ON NOSI In-Reply-To: Your message of "Fri, 28 Oct 94 15:46:38 +1000." <"941028 14:32:05*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Date: Fri, 28 Oct 94 00:10:35 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, I will send you the docs we have thus far. We only have two for NOSI and a bunch of mail I know you recieved. The two are carpenter-draft and the NOSI BOF announce. I will send you the IPng, Autoconfig, SDRP docs we have that are related just in case. Did not say you were "handwaving" just could not understand your analysis on sys discovery discussion and hence thought it might be "handwaving" I thought I made that clear I was not sure one way or the other, but needed more technical analysis in words why you agreed with Bill? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 21:58:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06399; Thu, 27 Oct 94 21:58:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06393; Thu, 27 Oct 94 21:58:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12453; Thu, 27 Oct 94 21:54:22 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA02603; Thu, 27 Oct 94 21:54:03 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 28 Oct 94 13:45:07 +0900 From: Masataka Ohta Message-Id: <9410280445.AA24729@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof.Eng.Sun.COM Date: Fri, 28 Oct 94 13:45:05 JST In-Reply-To: <199410261240.AA05389@zed.isi.edu>; from "bmanning@ISI.EDU" at Oct 26, 94 5:40 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Link layer is not necessarily point to point, if components have > > unique MAC addresses. > but MAC addresses are not unique and can be changed at will. > DECsupports this for DECnet, Sun supports this via the ifconfig > setup, MAC and PCs have this ability for overriding the PROM... But, what can you do for it? > You can not assume an invariate, unique MAC address. The only fix is to make it factory-configured globally unique value, not only locally-configured link unique, which is working quite well. Masataka Ohta PS The issue is unrelated to ARP or any other way of address resolution. The only requirement for MAC addresses is local uniqueness. That is, as long as there are MAC addresses, they must be link unique. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 23:08:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06449; Thu, 27 Oct 94 23:08:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06443; Thu, 27 Oct 94 23:08:52 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15254; Thu, 27 Oct 94 23:04:29 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA07262; Thu, 27 Oct 94 23:04:26 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 15:59:34 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 28 Oct 1994 16:03:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 16:04:46 +1000 Date: Fri, 28 Oct 1994 16:04:46 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Oct 28 16:04:46 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 460416281094 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <460416281094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >The only fix is to make it factory-configured globally unique value, not only >locally-configured link unique, which is working quite well. >The only requirement for MAC addresses is local uniqueness. That is, >as long as there are MAC addresses, they must be link unique. Are you saying that locally administered MAC address are not to be allowed? I can't see how you can make MAC addresses unique without eliminating locally administered addresses. Is this possible or even desirable? Jeff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 27 23:49:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06466; Thu, 27 Oct 94 23:49:22 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06460; Thu, 27 Oct 94 23:49:15 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA12524; Thu, 27 Oct 94 23:44:54 PDT Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA09660; Thu, 27 Oct 94 23:44:30 PDT Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 28 Oct 94 15:37:00 +0900 From: Masataka Ohta Message-Id: <9410280637.AA25201@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof Date: Fri, 28 Oct 94 15:36:59 JST In-Reply-To: <460416281094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS>; from "Jeff.Latimer@FINANCE.ausgovfinance.telememo.au" at Oct 28, 94 4:04 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Are you saying that locally administered MAC address are not to be > allowed? No, I don't think we have to actively forbid it. They are not used anyway. > I can't see how you can make MAC addresses unique without > eliminating locally administered addresses. The history is that the locally configured MAC addresses WERE the source of duplicated MAC addresses. > Is this possible or even > desirable? What is "this"? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 00:35:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06492; Fri, 28 Oct 94 00:35:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06486; Fri, 28 Oct 94 00:34:56 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17701; Fri, 28 Oct 94 00:30:33 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA15358; Fri, 28 Oct 94 00:30:25 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 17:25:39 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 28 Oct 1994 17:29:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 17:31:41 +1000 Date: Fri, 28 Oct 1994 17:31:41 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: ipng@sunroof.eng.sun.com X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL Oct 28 17:31:41 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 413117281094 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <413117281094*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: ipng@sunroof.Eng.Sun.COM (Non Receipt Notification Requested) Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ------------------------------ Start of body part 1 ---------------------------- Forwarded with Changes --------------------------- From: /DT=RFC-822/DV=owner-ipng%sunroof2@Sun.COM/O=AARN/ADMD=TELEMEMO/PRMD=OZ.AU/C=AU at DOF-X400 Date: 10/28/94 4:36PM To: Jeff Latimer at DOF-ITB Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS ------------------------------------------------------------------------------- ------------------------------ Start of body part 2 >> Are you saying that locally administered MAC address are not to be >> allowed? >No, I don't think we have to actively forbid it. They are not used >anyway. I know that we use them for certain Netbios and SNA configurations. >> I can't see how you can make MAC addresses unique without >> eliminating locally administered addresses. >The history is that the locally configured MAC addresses WERE the >source of duplicated MAC addresses. Agreed. >> Is this possible or even >> desirable? >What is "this"? I mean, the MAC is configured at the card driver level. 802. etc. I would have thought that to eliminate the locally administered MAC there would need to be a lot of cooperation in with the card/driver people. Hence I was wondering if we were out of scope with going this far. Jeff ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 01:14:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06534; Fri, 28 Oct 94 01:14:42 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06528; Fri, 28 Oct 94 01:14:34 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA15525; Fri, 28 Oct 94 01:10:13 PDT Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AB18325; Fri, 28 Oct 94 01:10:09 PDT X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 18:05:21 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 28 Oct 1994 18:09:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 28 Oct 1994 20:12:06 +1000 Date: Fri, 28 Oct 1994 20:12:06 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941028 19:42:05 003] X400-Content-Type: P2-1984 (2) Content-Identifier: 941028 19:42:05 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941028 19:42:05*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) ALAN'S COMMENTS ON NOSI Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM jim, thanks for the docs. I popped back into the office, because I love this industry?! Ran used the handwaving term. Anyway the piggy back. I agreed with bill on this one because he said that address resolution should be dealt with separately and before "user data transfers" (that require the addresses to be resolved). I suppose I believe in protocol integrity. Protocols are the result of function / process exchanging data. So where a UDP or TCP over IP also instigates an ARP or needs lower layer resolution (and these are combined into one request protocol unit), what happens if the ARP response fails and the TCP/UDP response works or the TCP/UDP response fails and the ARP works. I do not believe in compound protocol error recovery. Believing we still have some way to go with ARP mechanisms on X.25, FRx and ATM PVCs and ditto on SVCs with numbering plans and (dare I say it NSAPs/mapping) and discovery. Interworking units may also be an issue (X.25 - ISDN). My preference is to resolve the ARP mechanisms needed for the above and then see how it can be related to "normal IP User Dataflows" UDP/TCPIP, etc. Not start off with a concept that can have onerous network and user (of IP) level behaviour which will get worse as the resolution functions desired of it increase. Again being a new comer, I realise this may have been said already. Also I may be having an idealist view of the issue instead of seeing a pragmatic implementable solution to a lesser problem. Regards Alan@Oz PS. what happens if one does wear a suit at a BOF? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 02:07:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06636; Fri, 28 Oct 94 02:07:04 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06628; Fri, 28 Oct 94 02:06:55 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA17981; Fri, 28 Oct 94 02:02:32 PDT Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22196; Fri, 28 Oct 94 02:02:26 PDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09275; Fri, 28 Oct 1994 17:53:46 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof Subject: Re: (IPng) RE: RE: (IPNG) NOSI BOF - STRONG COMMENTS In-Reply-To: Your message of "Fri, 28 Oct 1994 14:05:48 +1000." <"941028 12:20:49*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> Date: Fri, 28 Oct 1994 17:53:41 +1000 Message-Id: <11203.783330821@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Fri, 28 Oct 1994 14:05:48 +1000 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-ID: <"941028 12:20:49*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> I don't do this all that often, but this time I am absolutely going to agree with Bill. A theoretical network design No-one is interested in a theortical network design here, only one that will work in practice on the network we have now, and the one we will have tomorrow. must be based on the formation of an addressing structure. And in any case, I absolutely disagree with that. As Bill said the addresses are nothing more than the tools the network uses to get bits form one endpoint to another. Blessing them with some mystic properties does not aid this purpose whatever. This underpins the NETWORK SPECIFICATION and ALL its protocols. Some details of the addressing are important here - largely how big they are, whether they are variable (length) or not, etc. Beyond that (that is, the contents of the field so defined) are only relevant to routing protocols. No other applications should care. If they do, they are broken. AND the address structure must be capable of being administered. Perhaps. Personally I am very much in favour of automatic address assignments, that is, you turn on your link, and it tells you what your address (prefix) is to be. If you turn on multiple links, you will be told multiple prefixes. You can use one, and ignore the others, use them all (in parallel), or use some for some purposes, and others for others. You can also probably announce out your links "by the way, I also own these other addresses, that I got from ...". The Actual DEPLOYMENT of a real network will use this addressing structure But you misunderstand - unlike some other systems, here we already have a real deployed network, it exists first. We are now desiging addresses to match. No-one is going to be very happy if you tell them they're going to have to pull down the network that already exists because you haven't decided on the addressing structure yet, so its not permitted to exist. Including that of assigning real values to things like: country codes, Country codes will never be relevant. The numbering MUST follow network topology (either that, or topology must be forced to follow geography, and political boundaries - attempting to make that happen is likely to be a monumental failure). THIS HAS TO BE DONE FIRST BEFORE THE IRON IS INSTALLED In that case we're doomed. because the iron is already installed. and this process is BASED on the addressing philosophy of the networks theoretical address specification. No, we do it the other way, we base the addresses on the phycical topology that is already installed, and make it flexible enough that we can change it as the topology changes. That is, addresses don't remain constant for long periods of time, they alter. If the 16 bytes is all you see as the IPv6 addressing issue, then perhaps you should state your views with government agencies. All kinds of people are seeing these views and participating in the designs. Its not a closed process, and has been well publicised. Certainly saying Government Agencies (and NSAPs/carrier numbering plans) will be ignored in preference of others (who ever these people are) should be brought to their attention. Why? They're free to keep doing their thing, we do not pretend to be a monopoly, or to require any kind of conformance by the world at large with what we're doing. We're just trying to make something that works. Is it that you believe you can build a city and then go and slap street and building address on afterwards? Yes. That's how most cities were built - with very few exceptions there were no grand street addressing plans that existed before the city was built. The addressing plan grows with time, and changes as needs dictate. Whether you're in Melbourne of Sydney, you must know that... ( because if you do, how did you get the building materials to the sites for the work?) When a new street is being added, it gets a name at that point. If materials are needed before the street is named, it will be referred to by some other designation, most probably related to some connecting cross street. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 07:23:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06824; Fri, 28 Oct 94 07:23:40 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06818; Fri, 28 Oct 94 07:23:29 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA00498; Fri, 28 Oct 94 07:19:09 PDT Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22774; Fri, 28 Oct 94 07:19:03 PDT Received: from Bill.Simpson.DialUp.Mich.Net (pm035-18.dialip.mich.net [141.211.7.29]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA09505 for ; Fri, 28 Oct 1994 10:18:59 -0400 Date: Fri, 28 Oct 94 13:48:45 GMT From: "William Allen Simpson" Message-Id: <3371.bill.simpson@um.cc.umich.edu> To: ipng@sunroof Subject: (IPng) Re: NOSI BOF - STRONG COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: ALAN.LLOYD@dcthq.datacraft.telememo.au > Is it that you believe you can build a city and then go and slap street and > building address on afterwards? ( because if you do, how did you get the > building materials to the sites for the work?) > I just got a kick out of this! Of course, they are assigned afterwards! When has it ever been done otherwise? Haven't you seen addresses like "123 1/2 1st Street NW"? Haven't you seen surveyor maps and plat numbers? In Detroit, back in '16 (if I remember correctly), the entire grid was renumbered by the electric company out to 26 miles! They wanted it for billing, of course -- service delivery was not a problem. But they only used 5 digit block numbers, so of course we ran out (there were fewer people here then). Streets are renumbered all the time. In Boston a few weeks ago, I was frustrated that houses aren't always numbered in order, and blocks aren't always even on one side, odd the other (ie, 200, 250, 240, 237, arrggg). And they don't bother with signs on major streets (it's obvious to the locals, right?) In IPv6, we need renumbering to be painless. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 09:31:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06890; Fri, 28 Oct 94 09:31:35 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06884; Fri, 28 Oct 94 09:31:24 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA09502; Fri, 28 Oct 94 09:27:03 PDT Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA16650; Fri, 28 Oct 94 09:26:55 PDT Received: from relay.imsi.com by wintermute.imsi.com id MAA16867 for ; Fri, 28 Oct 1994 12:26:48 -0400 Received: from snark.imsi.com by relay.imsi.com id MAA15367 for ; Fri, 28 Oct 1994 12:26:47 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA28036; Fri, 28 Oct 94 12:26:46 EDT Message-Id: <9410281626.AA28036@snark.imsi.com> To: ipng@sunroof Subject: Re: (IPng) Re: NOSI BOF - STRONG COMMENTS In-Reply-To: Your message of "Fri, 28 Oct 1994 13:48:45 GMT." <3371.bill.simpson@um.cc.umich.edu> X-Reposting-Policy: redistribute only with permission Date: Fri, 28 Oct 1994 12:26:46 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "William Allen Simpson" says: > > From: ALAN.LLOYD@dcthq.datacraft.telememo.au > > Is it that you believe you can build a city and then go and slap street and > > building address on afterwards? ( because if you do, how did you get the > > building materials to the sites for the work?) > > > I just got a kick out of this! > > Of course, they are assigned afterwards! When has it ever been done > otherwise? Haven't you seen addresses like "123 1/2 1st Street NW"? > Haven't you seen surveyor maps and plat numbers? My mother was a builder. I remember one day when one of the houses she built was finished and she had to pick a house number for it -- there were no lots numbered between #5 and #21 as I recall, so there was no obvious choice. I don't recall things ever having been numbered first, though I could be wrong. Lots on the town surveys did have lot numbers for survey purposes, but those were arbitrary and rarely even known to the owners of the lots. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 09:32:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06902; Fri, 28 Oct 94 09:32:29 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06894; Fri, 28 Oct 94 09:32:20 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA09572; Fri, 28 Oct 94 09:27:59 PDT Received: from clark.net by Sun.COM (sun-barr.Sun.COM) id AA16864; Fri, 28 Oct 94 09:27:56 PDT Received: (hcb@localhost) by clark.net (8.6.9/8.6.5) id MAA26522; Fri, 28 Oct 1994 12:27:55 -0400 From: Howard Berkowitz Message-Id: <199410281627.MAA26522@clark.net> Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof Date: Fri, 28 Oct 1994 12:27:52 -0400 (EDT) Cc: hcb@clark.net (Howard Berkowitz) In-Reply-To: <9410280637.AA25201@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Oct 28, 94 03:36:59 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1322 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > Are you saying that locally administered MAC address are not to be > > allowed? > > No, I don't think we have to actively forbid it. They are not used > anyway. Sorry, but they are actively used, primarily in non-IP environments. Some of the ways in which they are used are: 1. Modified by higher-level protocols (e.g., DECnet) 2. To make MAC addresses "self-documenting" as to their topology. This is most common in bridged environments, especially SRB. 3. To identify users/workstations. This is, of course, a perversion of the intended use, but it is done. Again, this tends to be seen in relatively primitive environments without full network layers or directory services (e.g., NetBEUI/NetBIOS). There are also cases where vendors have duplicated MAC addresses reflecting customer IDs, or field service locations. This isn't strictly LOCAL administration, but it still leads to duplication. I am coming more and more to the conclusion that we should actively discourage local MAC address changing. Should we be considering this as part of the IPng transition plan, as an infrastructure question? If we did this, it definitely would affect DECnet and other systems. Can these be managed as islands in transition? Howard Berkowitz PSC International ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 11:05:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07092; Fri, 28 Oct 94 11:05:53 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07086; Fri, 28 Oct 94 11:05:46 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA15712; Fri, 28 Oct 94 11:01:22 PDT Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA01827; Fri, 28 Oct 94 10:57:52 PDT Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Fri, 28 Oct 1994 10:57:05 -0700 From: bmanning@ISI.EDU Posted-Date: Fri, 28 Oct 1994 10:56:09 -0700 (PDT) Message-Id: <199410281756.AA10609@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Fri, 28 Oct 1994 10:56:09 -0700 Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof Date: Fri, 28 Oct 1994 10:56:09 -0700 (PDT) In-Reply-To: <9410280445.AA24729@necom830.cc.titech.ac.jp> from "Masataka Ohta" at Oct 28, 94 01:45:05 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 543 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > You can not assume an invariate, unique MAC address. > > The only fix is to make it factory-configured globally unique value, not only > locally-configured link unique, which is working quite well. > > Masataka Ohta This shows a lack of understanding the Xerox Grey Book ethernet specs. Please review them to improve your understanding of this principle. Fixing this value into a factory-configured, unique value violates this spec. Perhaps you are suggesting a re-write of the 802.3 spec to better meet your needs? -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 13:10:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07222; Fri, 28 Oct 94 13:10:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07216; Fri, 28 Oct 94 13:10:08 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03389; Fri, 28 Oct 94 13:05:45 PDT Received: from gatekeeper.us.oracle.com by Sun.COM (sun-barr.Sun.COM) id AA24672; Fri, 28 Oct 94 13:05:38 PDT Received: from battersea.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id NAA25265; Fri, 28 Oct 1994 13:04:47 -0700 Received: by battersea.us.oracle.com (5.59.11/37.7) id AA08507; Fri, 28 Oct 94 13:04:46 PDT Message-Id: <9410282004.AA08507@battersea.us.oracle.com> Date: Fri, 28 Oct 94 13:04:46 PDT From: John Hanley To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199410281627.MAA26522@clark.net> (message from Howard Berkowitz on Fri, 28 Oct 1994 12:27:52 -0400 (EDT)) Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I am coming more and more to the conclusion that we should actively > discourage local MAC address changing. I share your sentiment. Though a station running IPv6 and other stacks might have to do "too" much work in the device driver to send IPv6 packets with burned in MAC source addr and other packets with a locally administered MAC addr. Expert sniffers would have an even harder time making sense of things. Much of the benefit of unique burned in addrs can still be realized if the unique addr appears elsewhere in packets. Consider NSAPs. I _know_ that an NET does not end in MAC_addr + zero. But it is typical, and very helpful. Since IPv6 addrs often have more than 10 bytes of prefix, perhaps the link-specific (interface-specific) discovery and routing protocols could allow distant hosts to learn the 48-bit addr that is "burned in" on a card, regardless of whether the card ever actually sends packets with that MAC source addr. The solicitation format would be similar to the discovery ICMP Media-Access extension. Creeping featurism that instead belongs in DHCP or a mandatory SNMP MIB? Perhaps. It depends on how reliant IPv6 is on uniqueness for autoconfig and for correct operation. Cheers, JH ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 13:42:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07268; Fri, 28 Oct 94 13:42:21 PDT From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06695; Fri, 28 Oct 94 04:46:10 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25379; Fri, 28 Oct 94 04:41:48 PDT Received: from dub-img-2.compuserve.com by Sun.COM (sun-barr.Sun.COM) id AA06115; Fri, 28 Oct 94 04:41:48 PDT Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam) id HAA13547; Fri, 28 Oct 1994 07:41:46 -0400 Date: 28 Oct 94 07:40:12 EDT >From: Fred Rabouw <72150.1105@compuserve.com> To: IPng Subject: (IPng) RFC1710 and address size? Message-Id: <941028114011_72150.1105_EHB112-1@CompuServe.COM> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Gentlepeople, For the last month I've seen draft documents specifying 128 bit addresses for IPv6. Why is RFC1710 specifying a 64 bit SIPP address? Fred Rabouw (fredr@anubis.network.com) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 14:29:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07328; Fri, 28 Oct 94 14:29:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07322; Fri, 28 Oct 94 14:29:19 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10604; Fri, 28 Oct 94 14:24:56 PDT Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA07840; Fri, 28 Oct 94 14:22:53 PDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14597(4)>; Fri, 28 Oct 1994 14:22:22 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 28 Oct 1994 14:21:56 -0700 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) RFC1710 and address size? In-Reply-To: owner-ipng%sunroof2's message of Fri, 28 Oct 94 04:40:12 -0800. <941028114011_72150.1105_EHB112-1@CompuServe.COM> Date: Fri, 28 Oct 1994 14:21:46 PDT From: Steve Deering Message-Id: <94Oct28.142156pdt.12171@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Fred Rabouw <72150.1105@compuserve.com> > > Gentlepeople, > For the last month I've seen draft documents specifying 128 bit addresses for > IPv6. Why is RFC1710 specifying a 64 bit SIPP address? RFC1710 is one of the many whitepapers that were submitted to the IPng Directorate in response to RFC1550, this past spring. Most (all?) of those whitepapers are now being published as RFCs, as part of the historical record. SIPP, which RFC1710 describes, did have 64-bit addresses. IPv6 has 128-bit addresses. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 28 21:50:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07604; Fri, 28 Oct 94 21:50:45 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07598; Fri, 28 Oct 94 21:50:38 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA16183; Fri, 28 Oct 94 21:46:17 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA09115; Fri, 28 Oct 94 21:46:13 PDT Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16415; Sat, 29 Oct 1994 00:46:06 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA18742; Sat, 29 Oct 1994 00:46:04 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA16306; Sat, 29 Oct 1994 00:22:36 -0400 Message-Id: <9410290422.AA16306@brigit.zk3.dec.com> To: ipng@sunroof Cc: conta@zk3.dec.com, bsimpson@morningstar.com Subject: Re: (IPng) LL Multicast Last Hop In-Reply-To: Your message of "Thu, 27 Oct 94 15:18:49 GMT." <3347.bill.simpson@um.cc.umich.edu> Date: Sat, 29 Oct 94 00:22:36 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: "William Allen Simpson" .... > to get a bahavior like yours, and I couldn't, but I have a list of two > DNS servers, and a time-out interval that starts at 2 seconds. > Fascinating. Your advice is to speed up the timeout interval. This is exactly the user behaviour that I predicted, which would cause congestion. ... Assuming your timeout is not doubled after each retry, like on the implementation I am using, do you call congestion a packet every 2 seconds? .... I have not, at any time, advocated "relying IPv6 address resolution robustness on correct link adapters, and link implementations in routers" [sic]. You say yes, I say no,... Bill, it is important, therefore we have to converge on this somehow, and stop going in circles! So here it is... We want IPv6 BIGGER, much BIGGER than IPv4. It has to be AT LEAST AS GOOD. IPv4 ARP processing does not care about the modality in which the ARP packet was received: broadcast, multicast, unicast. Its REQUEST/REPLY works very robustly because it's self-contained. What is the mechanism you offer for IPv4 instead? You have to convince me that its reliability is as good as IPv4. Please do it! ... IPv4 and IPv6 require a host to correctly process duplicate datagrams. Duplicates of packets originating on the LAN? not as result of restransmission? Is this acceptable DURING ADDRESS RESOLUTION between two independent hosts, because of a faulty router?? ... > will be like any minor appliance produced everywhere on this planet, > would you bet your income that everyone will follow ad literam RFC xxxx? > I would not bet my income that _you_ would follow "ad literam" RFC xxxx. I made my point then. ... We cannot design around all possible incorrect implementations. As a collegue of mine, a veteran of the Internet community, said: you build robustness by assuming the worst! ... The design credits are in the design document acknowledgements: The document was initially composed of selections of text contributed by Fred Baker (ACC), Dino Farinacci (Cisco), Christian Huitema...... .... I missed the SIPP documents, I looked in the IPv6 ones. So the credits refer to pure text, and not ideas, or previous design or text from which the current text derives? ... Bill.Simpson@um.cc.umich.edu Alex Conta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 29 00:35:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07637; Sat, 29 Oct 94 00:35:40 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07631; Sat, 29 Oct 94 00:35:33 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA18819; Sat, 29 Oct 94 00:31:10 PDT Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA19003; Sat, 29 Oct 94 00:30:11 PDT Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA18371; Sat, 29 Oct 1994 03:30:08 -0400 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA21200; Sat, 29 Oct 1994 03:30:07 -0400 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA16398; Sat, 29 Oct 1994 03:06:40 -0400 Message-Id: <9410290706.AA16398@brigit.zk3.dec.com> To: ipng@sunroof Cc: conta@zk3.dec.com, bsimpson@morningstar.com Subject: Re: (IPng) piggybacking In-Reply-To: Your message of "Thu, 27 Oct 94 16:02:55 GMT." <3348.bill.simpson@um.cc.umich.edu> Date: Sat, 29 Oct 94 03:06:40 -0400 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: "William Allen Simpson" The hop-by-hop option header is always inserted at the source. Can you state a reason why not allow differently, for a hop lived option? I disagree that insertions by routers of such options would ever be useful. We use tunnels for such information. One use is just being discussed. Would you elaborate on your statement, why tunnels? > 2) Authentication: Adding an intervening header at a router would break > the current authentication proposal, and open the door to many > abuses. > >.... Page 8 of the IPv6 Specification states that setting the 3-rd > highest bit would exclude the hop by hop option from integrity computation, > when an Authentication header is present. > ??? What does this have to do with anything? My answer is not addressing your concern about authentication? If so, please say why!, and elaborate on the concern. > Abuses? What abuses? The IPv6 layer (system) generates such hop by hop > extension headers. Noone else. An unprivileged user would not have direct > access to issueing a packet with such a header. A privileged user should be > allowed - similar to current ARP implementations - indirectly, through a > system call the sending of a "media address resolution solicitation". > What are these "privileged user" beings, and how do they affect IPv6? I explained the safeguards. I read your not elaborating on abuses, as an indication that you find my explanation satisfactory. A privileged user is a user that has 'root' privileges on UNIX, or SYSPRV (system) privileges on VMS, or some sort of higher privilege than a normal user. This applies for multi-user systems that are more sophisticated in terms of rights and privileges given to users, than single user systems. A privileged user may employ utilities, or use system calls in his applications that a normal user cannot. > 3) MTU Discovery: Adding an intervening header at a router would break > MTU discovery. > > You don't say how. That's an odd statement, as it seems to be in the next paragraph: Nothing in the next paragraph had anything to do with PMTU discovery. Unless you elaborate on Path MTU concerns, I will consider that the following paragraphs are answered as it follows. > Your solution to only add the header on shorter than MTU sized > packets is based on faulty reasoning. You assume that streamed > (TCP) packets are the dominant form of traffic, and that most > initial packets are less than MTU sized. > > That's my conclusion, and not assumption, that most first packets are small > packets. That is based on facts and not faulty reasoning, see bellow. > I add the header to packets shorter than MTU - extension header size. > ... Well, I don't know where you got your facts. Last year, I got mine from the Merit/MichNet/NSF NOC, which is/was within a brief walking distance of my apartment. If you are talking about UDP versus TCP usage, reports may differ slightly from the reality of particular networks. However, in terms of first packets, your statements are not accurate, and I explained why. As far as my resources of information, a very good one is the sniffer and the monitoring of a network, or several. Next time you're in the area, I should perhaps have you visit, and show you. > Only the first packets are relevant for this discussion. And you are > wrong in > both DNS and NFS case. The majority of DNS first packets are small - if we > talk name resolution, or not; zone transfers may be large packets. but that > is TCP, so first packets are small. > > NFS first packets are also small - because its stateless nature, the start > of an NFS operation requires several small control packets, before the > pure data transfer (disk blocks) which may involve large packets... There are several fallacies here, but I am getting tired of the tirade, and will address the first: My tirade is just an echo to your style. I am sorry I got carried away. I would be more than happy to get the conversation with you away from the "lower deck". Your statements about DNS and NFS, were inaccurate, and I explained you why. If you disagree please say so, and why... Discovery does not only take place for the first datagram. It takes place every time the cache entry times out. You must have missed a relevant portion of my text, which was addressing such a possible concern as you just expressed: .... large packets as first packets are an exception rather than the rule. Furthermore, they are usually sent in a burst, which is usually shorter in time than a media address resolution cache entry lifetime, which makes also the address resolution in the middle of a large packet communication more an exception than a rule. > Also, good TCP implementations for years have carried data in the > SYN packet. > > Wrong. Good TCP implementations should always carry SYN in a control > packet - no data. > > Becuse applications transmits are expensive, in system time, and in a > multi-user system, you do not to spend system time and network > bandwidth - in transmits and retransmits - before you know that a TCP > connection is successfuly established. I have stated a fact of history and practice. But as above, you are happy to brand the internet community as "wrong". You speak for the internet community again, so you must have a reason, if not only to make me feel guilty. Would you please name a few of the TCP implementations you had in mind? I know I speak for those who built or use TCP stacks and TCP applications based on 'BSD sockets' and 'WINsockets' APIs, where a 'connect' or 'accept' i.e. establishing a connection, and thus sending a SYN, do not imply any data. That's at least several flavors of UNIX, then OpenVMS, Windows, MS-DOS, Windows-NT, etc... Very large, and large systems, servers, workstations, PCs, etc..., and many, many, many licenses, and users. If you are talking about the exprimental T/TCP (RFC1644) or earlier experiments (RFC1379), that is not standard TCP. > 4) Extension size: Your maximum estimation is simply wrong. You assume > that we don't use the Discovery extensions. Whether you like them > or not, they are each and every one required in some environment > with which we have practical experience. > > In an address solicitation you need to put the minimum, which is the > destination IP address, and the media address of the sender interface. > Anything else that you put in your general solicitation, i.e. system heard ***can > go separately in an ICMP packet. > If we now have 2 packets, then there is no reason to pursue your idea any further. Therefore, I won't. Bill.Simpson@um.cc.umich.edu First You forget the reliability problem of you model, which this doesn't have. Even at equality of number of packets, I would still consider seriously an alternative to your current model, unless it is fixed. Second Piggybacking data and solicitation, reduces the number of packets in case of a new communication to 2 packets, versus your 3 packet model, in more than 80% of cases - some collegues say more than 90%, but I am conservative. Third The "system heard" as you defined it, and as you described at the meeting is an extension used by mobile hosts. Your processing document sends the reader to a new document that you are going to write!, so its importance and use still has to be documented. At the implementors meeting, we discussed sending the "system heard" extension. We said that it is optional, will be used by mobile hosts, but does not have a role to LAN host environments, and therefore for a LAN only IPv6 implementation the code may leave out the mechanisms to send 'system heard'. Conclusion. The "system heard" can go also with the solicitation if it has room in the packet, without exceeding MTU, or in a separate ICMP packet. Even if the 'system heard' would go in a separate ICMP advertisment packet, in all cases - but we established that it won't, since it is helpfull only for mobile - the packet count would still be 2 + 1, which is equal to your 3. All this without the reliability concern of the negative effect of a "link multicast/ipv6 unicast" that your model incures. So your dismissal on number of packet base seems quite hasty, and unfounded. At any rate, I am not considering the "discovery" discusion closed at all, since there is a lot more to be done, on this topic, and others, before it reaches a comfortable level of completeness. I wish our discussions were more constructive and polite. We perhaps can work on it. You made a long list of reasons why my idea has fatal flows. That was constructive in that it spun a discussion of technical details. I argued against your arguments, and I answered all your concerns, when they were technical and expressed as such, in several messages. I am not satisfied with your answers, or how you responded to my answers from a technical prospective. The proposal has merits, which were not explored fully yet. I have a couple of ideas in relationship with that. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 29 07:40:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07722; Sat, 29 Oct 94 07:40:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07716; Sat, 29 Oct 94 07:39:58 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13764; Sat, 29 Oct 94 07:35:34 PDT Received: from sundance.itd.nrl.navy.mil ([132.250.92.89]) by Sun.COM (sun-barr.Sun.COM) id AA02985; Sat, 29 Oct 94 07:34:05 PDT To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) security considerations Date: Sat, 29 Oct 94 15:29:54 GMT From: Ran Atkinson Message-Id: <9410291529.aa09922@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, DOS, Windows 3.1, WindowsNT, and MacOS are all examples of operating systems that do not have meaningful access control mechanisms hindering a would-be malicious user from intercepting, modifying, or injecting packets on the Internet. Windows95, Windows NT, and MacOS all come with built-in TCP/IPv4 support and PCs are very widespread already. All the world is no longer VMS or UNIX or TENEX. In fact, my computer security side isn't sure the BSD notion of "trusted ports" is very useful in the current threat environment. The security mechanisms and architecture for IPv6 should, IMNVHO, assume that would-be malicious users ARE capable of the actions noted above. This directly leads to the conclusion that it is undesirable to have non-authenticated/ non-authenticatable options that might have important security-related side-effects if there is any reasonable alternative. I am currently uncomfortable with this (Alex's ?? or am I confused about whose idea this is) notion of inserting a new optional header in the middle of packet transit from source A to destination B, primarily because I don't understand what the proposed format and use of such an optional header might be. The SDRP folks' insertion of a unidirectional source route header is something I'm still mulling over and haven't reached any conclusions about, but in general we need to be very thoughtful about specifying optional headers that are incapable of being authenticated using the proposed IPv6 Authentication Header. Regards, Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 29 11:01:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07778; Sat, 29 Oct 94 11:01:04 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07772; Sat, 29 Oct 94 11:00:58 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA24640; Sat, 29 Oct 94 10:56:35 PDT Received: from csupomona.edu (dns.is.csupomona.edu) by Sun.COM (sun-barr.Sun.COM) id AA11190; Sat, 29 Oct 94 10:56:33 PDT Received: by csupomona.edu (5.65/DEC-Ultrix/4.3) id AA02074; Sat, 29 Oct 1994 10:48:45 -0700 From: tpoernomo@csupomona.edu Message-Id: <9410291748.AA02074@csupomona.edu> Received: from clstac.dnet by dns.dnet; Sat, 29 Oct 94 10:51:19 PDT Date: Sat, 29 Oct 94 10:51:19 PDT To: ipng@sunroof Subject: Re: (IPng) RFC1710 and address size? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This is confusing. Am I right SIPP and IPv6 are different? If not, then which onw is correct: SIPP with 128 bytes address of 64? BTW, is RFC1710 describes the final standard for SIPP? Sincerely, Ted :) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 29 21:04:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07904; Sat, 29 Oct 94 21:04:57 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07898; Sat, 29 Oct 94 21:04:49 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA03527; Sat, 29 Oct 94 21:00:26 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01914; Sat, 29 Oct 94 21:00:16 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA04708; Sat, 29 Oct 94 20:57:43 -0700 Received: by xirtlu.zk3.dec.com; id AA08945; Sat, 29 Oct 1994 23:57:10 -0400 Message-Id: <9410300357.AA08945@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) RE: RE: (IPNG) NOSI BOF - STRONG COMMENTS In-Reply-To: Your message of "Fri, 28 Oct 94 17:53:41 +1000." <11203.783330821@munnari.OZ.AU> Date: Sat, 29 Oct 94 23:57:04 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Date: Fri, 28 Oct 1994 17:53:41 +1000 >Message-Id: <11203.783330821@munnari.OZ.AU> >From: Robert Elz Date: Fri, 28 Oct 1994 14:05:48 +1000 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-ID: <"941028 12:20:49*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> A theoretical network design >No-one is interested in a theortical network design here, only >one that will work in practice on the network we have now, and >the one we will have tomorrow. Agreed. But it is imperative that we test concepts about network design before we pick one. That is how I took Alan's message. must be based on the formation of an addressing structure. >And in any case, I absolutely disagree with that. As Bill said >the addresses are nothing more than the tools the network uses to >get bits form one endpoint to another. Blessing them with some >mystic properties does not aid this purpose whatever. I don't agree at all. Addresses have everything to do with implementation: their size, structure, what they tell me, and what names they are connected to. These are the details you reference in your next comment and these details are critical to starting. Again how I took Alan's comment. This underpins the NETWORK SPECIFICATION and ALL its protocols. >Some details of the addressing are important here - largely >how big they are, whether they are variable (length) or not, >etc. Beyond that (that is, the contents of the field so defined) >are only relevant to routing protocols. No other applications >should care. If they do, they are broken. Applications should not care but an ipv6_input (or output) layer will care for various reasons in a host or router kernel. AND the address structure must be capable of being administered. >Perhaps. Personally I am very much in favour of automatic >address assignments, that is, you turn on your link, and it >tells you what your address (prefix) is to be. If you turn on >multiple links, you will be told multiple prefixes. You can >use one, and ignore the others, use them all (in parallel), or >use some for some purposes, and others for others. You can also >probably announce out your links "by the way, I also own these >other addresses, that I got from ...". Exactly and administered means that the implementation be able to be self contained and treat the addresses in a reliable manner. Which means we must assume they were administered correctly. The Actual DEPLOYMENT of a real network will use this addressing structure >But you misunderstand - unlike some other systems, here we >already have a real deployed network, it exists first. We NO not for IPv6 we don't. >are now desiging addresses to match. No-one is going to be very >happy if you tell them they're going to have to pull down the >network that already exists because you haven't decided on the >addressing structure yet, so its not permitted to exist. This has to be discussed for transition. Including that of assigning real values to things like: country codes, >Country codes will never be relevant. The numbering MUST follow >network topology (either that, or topology must be forced to >follow geography, and political boundaries - attempting to make >that happen is likely to be a monumental failure). I agree. THIS HAS TO BE DONE FIRST BEFORE THE IRON IS INSTALLED >In that case we're doomed. because the iron is already >installed. I don't agree we only have an idea from SIT how we can begin to install the IRON. This begs the other question that was asked when we started working on IPNg and that is are we trying to solve the problems of the multiprotocol world. I do not think we should and only worry about IPv6. But if there is a need to address present non-IPv4 addresssing plans as we design how to deploy IPv6 then I am open to that discussion just in case its a real issue. and this process is BASED on the addressing philosophy of the networks theoretical address specification. >No, we do it the other way, we base the addresses on the >phycical topology that is already installed, and make it >flexible enough that we can change it as the topology changes. >That is, addresses don't remain constant for long periods of >time, they alter. I do not think we have anything installed. As far as addressing I was very glad to see the two addressing plans for the basics from Bob and Yakov before I started implementation design. So I think Alan has a valid approach that we need addressing understood before we can begin implementing not necessarily designing other parts. If the 16 bytes is all you see as the IPv6 addressing issue, then perhaps you should state your views with government agencies. >All kinds of people are seeing these views and participating >in the designs. Its not a closed process, and has been well >publicised. 16bytes are done deal I hope lets make them work. Certainly saying Government Agencies (and NSAPs/carrier numbering plans) will be ignored in preference of others (who ever these people are) should be brought to their attention. >Why? They're free to keep doing their thing, we do not pretend >to be a monopoly, or to require any kind of conformance by the >world at large with what we're doing. We're just trying to make >something that works. I agree. Is it that you believe you can build a city and then go and slap street and building address on afterwards? >Yes. That's how most cities were built - with very few >exceptions there were no grand street addressing plans that >existed before the city was built. The addressing plan grows >with time, and changes as needs dictate. Whether you're in >Melbourne of Sydney, you must know that... Yes but those who settle cities have an idea of the parcel of land they are going to begin with and initial boundaries. ( because if you do, how did you get the building materials to the sites for the work?) >When a new street is being added, it gets a name at that >point. If materials are needed before the street is named, >it will be referred to by some other designation, most probably >related to some connecting cross street. Not in my town. We have a pool of street names builders can select from. They are predefined. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 29 22:29:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07929; Sat, 29 Oct 94 22:29:41 PDT Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07923; Sat, 29 Oct 94 22:29:34 PDT Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA03979; Sat, 29 Oct 94 22:25:11 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA04391; Sat, 29 Oct 94 22:25:09 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA09844; Sat, 29 Oct 94 22:23:10 -0700 Received: by xirtlu.zk3.dec.com; id AA09551; Sun, 30 Oct 1994 01:22:38 -0400 Message-Id: <9410300522.AA09551@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) security considerations In-Reply-To: Your message of "Sat, 29 Oct 94 15:29:54 GMT." <9410291529.aa09922@sundance.itd.nrl.navy.mil> Date: Sun, 30 Oct 94 01:22:32 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, > I am currently uncomfortable with this (Alex's ?? or am I confused >about whose idea this is) notion of inserting a new optional header in >the middle of packet transit from source A to destination B, primarily >because I don't understand what the proposed format and use of such an >optional header might be. The SDRP folks' insertion of a >unidirectional source route header is something I'm still mulling over >and haven't reached any conclusions about, but in general we need to >be very thoughtful about specifying optional headers that are >incapable of being authenticated using the proposed IPv6 >Authentication Header. The hop-by-hop was not really set in transit but at the router at the link where the packet would be delivered to the host. So its not really done in transit but at the link. But Alex's idea is a way to use 2 packets instead of 3 for discovery when the media address needs to be resolved. We need to understand the security implementation problems clearly, so could you elaborate in detail what problems you see and where you see in what modules on hosts or routers where it could cause an attack if IPv6 authentication is in place already? As far as SDRP unidirectional source route I think its a very needed part of the ideas being proposed in that group. Again I don't see the security issue if IPv6 authentication is in place? I am confused also in the specs which security parts are required for routers and which are for hosts? Also what are your latest Ipv6 security drafts I have lost track could you send us the versions we should be studying at this point? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 29 22:49:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07942; Sat, 29 Oct 94 22:49:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07936; Sat, 29 Oct 94 22:49:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28927; Sat, 29 Oct 94 22:45:17 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05013; Sat, 29 Oct 94 22:45:07 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA10896; Sat, 29 Oct 94 22:41:26 -0700 Received: by xirtlu.zk3.dec.com; id AA09689; Sun, 30 Oct 1994 01:40:34 -0400 Message-Id: <9410300540.AA09689@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery Date: Sun, 30 Oct 94 01:40:28 -0400 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This relates back to the system discovery topic but I wanted to give it new subject title: We have three types of multicast for discovery: 1. ALL-HOSTS-MULTICAST 2. ALL-ROUTERS-MULTICAST 3. ALL-NODES-MULTICAST All nodes see all multicast packets at the link layer and that is where the packet will know if the packet is to be accepted and processed by that node and sent the IPv6 layer. The point of using multicast as opposed to IPv4 style broadcast is to provide a more expedient decision at the link layer to discard the packet. If routers process ALL-HOSTS-MULTICAST or hosts process ALL-ROUTERS-MULTICAST then nothing has be gained by defining these multicast packet types over broadcast. If the spec means that routers don't process ALL-HOSTS-MULTICAST beyond the link layer, then routers will not accept them and pass them to the IPv6 layer. This will prevent faulty behavior by the router. Now when host applications are communicating with routers (e.g. telnet or snmp) the modebased on my interpretation of the specs is as follows: When the IPv6 layer determines whether a packet is to be transmitted on its subnet or passed to a router, there needs to be a new test point in an implementation if the destination node is a router, because of the way IPv6 wants to use multicast for discovery. In the media resolution software for missing or timed-out entries the test must be done again to see if the dest address is a router. If it is the address must be discovered with an ALL-ROUTERS-MULTICAST packet. Routers can still use the ALL-HOSTS-MULTICAST solicitation to resolve host addresses as the reply is a unicast. This is my interpretation of the specifications at present. It might be good to have some words in the specs to make all this much clearer to a reader or implementor. Unless my interpretation is wrong? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 00:04:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07963; Sun, 30 Oct 94 00:04:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07957; Sun, 30 Oct 94 00:04:38 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29552; Sun, 30 Oct 94 00:00:13 PDT Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07912; Sun, 30 Oct 94 00:00:14 PDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA15414; Sat, 29 Oct 94 23:56:54 -0700 Received: by xirtlu.zk3.dec.com; id AA10206; Sun, 30 Oct 1994 01:56:21 -0500 Message-Id: <9410300656.AA10206@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Local File Network Address/Name Support for Transition Date: Sun, 30 Oct 94 01:56:15 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Our ngtrans list seems too quiet so I am sending this to the ipng base group too as I know we have a lot of good implementors and users listening on this list. I think we need to specify a local file for end users as an option. thanks /jim ------- Forwarded Message To: ngtrans%sunroof@Sun.COM Subject: (ngtrans) Local File Support in SIT Proposal Date: Fri, 28 Oct 94 01:27:04 -0400 From: bound@zk3.dec.com During the initial stages of transition I believe that SIT should permit and provide the specification for hosts to be deployed without routers on the network. This is possible with the present specification draft-gilligan-ipv6-sit-overview-00.txt. It could also be the case that the DNS server will not be owned by the host being deployed and hence not updated to support IPv6 records. A way to alleviate this problem is to provide Local File support on the host where the IPv6 DNS AAAA records can be read instead of going to the DNS server via the resolver. But more important end users will want the ability to come up quickly and access other nodes and in some instances on a local subnet want to avoid having to query the centralized name server. On some hosts today when you install the BIND client the script asks you what order should the search for a name take e.g. Local File, Yellow Pages, BIND. Hence, this addition to SIT will permit future IPv6 scripts to do the same during BIND client setup. Here is where it needs to be put in the spec and the proposed wording and changes below: Page 12 after IPv6 Addressing Summary. One of the headings for the matrix states: ----------------- DNS DNS Type this should say Type Required Required (*) --------------------- The * in my proposed word change would point to a sentence below that states: __________________________________________________________________ * In addition to DNS records a Local File may also be supported to determine the various types of IPv6 address (see 10. Upgrade Dependencies). ___________________________________________________________________ Then on page 26 10. Ugrade Dependencies I would add after the 1st paragraph: - ------------------------------------------------------------------- Local File support may also be provided to support minimal dependencies, espescially during the initial stages of transtion in addition to DNS record support. The Local File should be an ASCII file that can be read to obtain or search IPv6 address types. An example format of those address types are as follows: 0:0:0:0:0:ffff:16.23.12.5 foo.wbos.aol.com foo #IPv4/IPv6 compatible address A:B:E:A:C:D:A:B who.next.lp.uk who #IPv6-Only Address The Local file is an ASCII file that contains information about the known nodes on the DARPA Internet. For each node a single line should be present with the following information: Internet IPv6 address Official node name Aliases Each IPv6-node name is separated from the next by a newline. Items are separated by any number of blanks or tab characters. A number sign (#) indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search the file. This file is normally created from the official node data base maintained at the Net- work Information Control Center (NIC), though local changes may be required to bring it up to date regarding unofficial aliases or unknown nodes. IPv6 addresses are specified in the conventional colon (:) notation. It is implementation defined regarding what software modules will read and use these Local File entries to access IPv6 nodes, instead of accessing DNS. Node names can contain any printable character other than a field delimiter, newline, or comment character. ED COMMENT : We need a pointer to the IPv6 address notation after the (:) above and I was not sure which spec we want to reference??? - ------------------------------------------------------------------ Also on page 26 the diagram depicting the upgrade dependencies for the those specifying DNS in the text should replace DNS with DNS (*). Then the wording below the diagram for the * would state: - --------------------------------------------------------------- * Implies this may be supported by use of a Local File too. - ------------------------------------------------------------- I purposely used MAY and SHOULD in my descriptions to make it optional. I also purposely used the word "nodes" instead of hosts so that if routers want to use this they can (or maybe even printers or other types of nodes too). Question do we need to add an entry for local host support (the loopback address), while we are defining a Local File? Comments ??? thanks /jim ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 01:23:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07995; Sun, 30 Oct 94 01:23:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07989; Sun, 30 Oct 94 01:23:04 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00574; Sun, 30 Oct 94 01:18:39 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AB14168; Sun, 30 Oct 94 01:18:39 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 30 Oct 94 18:11:22 +0900 From: Masataka Ohta Message-Id: <9410300911.AA02717@necom830.cc.titech.ac.jp> Subject: Re: (IPng) ATM..MASATAKA'S COMMENTS To: ipng@sunroof.Eng.Sun.COM Date: Sun, 30 Oct 94 18:11:21 JST In-Reply-To: <941025 10:43:58*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU@MHS>; from "/PN=ALAN.LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/@X400.oz.au" at Oct 25, 94 2:22 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If one is taking Q.2931 to the desktop (and toasters), then we need some > convenient way of mapping or incorporating E.164 (or the numbering plans in > NSAPs) into the IP addresses.. The content of Q.2931 can be carried in IP layer reservation packets (such as RSVP). As the packet is IP routed, no support for E.164 mapping is necessary. > Perhaps the evolution is the merging of the Toasters, (Dentist's > Appliances?), Telephones with the Television with the data network terminal.. > so what is the addressing scheme and the carrier numbering plans then.. Assume the environmennt is IP dominant. Then, under fair competition, carriers will deploy IP addressing scheme, not E.164. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 08:38:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08051; Sun, 30 Oct 94 08:38:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08045; Sun, 30 Oct 94 08:38:43 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03234; Sun, 30 Oct 94 08:34:17 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA25943; Sun, 30 Oct 94 08:34:18 PST To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Re: Security Considerations Date: Sun, 30 Oct 94 17:34:23 GMT From: Ran Atkinson Message-Id: <9410301734.aa10476@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, I do not understand exactly what Alex is proposing, perhaps partly because it seems to evolve with email. Hence I cannot comment specifically on it at this time. It would be useful if Alex would perhaps restate in clear terms exactly what he is proposing and how it differs from the ARP model. I think the ARP model is fine, though I do prefer ICMP message formats for authentication reasons. In general, if you modify a packet in transit to remove any data, then you will break the authentication over that packet. If you insert data that has the "this is not authenticated" flag set, then I as a receiver have NO WAY to know whether it was set legitimately or not --> hence that inserted data had best not be security relevant. Theft of packets using forged ARPs occurs now in the IPv4 Internet. I want IPv6 to be no less secure and ideally a bit more secure than the IPv4 Internet. I suspect that router vendors will tell you in no uncertain terms that breaking open a packet and modifying it guarantees a BIG performance hit for that router. I am correspondingly leery of any proposal requiring a router to "crack packets and modify them". With SDRP, the big open issue in my mind is for the case I'm told about where the originator is NOT using SDRP but some system in the middle (e.g. at an administrative boundary) is adding SDRP for policy-based routing. In that case, authentication is difficult. The risks of one-way source routing (without unauthenticated source route inversion) need additional study, IMHO. I've been keeping the security drafts updated as online I-Ds, except for ESP. The Internet Drafts folks have continued to file those drafts under draft-ietf-sipp-* (for administrative reasons known to the IESG and the good folks at CNRI and not understood by me). ESP will be updated by the end of this week in online I-D form to reflect the Toronto Implementer's Meeting discussions about formats and also to try to make the DES-CBC profile more complete and clear. Comments on any of the 3 drafts may be sent either to me or to the ipng list as a whole. Regards, Ran atkinson@Itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 13:28:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08084; Sun, 30 Oct 94 13:28:42 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08078; Sun, 30 Oct 94 13:28:30 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA05236; Sun, 30 Oct 94 13:24:04 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA24407; Sun, 30 Oct 94 07:33:33 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-20.dialip.mich.net [141.211.7.31]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA12231 for ; Sun, 30 Oct 1994 10:33:30 -0500 Date: Sun, 30 Oct 94 14:51:03 GMT From: "William Allen Simpson" Message-Id: <3374.bill.simpson@um.cc.umich.edu> To: ipng@sunroof Subject: Re: (IPng) security considerations Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thanks, Ran, for the excellent explanation. > From: bound@zk3.dec.com > I am confused also in the specs which security parts are required for > routers and which are for hosts? > All are required for both hosts and routers (and the host side of routers). > Also what are your latest Ipv6 security drafts I have lost track could > you send us the versions we should be studying at this point? > Why not look in the internet-drafts directory under the names of the drafts you have for a new -nn? Please don't post drafts to lists. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 13:29:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08111; Sun, 30 Oct 94 13:29:45 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08097; Sun, 30 Oct 94 13:29:19 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA05359; Sun, 30 Oct 94 13:24:52 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA24410; Sun, 30 Oct 94 07:33:36 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-20.dialip.mich.net [141.211.7.31]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA12235 for ; Sun, 30 Oct 1994 10:33:32 -0500 Date: Sun, 30 Oct 94 14:57:05 GMT From: "William Allen Simpson" Message-Id: <3375.bill.simpson@um.cc.umich.edu> To: ipng@sunroof Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > We have three types of multicast for discovery: > > 1. ALL-HOSTS-MULTICAST > 2. ALL-ROUTERS-MULTICAST > 3. ALL-NODES-MULTICAST > Not exactly correct: a. all-nodes b. all-routers c. solicited-nodes (block of 256) All-hosts is not used in discovery. > The point of using multicast as opposed to IPv4 style broadcast is to > provide a more expedient decision at the link layer to discard the > packet. If routers process ALL-HOSTS-MULTICAST or hosts process > ALL-ROUTERS-MULTICAST then nothing has be gained by defining these > multicast packet types over broadcast. > ... > This is my interpretation of the specifications at present. It might be > good to have some words in the specs to make all this much clearer to a > reader or implementor. Unless my interpretation is wrong? The definitions of all-XXX multicast are in the address spec. Perhaps they could be elaborated upon there. We should put the solicited-node block there, too. > In the media resolution software for missing or timed-out entries the test > must be done again to see if the dest address is a router. If it > is the address must be discovered with an ALL-ROUTERS-MULTICAST packet. > Absolutely NOT! Media resolution is _never_ used for a router. That's in router advertisements. If the router entry times out, you cannot use that router! That's the point of having lifetimes. Either use another router, or (when there are no more routers in your list) return ICMP unreachable. > Routers can still use the ALL-HOSTS-MULTICAST solicitation to resolve > host addresses as the reply is a unicast. > Absolutely NOT! The Solicited-Node multicast is used, and the reply is multicast! Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 13:29:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08112; Sun, 30 Oct 94 13:29:50 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08090; Sun, 30 Oct 94 13:29:09 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA05337; Sun, 30 Oct 94 13:24:42 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA24402; Sun, 30 Oct 94 07:33:30 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-20.dialip.mich.net [141.211.7.31]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA12228; Sun, 30 Oct 1994 10:33:27 -0500 Date: Sun, 30 Oct 94 14:48:25 GMT From: "William Allen Simpson" Message-Id: <3373.bill.simpson@um.cc.umich.edu> To: ipng@sunroof Subject: Re: (IPng) IPv6 Local File Network Address/Name Support for Transition Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Our ngtrans list seems too quiet so I am sending this to the ipng base > group too as I know we have a lot of good implementors and users > listening on this list. Please don't. I *hate* getting things on two lists. And you just sent the message. You expect instant turnaround? You sent it at 1 am! I only read email once or twice a day. I expect others do the same. > I think we need to specify a local file for > end users as an option. > This is a user interface issue, and doesn't belong in a protocol specification. And I disagree. No implementation of mine will need such problematic user configuration. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 14:06:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08146; Sun, 30 Oct 94 14:06:04 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08140; Sun, 30 Oct 94 14:05:57 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA07529; Sun, 30 Oct 94 14:01:33 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA08797; Sun, 30 Oct 94 14:01:31 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 31 Oct 94 06:54:16 +0900 From: Masataka Ohta Message-Id: <9410302154.AA04597@necom830.cc.titech.ac.jp> Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery To: ipng@sunroof Date: Mon, 31 Oct 94 6:54:14 JST In-Reply-To: <3375.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Oct 30, 94 2:57 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Not exactly correct: > > a. all-nodes > b. all-routers > c. solicited-nodes (block of 256) > > All-hosts is not used in discovery. I heard IPng will actively support multiple IP addresses for a single interface. If so, and if I understand your specification correctly, each IP address needs another multicast address for the case c. So, is it possible to support them with interface chips which does not support so much multicast addresses? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 14:28:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08320; Sun, 30 Oct 94 14:28:22 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08314; Sun, 30 Oct 94 14:28:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11273; Sun, 30 Oct 94 14:23:49 PST Received: from nic.near.net by Sun.COM (sun-barr.Sun.COM) id AA09850; Sun, 30 Oct 94 14:23:49 PST Received: from jcurran.near.net by nic.near.net id aa02409; 30 Oct 94 17:23 EST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 30 Oct 1994 17:23:48 -0500 To: ipng@sunroof.Eng.Sun.COM From: John Curran Subject: Re: (IPng) IPv6 Local File Network Address/Name Support for Transition Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 9:48 AM 10/30/94, William Allen Simpson wrote: >>(Jim Bound) >> I think we need to specify a local file for >> end users as an option. >> >This is a user interface issue, and doesn't belong in a protocol >specification. > >And I disagree. No implementation of mine will need such problematic >user configuration. Hmm. I agree with both of you: o It might be useful (in some arcane situations) to have a convention for directly specifying IPv6 addresses for particular hosts. I can imagine such being useful in lab situations, during development, etc. o How this "feature" is activated is a user interface issue, and doesn't belong anywhere near the protocol specs. If someone wants to post an informational RFC on "How I added an IPv6 address hardwire capability to XX Unix", then others can follow it or not as they see fit. /John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 30 17:45:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08349; Sun, 30 Oct 94 17:45:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08343; Sun, 30 Oct 94 17:45:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14631; Sun, 30 Oct 94 17:40:51 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA18225; Sun, 30 Oct 94 17:40:51 PST To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) manual configuration Date: Mon, 31 Oct 94 2:39:19 GMT From: Ran Atkinson Message-Id: <9410310239.aa10980@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM If I understand John Curran correctly, I'm with him. File specs are not the stuff of standards-track RFCs, but if folks want to put out an Informational RFC on how they did it for the FOO operating system that might be of some value to others. Multi-level Secure (sic) and Compartmented Mode Workstations are examples of systems which need an insanely large amount of manual configuration to make work properly. It is not unusual for such systems to have multiple physical interfaces and also multiple logical IP interfaces per physical interface. Among the things that often have to be configured per logical IP interface are: sensitivity range (e.g. Unclassified thru Secret, or Top-Secret only) list of hosts that the system is willing to talk with labelling format that will be used (and ITS horrendous parameters) users who are allowed to access that interface For security reasons, manual configuration of these parameters is necessary on such systems. In fact, such systems probably cannot legally implement the Address Configuration protocol or DHCP for security reasons. I admit these systems are very abnormal, but they do exist as examples of why manual configuration probably isn't going away. IMHO, labelling ought to go away with IPv6 and should be replaced by encryption with a different key for each sensitivity level. Even if the encryption is with an algorithm one doesn't trust to protect data from outsiders, it is more secure to encrypt than to just label. One can continue to use link encryptors that implement algorithms that one trusts if the IP crypto uses algorithms one doesn't like. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 01:10:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08548; Mon, 31 Oct 94 01:10:32 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08542; Mon, 31 Oct 94 01:10:25 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA20185; Mon, 31 Oct 94 01:06:00 PST Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA14352; Mon, 31 Oct 94 01:05:57 PST Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 31 Oct 1994 09:05:44 +0000 To: ipng <@Sun.COM:ipng@sunroof> Subject: Re: (IPng) ATM..MASATAKA'S COMMENTS In-Reply-To: Your message of "Sun, 30 Oct 94 18:11:21 +0200." <9410300911.AA02717@necom830.cc.titech.ac.jp> Date: Mon, 31 Oct 94 09:05:41 +0000 Message-Id: <546.783594341@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> If one is taking Q.2931 to the desktop (and toasters), then we need some >> convenient way of mapping or incorporating E.164 (or the numbering plans in >> NSAPs) into the IP addresses.. >The content of Q.2931 can be carried in IP layer reservation packets >(such as RSVP). As the packet is IP routed, no support for E.164 mapping >is necessary. i'm interested in the idea of RSVP to Q.2931 interworking in general, and think that someone should write a clear architectural paper on how to accomodate traditional singlaling and recveiver initiated signalling (apart from obvious wrappers) basically, i can imagine rsvpd's and q2931ds existing i nthe net from the sender initiated side, for a given group to include receiver initiated joins, there must be a specific member of the sender specified group who runs an rsvpd, which is in the group, and acts as a proxy, so that there is a 'sender' to the group for whom the rsvp go to in some sense (the igmp/multicast routing and point-multipoint call stuff can be done similarly, but need not - we want a good separation of control and data functionality) from a receiver initiated side, one (or more) receiver (who may or may not be a sender) must run a q2931d which accepts q2931 requests from senders, and issues rsvp's now draw this lot on top of the ctl and data routing paths:-) jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 02:34:43 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08672; Mon, 31 Oct 94 02:34:43 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08666; Mon, 31 Oct 94 02:34:36 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA22886; Mon, 31 Oct 94 02:30:03 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA18826; Mon, 31 Oct 94 02:29:50 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 31 Oct 94 19:22:17 +0900 From: Masataka Ohta Message-Id: <9410311022.AA07886@necom830.cc.titech.ac.jp> Subject: Re: (IPng) ATM..MASATAKA'S COMMENTS To: ipng@sunroof Date: Mon, 31 Oct 94 19:22:16 JST In-Reply-To: <546.783594341@cs.ucl.ac.uk>; from "Jon Crowcroft" at Oct 31, 94 9:05 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > i'm interested in the idea of RSVP to Q.2931 interworking in general, > and think that someone should write a clear architectural paper on how > to accomodate traditional singlaling and recveiver initiated > signalling (apart from obvious wrappers) I don't think it so complex. RSVP is for the internetwork layer, while Q.2931 is for the link layer. Just as ARP is issued from a router to the next hop router, Q.2931 should be issued from a router to setup bridges upto the next hop router. > from a receiver initiated side, one (or more) receiver (who may or may not be a > sender) must run a q2931d which accepts q2931 requests from senders, and issues > rsvp's Because of proper layering, there are no q2931d. Rsvpd should issue Q.2931 packet, instead. > now draw this lot on top of the ctl and data routing paths:-) Receiver---B------Router-B-B--B--Router--B--B---Router---B-----Sender ------------+--------------+--------------+-----------> RSVP <--------- <--------- <--------- <--------- Q.2931 Q.2931 Q.2931 Q.2931 'B' denotes ATM swiches acting as bridges. Isn't it too trivial to be fun? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 02:46:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08689; Mon, 31 Oct 94 02:46:22 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08683; Mon, 31 Oct 94 02:46:15 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA23161; Mon, 31 Oct 94 02:41:47 PST Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA19590; Mon, 31 Oct 94 02:41:43 PST Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 31 Oct 1994 10:41:12 +0000 To: ipng <@Sun.COM:ipng@sunroof> Subject: Re: (IPng) ATM..MASATAKA'S COMMENTS In-Reply-To: Your message of "Mon, 31 Oct 94 19:22:16 +0200." <9410311022.AA07886@necom830.cc.titech.ac.jp> Date: Mon, 31 Oct 94 10:41:04 +0000 Message-Id: <1194.783600064@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> i'm interested in the idea of RSVP to Q.2931 interworking in general, >> and think that someone should write a clear architectural paper on how >> to accomodate traditional singlaling and recveiver initiated >> signalling (apart from obvious wrappers) >I don't think it so complex. >RSVP is for the internetwork layer, while Q.2931 is for the link layer. yes. howver, IP & ARP are related by exactly the _reverse_ assumption about connectivity than Q.2931 and RSVP ARP assumes you can reach everyone before you can send IP and being lower layer(ish) pre-dates IP in usage RSVP assumes you can reach everyone to make your reservation, but Q.2931 must go the 'other way'; first, while the 'other way' doesnt exist yet... you have a deadlocked bootstrap problem unless you assume PVCs for Q.2931/RSVP interactions....wich is precisely the purpose of the rsvpds and q932ds >Just as ARP is issued from a router to the next hop router, Q.2931 >should be issued from a router to setup bridges upto the next hop >router. > >> from a receiver initiated side, one (or more) receiver (who may or may not be a >> sender) must run a q2931d which accepts q2931 requests from senders, and issues >> rsvp's > >Because of proper layering, there are no q2931d. Rsvpd should issue >Q.2931 packet, instead. > >> now draw this lot on top of the ctl and data routing paths:-) > >Receiver---B------Router-B-B--B--Router--B--B---Router---B-----Sender > > ------------+--------------+--------------+-----------> > RSVP > > <--------- <--------- <--------- <--------- > Q.2931 Q.2931 Q.2931 Q.2931 > >'B' denotes ATM swiches acting as bridges. > >Isn't it too trivial to be fun? hmmmm....yes, if you can run atm switches as bridges in the WAN - i'm not sure if the operators will be happy with that "open" access, since what is to stop the user sending their data that way as we;ll as thier reservation ctl packets? jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 03:46:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08737; Mon, 31 Oct 94 03:46:33 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08731; Mon, 31 Oct 94 03:46:26 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA24633; Mon, 31 Oct 94 03:41:52 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA26074; Mon, 31 Oct 94 03:41:27 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 31 Oct 94 20:34:04 +0900 From: Masataka Ohta Message-Id: <9410311134.AA08146@necom830.cc.titech.ac.jp> Subject: Re: (IPng) ATM..MASATAKA'S COMMENTS To: ipng@sunroof Date: Mon, 31 Oct 94 20:34:02 JST In-Reply-To: <1194.783600064@cs.ucl.ac.uk>; from "Jon Crowcroft" at Oct 31, 94 10:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > > >> i'm interested in the idea of RSVP to Q.2931 interworking in general, > >> and think that someone should write a clear architectural paper on how > >> to accomodate traditional singlaling and recveiver initiated > >> signalling (apart from obvious wrappers) > > >I don't think it so complex. > >RSVP is for the internetwork layer, while Q.2931 is for the link layer. > > yes. howver, IP & ARP are related by exactly the _reverse_ assumption > about connectivity than Q.2931 and RSVP It's OK. You can even construct a connection oriented layer over connection less layer or vice versa. Reservation direction is a minor difference. Instead, I think RSVP may lack the protocol for intra-link-layer reservation negotiation. > ARP assumes you can reach everyone before you can send IP > and being lower layer(ish) pre-dates IP in usage Both ARP and Q.2931 can reach everyone before you can send IP. > RSVP assumes you can reach everyone to make your reservation, but > Q.2931 must go the 'other way'; first, while the 'other way' doesnt > exist yet... RSVP, located at the internetworking layer, does not see bridges. For ESVP, routers are directly connected. > you have a deadlocked bootstrap problem unless you assume PVCs for > Q.2931/RSVP interactions....wich is precisely the purpose of the > rsvpds and q932ds Not at all. If bootstrapping is the issue, how can you send the first RSVP packet on non-ATM network? I do assume adjacent ATM routers are connected by non-QoS-assured SVCs, through which RSVP packets travels. > >Receiver---B------Router-B-B--B--Router--B--B---Router---B-----Sender > >Isn't it too trivial to be fun? > hmmmm....yes, if you can run atm switches as bridges in the WAN - i'm > not sure if the operators will be happy with that "open" access, since > what is to stop the user sending their data that way as we;ll as thier > reservation ctl packets? Why do you think WAN does not contain routers? As I already wrote, I assume WAN providers will, under free competition, use IPv6 addressing hierarchy, not E.164, which means WAN providers use IP routers within them. That's what the Internet WAN providers today are actually doing. WAN providers use routers as firewalls to subscribers. And, as discussed in RSVP list today, RSVP firewall is also trivial. See draft-ohta-shared-media-01.txt, which is a parody against RFC1620, for further trivial architectural discussion. See draft-ohta-ip-over-atm-01.txt on how you can construct an ATM router, a network layer cell level relay. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 05:42:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08832; Mon, 31 Oct 94 05:42:28 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08826; Mon, 31 Oct 94 05:42:21 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA27402; Mon, 31 Oct 94 05:37:47 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03402; Mon, 31 Oct 94 05:37:45 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA12788; Mon, 31 Oct 94 05:32:32 -0800 Received: by xirtlu.zk3.dec.com; id AA12326; Mon, 31 Oct 1994 08:32:30 -0500 Message-Id: <9410311332.AA12326@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) Re: Security Considerations In-Reply-To: Your message of "Sun, 30 Oct 94 17:34:23 GMT." <9410301734.aa10476@sundance.itd.nrl.navy.mil> Date: Mon, 31 Oct 94 08:32:24 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ran, Well yes Alex and Bill's ideas are evolving by mail thats what working groups are for. Its clear to me and if its not to you that is not good maybe Alex can send mail highlighting at this point exactly where his proposal is at, and where him and Bill diverge. I think it would be better for folks to read the specs themselves to verify when others tell them that there is an issue rather than stating there might be a problem with a spec from a third party. But I see no security hole in SDRP and I have read the spec you will have to take the actual wording and then below it show me where the security hole is or this entire conversation is academic. This should go to sdrp list (which I am reading too). You do realize in the present IPv6 Specication you can include a hop-by-hop option that is not part of the integrity assurance computation performed when an Authentication Header is present. Also we are no longer building proposals for IPng but building IPv6. SIPP was not the proposal selected it was modified and all the specs are not cast in concrete and must become IPv6 specs and hopefully sent to Bob Hinden as editor. But first many of them need extensive discussion and verification for technical accuracy and robustness. So its imperative that clear and accurate statements pro or con of specs be stated referencing that specification. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 05:45:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08859; Mon, 31 Oct 94 05:45:46 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08853; Mon, 31 Oct 94 05:45:39 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27506; Mon, 31 Oct 94 05:41:12 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03797; Mon, 31 Oct 94 05:41:12 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA12987; Mon, 31 Oct 94 05:35:34 -0800 Received: by xirtlu.zk3.dec.com; id AA12403; Mon, 31 Oct 1994 08:35:32 -0500 Message-Id: <9410311335.AA12403@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng Implementor Meeting Minutes Date: Mon, 31 Oct 94 08:35:26 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Chairs, We need to share the discussions at the Oct 10-12 implementor meeting minutes with the working group. Its been 3 weeks since the meeting! I think its reasonable for us to see these minutes A.S.A.P. at this point, because it has input to several ongoing technical discussions on the mail list. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 06:13:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08880; Mon, 31 Oct 94 06:13:16 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08874; Mon, 31 Oct 94 06:13:10 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA28420; Mon, 31 Oct 94 06:08:35 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA06656; Mon, 31 Oct 94 06:08:27 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA14908; Mon, 31 Oct 94 06:04:04 -0800 Received: by xirtlu.zk3.dec.com; id AA13432; Mon, 31 Oct 1994 09:03:56 -0500 Message-Id: <9410311403.AA13432@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) IPv6 Local File Network Address/Name Support for Transition In-Reply-To: Your message of "Sun, 30 Oct 94 14:48:25 GMT." <3373.bill.simpson@um.cc.umich.edu> Date: Mon, 31 Oct 94 09:03:49 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I am moving this to ngtrans. Bill is right in theory on not using two lists. So I will respond to all mail on ngtrans to be a team player on lists. If any of you implementors out there are not on ngtrans please send me private mail bound@zk3.dec.com. I am concerned that the list is not as robust as ipng base group. If that is true then I have a problem with that. Yes I did send it at 1 a.m. but its been too quiet prior to this mail IMHO. Unless we all agree that SIT overview is a done deal. There is an issue with Local Files in that DNS is not REQUIRED. What I am concerned about and want to see discussed is should it be REQUIRED to be deployed with updated IPv6 AAAA records. I have seen very negative affects requiring this in other protocol transitions. I will respoond to Bill, John, and Ran on ngtrans. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 07:08:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09012; Mon, 31 Oct 94 07:08:44 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09006; Mon, 31 Oct 94 07:08:36 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA00387; Mon, 31 Oct 94 07:04:01 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA14123; Mon, 31 Oct 94 07:03:49 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA19275; Mon, 31 Oct 94 06:59:25 -0800 Received: by xirtlu.zk3.dec.com; id AA16576; Mon, 31 Oct 1994 09:59:22 -0500 Message-Id: <9410311459.AA16576@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Mon, 31 Oct 94 06:54:14 +0200." <9410302154.AA04597@necom830.cc.titech.ac.jp> Date: Mon, 31 Oct 94 09:59:15 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Not exactly correct: >> >> a. all-nodes >> b. all-routers >> c. solicited-nodes (block of 256) >> >> All-hosts is not used in discovery. >I heard IPng will actively support multiple IP addresses for a single >interface. >If so, and if I understand your specification correctly, each IP >address needs another multicast address for the case c. >So, is it possible to support them with interface chips which does not >support so much multicast addresses? Masataka asks a very important question. My intelligence is the answer is yes and this will be done in software. Do others disagree? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 07:13:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09024; Mon, 31 Oct 94 07:13:59 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09018; Mon, 31 Oct 94 07:13:52 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA00697; Mon, 31 Oct 94 07:09:26 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA15125; Mon, 31 Oct 94 07:09:23 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA18848; Mon, 31 Oct 94 06:55:17 -0800 Received: by xirtlu.zk3.dec.com; id AA16337; Mon, 31 Oct 1994 09:55:15 -0500 Message-Id: <9410311455.AA16337@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Sun, 30 Oct 94 14:57:05 GMT." <3375.bill.simpson@um.cc.umich.edu> Date: Mon, 31 Oct 94 09:55:08 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> 1. ALL-HOSTS-MULTICAST >> 2. ALL-ROUTERS-MULTICAST >> 3. ALL-NODES-MULTICAST >> >Not exactly correct: > a. all-nodes > b. all-routers > c. solicited-nodes (block of 256) I can find "c" in the specs? What page which spec? In draft-hinden-ipng-00.txt it says on page 12 All Nodes Address which I transformed into ALL-NODES-MULTICAST. >All-hosts is not used in discovery. Well it should be for solicitation if I don't want to bother the routers. This is my interpretation of the specs so clarity would help. But now we are on new thread and I think it all-hosts should be used for solicitation. Aha. Maybe we have another issue I thought was fixed. I believe hosts should be able to send out general solicitations.? Do you disagree with this? If so we have more to resolve for implementation of system discovery. > The point of using multicast as opposed to IPv4 style broadcast is to > provide a more expedient decision at the link layer to discard the > packet. If routers process ALL-HOSTS-MULTICAST or hosts process > ALL-ROUTERS-MULTICAST then nothing has be gained by defining these > multicast packet types over broadcast. > ... > This is my interpretation of the specifications at present. It might be > good to have some words in the specs to make all this much clearer to a > reader or implementor. Unless my interpretation is wrong? >The definitions of all-XXX multicast are in the address spec. Perhaps >they could be elaborated upon there. I agree this needs to be clear. >We should put the solicited-node block there, too. Yep its not there now. > In the media resolution software for missing or timed-out entries the test > must be done again to see if the dest address is a router. If it > is the address must be discovered with an ALL-ROUTERS-MULTICAST packet. > >Absolutely NOT! Absolutely yes unless you want to overload the hosts solicitation for other nodes via All-hosts-multicast (which we don't agree on above). The overload will let routers now receive packets that may not be for the router. >Media resolution is _never_ used for a router. That's in router >advertisements. How does the router discover the host address? Or in the case where the router needs to connect to a host as a telnet server or client response? That was part of what I was questioning in my mail. >If the router entry times out, you cannot use that router! That's the >point of having lifetimes. I agree. But then I can send as a host the all-router-multicast and get an update without waiting for the router advertisement. >Either use another router, or (when there are no more routers in your >list) return ICMP unreachable. No my implementation work right now is going to send out an all-routers-multicast packet before I blow away the application with an ICMP unreachable. We diverge big time here in design views of system discovery. >> Routers can still use the ALL-HOSTS-MULTICAST solicitation to resolve >> host addresses as the reply is a unicast. >> >Absolutely NOT! >The Solicited-Node multicast is used, and the reply is multicast! This is a complete waste and takes away any benefit of the differentiation os all-hosts, all-routers, and all-nodes multicast use. Again we really diverge here and I guess I don't agree with your paradigm for discovery use of the the all-xxx multicast packets and how then can be used to enhance the present discovery of IPv4 based on discovery all-xxx multicast packets. Good thing I sent this message out as I would like to see others on this list discuss the issue too. Not just Bill and I if possible. This is very important because if we continue to diverge I am so against what Bill stated I will quickly put out version of the use I feel all-xxx multicast packets should be used for in IPv6 for routers and hosts. But lets try some discussion first. Would other host and router implementors please jump in here. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 07:55:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09065; Mon, 31 Oct 94 07:55:00 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09059; Mon, 31 Oct 94 07:54:53 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA02792; Mon, 31 Oct 94 07:50:28 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA22434; Mon, 31 Oct 94 07:50:24 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14656(2)>; Mon, 31 Oct 1994 07:50:09 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12172>; Mon, 31 Oct 1994 07:49:57 -0800 To: ipng@sunroof Cc: deering@parc.xerox.com Subject: Re: (IPng) IPng Implementor Meeting Minutes In-Reply-To: bound's message of Mon, 31 Oct 94 05:35:26 -0800. <9410311335.AA12403@xirtlu.zk3.dec.com> Date: Mon, 31 Oct 1994 07:49:54 PST From: Steve Deering Message-Id: <94Oct31.074957pst.12172@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > > We need to share the discussions at the Oct 10-12 implementor meeting > minutes with the working group. Its been 3 weeks since the meeting! I > think its reasonable for us to see these minutes A.S.A.P. at this point, > because it has input to several ongoing technical discussions on the > mail list. Yes. Bob Hinden collected the minutes from Frank and Ross and started editing them, but was sidetracked by a trip to the Paris Interop last week; I think he's back now, so they should appear very shortly. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 08:12:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09090; Mon, 31 Oct 94 08:12:09 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09084; Mon, 31 Oct 94 08:12:01 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05748; Mon, 31 Oct 94 08:07:33 PST Received: from sirius.ctr.columbia.edu by Sun.COM (sun-barr.Sun.COM) id AA25645; Mon, 31 Oct 94 08:07:15 PST Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20913; Mon, 31 Oct 1994 09:40:39 -0500 From: hiroshi@ctr.columbia.edu (Hiroshi Esaki) Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14662; Mon, 31 Oct 1994 09:40:36 -0500 Date: Mon, 31 Oct 1994 09:40:36 -0500 Message-Id: <199410311440.JAA14662@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.Eng.Sun.COM, colip-atm@necom830.cc.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.OZ.AU Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: (IPng) Announcement of new mailing-list (correction) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dear for the persons who are interested in a new mailing-list (colip), ***** I wrote a wrong addresses for mailing-list (:-|) ***** The below is the correct one. We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- >> General Discussion: colip-atm@necom830.cc.titech.ac.jp >> To subscribe: colip-atm-request@necom830.cc.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ---------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 08:32:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09120; Mon, 31 Oct 94 08:32:30 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09114; Mon, 31 Oct 94 08:32:23 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07762; Mon, 31 Oct 94 08:27:55 PST Received: from sirius.ctr.columbia.edu ([128.59.64.60]) by Sun.COM (sun-barr.Sun.COM) id AA29116; Mon, 31 Oct 94 08:26:58 PST Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20389; Mon, 31 Oct 1994 09:01:17 -0500 From: hiroshi@ctr.columbia.edu (Hiroshi Esaki) Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14424; Mon, 31 Oct 1994 09:01:15 -0500 Date: Mon, 31 Oct 1994 09:01:15 -0500 Message-Id: <199410311401.JAA14424@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.Eng.Sun.COM, colip@necom830.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.OZ.AU Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: (IPng) Announcement of New Mailing-List Creation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dear everybody, Knock, knock, " TRICK or TREAT ? " We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- General Discussion: colip-atm@necom830.titech.ac.jp To subscribe: colip-atm-request@necom830.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ---------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 09:05:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09152; Mon, 31 Oct 94 09:05:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09146; Mon, 31 Oct 94 09:05:30 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11936; Mon, 31 Oct 94 09:01:03 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05379; Mon, 31 Oct 94 09:01:00 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA28434; Mon, 31 Oct 94 08:43:10 -0800 Received: by xirtlu.zk3.dec.com; id AA21152; Mon, 31 Oct 1994 11:43:01 -0500 Message-Id: <9410311643.AA21152@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IETF IPng Base Group Meeting Date: Mon, 31 Oct 94 11:42:55 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Thanks for the response on the implementors meeting. Couple of items. I sent mail to Megan to ask for an IETF room Sunday from 1-6 p.m. and Friday 9-Noon. Have not heard back yet but we will have these times for implementor issues discussion again at the next IETF. I may have to leave Thurs eve this time so I may not be around on Friday. For our IETF sessions can we think seriously about the format of these meetings in San Jose. Standard updates are OK but we need real discussions. Several comments by implementors at the implementors meeting off line (and now by me as I started setting up where I want to add code where I am working on IPv6) is that these specs as a complete unit are not implementable. You are seeing this in system discovery and for transition though they are minor thats only cause the momentum has started to be able to write code since the changes per the decision in Tornoto. I think the San Jose IPng base group, transition, and autoconfig needs to structure the meeting in such a manner to flush out real implementation issues on routers and hosts, as some input to you. I will duplicate this mail to addrconf and ngtrans too. I am not yelling doom but that we are at a point where we need to make very sure the ideas (not concrete this is how it is) proposed can be implemented and are also the best way to approach implementing IPv6 (which may be questioned in San Jose too). Finally I would rather have late specs that are ready in July 95 than early ones that are not implementable or not the best approach by Mar 95. We should not let politics or for any reason people who want to jump start the market cause us to not do the very best job with the set of specifications to define what exactly is IPv6. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 11:38:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09361; Mon, 31 Oct 94 11:38:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09355; Mon, 31 Oct 94 11:38:13 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01739; Mon, 31 Oct 94 11:33:39 PST Received: from sirius.ctr.columbia.edu ([128.59.64.60]) by Sun.COM (sun-barr.Sun.COM) id AA03639; Mon, 31 Oct 94 11:30:17 PST Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20487; Mon, 31 Oct 1994 09:14:44 -0500 From: hiroshi@ctr.columbia.edu (Hiroshi Esaki) Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14496; Mon, 31 Oct 1994 09:14:42 -0500 Date: Mon, 31 Oct 1994 09:14:42 -0500 Message-Id: <199410311414.JAA14496@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.Eng.Sun.COM, colip@necom830.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.OZ.AU Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: (IPng) Announcement of New Mailing-List Creation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dear everybody, Knock, knock, " TRICK or TREAT ? " We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- General Discussion: colip-atm@necom830.titech.ac.jp To subscribe: colip-atm-request@necom830.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ---------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 12:00:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09385; Mon, 31 Oct 94 12:00:31 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09379; Mon, 31 Oct 94 12:00:24 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA23588; Mon, 31 Oct 94 11:55:58 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA07951; Mon, 31 Oct 94 11:55:05 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA00850; Mon, 31 Oct 1994 14:54:52 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA23256; Mon, 31 Oct 1994 14:54:50 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA17237; Mon, 31 Oct 1994 14:31:22 -0500 Message-Id: <9410311931.AA17237@brigit.zk3.dec.com> To: ipng@sunroof Cc: conta@zk3.dec.com Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Mon, 31 Oct 94 09:59:15 EST." <9410311459.AA16576@xirtlu.zk3.dec.com> Date: Mon, 31 Oct 94 14:31:21 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: bound@zk3.dec.com >> Not exactly correct: >> >> a. all-nodes >> b. all-routers >> c. solicited-nodes (block of 256) >> >> All-hosts is not used in discovery. >I heard IPng will actively support multiple IP addresses for a single >interface. >If so, and if I understand your specification correctly, each IP >address needs another multicast address for the case c. >So, is it possible to support them with interface chips which does not >support so much multicast addresses? Masataka asks a very important question. My intelligence is the answer is yes and this will be done in software. Do others disagree? /jim The limitation of multicast addresses may occur at two levels: - hardware level - an adapter has a limited number of multicast address registers. The limit can be 0 - no hardware processing of multicast address list - software level - more sophisticated implementations, after reaching the multicast address list hardware level limit, go into multicast address promiscuous mode, in which all multicast addresses are processed in software. Here there may be a limit too, depending on implementation. It is worth to note that when the list of multicast addresses is processed in software, which is most likely the case if the list is long, if the list gets longer than a certain number of addresses the address lookup may become more expensive than listing on 'all-hosts' and letting address lookup filter at at IPv6 layer level. This depends on implementation and processor. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 12:35:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09490; Mon, 31 Oct 94 12:35:09 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09477; Mon, 31 Oct 94 12:34:49 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA26940; Mon, 31 Oct 94 12:30:23 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA14191; Mon, 31 Oct 94 12:29:53 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA08907 for ; Mon, 31 Oct 1994 12:28:24 -0500 Date: Mon, 31 Oct 94 16:21:34 GMT From: "William Allen Simpson" Message-Id: <3377.bill.simpson@um.cc.umich.edu> To: ipng@sunroof Subject: (IPng) multiple addresses per interface Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Masataka Ohta > I heard IPng will actively support multiple IP addresses for a single > interface. > > If so, and if I understand your specification correctly, each IP > address needs another multicast address for the case c. > Yes. > So, is it possible to support them with interface chips which does not > support so much multicast addresses? > Well, you have to support a multicast address for every group you join, too. That could be a lot of addresses! Dunno if it works on all chips. What chip did you have in mind? Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 12:40:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09507; Mon, 31 Oct 94 12:40:17 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09501; Mon, 31 Oct 94 12:40:05 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA27426; Mon, 31 Oct 94 12:35:38 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB14191; Mon, 31 Oct 94 12:30:30 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA08910 for ; Mon, 31 Oct 1994 12:28:26 -0500 Date: Mon, 31 Oct 94 16:25:32 GMT From: "William Allen Simpson" Message-Id: <3378.bill.simpson@um.cc.umich.edu> To: ipng@sunroof Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > > a. all-nodes > > b. all-routers > > c. solicited-nodes (block of 256) > > I can find "c" in the specs? Perhaps you mean "can't"? > What page which spec? > Processing p 5. Looks like I should add a "Link Header (if any)" section to each header description in the Formats, for cross reference. Will that tie the documents together better? Will do. > >All-hosts is not used in discovery. > > Well it should be for solicitation if I don't want to bother the routers. > No, when soliciting, use solicited-node. This avoids bothering a lot of hosts, which are more numerous than the routers. Only hosts join solicited-node. > Aha. Maybe we have another issue I thought was fixed. I believe hosts > should be able to send out general solicitations.? > Yes, both hosts and routers send general solicitations, to the solicited-node multicast. The solicited-node multicast is not used in the IPv6 header. It only appears in the LINK header. But it still needs to be reserved, so that IPv6 won't use those addresses. > ... unless you want to overload the hosts solicitation for > other nodes via All-hosts-multicast (which we don't agree on above). > The overload will let routers now receive packets that may not be for > the router. > Look, you misunderstand several things in the documents. Obviously, I either need more explanation, or I need _less_ explanation so that the topic isn't obscured. Yes, the solicited-node "overloads" a portion of all-hosts -- 1/256. All-hosts is not used (for discovery). > >Media resolution is _never_ used for a router. That's in router > >advertisements. > > How does the router discover the host address? FOR a router, not FROM a router! Of course a router uses media resolution to find hosts. > >If the router entry times out, you cannot use that router! That's the > >point of having lifetimes. > > I agree. But then I can send as a host the all-router-multicast and get > an update without waiting for the router advertisement. > By all the Gods above and below, please re-read the Processing section 3. Or Deering's RFC-1256. Or get somebody to explain verbally. The list turnaround is simply too slow. You only send solicitations under certain circumstances. You NEVER, NEVER, NEVER send router-solicitation after that. You _MUST_ wait for the advertisement. > No my implementation work right now is going to send out an > all-routers-multicast packet before I blow away the application with an > ICMP unreachable. > Then your implementation is simply non-conformant. > We diverge big time here in design views of system discovery. More accurately, you have never implemented router discovery before, and still don't understand the mechanisms. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 12:54:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09524; Mon, 31 Oct 94 12:54:23 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09518; Mon, 31 Oct 94 12:54:16 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA28922; Mon, 31 Oct 94 12:49:49 PST Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA16702; Mon, 31 Oct 94 12:46:22 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA00225; Mon, 31 Oct 1994 14:41:38 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA22151; Mon, 31 Oct 1994 14:41:36 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA17211; Mon, 31 Oct 1994 14:18:08 -0500 Message-Id: <9410311918.AA17211@brigit.zk3.dec.com> To: ipng@sunroof Cc: conta@zk3.dec.com Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Sun, 30 Oct 94 14:57:05 GMT." <3375.bill.simpson@um.cc.umich.edu> Date: Mon, 31 Oct 94 14:18:08 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill.Simpson@um.cc.umich.edu, wrote: > From: bound@zk3.dec.com > We have three types of multicast for discovery: > > 1. ALL-HOSTS-MULTICAST > 2. ALL-ROUTERS-MULTICAST > 3. ALL-NODES-MULTICAST > Not exactly correct: a. all-nodes b. all-routers c. solicited-nodes (block of 256) All-hosts is not used in discovery. This points me back to the implementors meeting discussions. There we discussed two aspects of the what Bill calls 'solicited-nodes', and that is: 1. The unlimited number of IPv6 addresses that one may have on an interface, will create the need for a large number of multicast addresses - Masataka raised a good point and a point thet has been discussed at the implementros meeting. 2. The address resolution group, which Bill called "solicited-{hosts, nodes}", is not always offering the granularity counted on - see bellow for more explanations. Given the above, at the implementors meeting, the conclusion was that the 'address resolution' group is not worth using. In light of the above, I would like to understand better the reference to the 'discovery' specs, and perhaps Bill could elaborate on that: a. specs previous to the implementors meeting. b. specs in which the discussions, and conclusions from the implementors meeting were included > The point of using multicast as opposed to IPv4 style broadcast is to > provide a more expedient decision at the link layer to discard the > packet. If routers process ALL-HOSTS-MULTICAST or hosts process > ALL-ROUTERS-MULTICAST then nothing has be gained by defining these > multicast packet types over broadcast. > ... > This is my interpretation of the specifications at present. It might be > good to have some words in the specs to make all this much clearer to a > reader or implementor. Unless my interpretation is wrong? The definitions of all-XXX multicast are in the address spec. Perhaps they could be elaborated upon there. We should put the solicited-node block there, too. I looked intensely through the specifications to find text about addresses a host, and a router listen on. I found: At page 12, in the "IPng Addressing Architecture" from October 1994, by Bob Hinden, Editor, it is specified: - beginninig of text from draft A router is required to recognize the following addresses as identifying itself: o Assigned Unicast Addresses o Cluster Addresses of all clusters for which the router is a boundary router o Loopback Address o All Nodes Multicast Address o All Hosts Multicast address o All other Multicast Addresses to which the router belongs. - end of text from draft Jim made a point relative to this earlier. > In the media resolution software for missing or timed-out entries the test > must be done again to see if the dest address is a router. If it > is the address must be discovered with an ALL-ROUTERS-MULTICAST packet. > Absolutely NOT! Media resolution is _never_ used for a router. That's in router advertisements. If the router entry times out, you cannot use that router! That's the point of having lifetimes. Jim's point was missed here. What about a router's host function, as opposed to a router's router function, such as: telnet "my_router_address_on_subnet". Either use another router, or (when there are no more routers in your list) return ICMP unreachable. You're a host trying to send a packet, so you would return an ICMP to yourself? > Routers can still use the ALL-HOSTS-MULTICAST solicitation to resolve > host addresses as the reply is a unicast. > Absolutely NOT! The Solicited-Node multicast is used, and the reply is multicast! Again, here we have a "pre" versus "after" implementors meeting issue. This was discussed there. Alex Conta ------------------------ Detailed explanations: 2. if the address space on a link is not allocated contiguously (or densely), and is not sufficiently populated, then the multicast groups defined for address resolution may offer no granularity at all: Just to illustrate that, in a simplified example (3 bytes of address), if I have on a link hosts with the following addresses: 4.2.1, 2.4.1, 1.2.4, 1.4.2 4.1.2 2.1.4 3.0.4 4.0.3, and others The "address resolution multicast group" value according to the formula from the "pre-implementors meeting specs" is for all the above hosts 7. If these are all and only hosts on that link, this results in no-more granularity than "all-hosts" ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 13:04:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09542; Mon, 31 Oct 94 13:04:24 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09536; Mon, 31 Oct 94 13:04:13 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA00133; Mon, 31 Oct 94 12:59:42 PST Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA18335; Mon, 31 Oct 94 12:55:56 PST Received: by rodan.UU.NET id QQxoat27842; Mon, 31 Oct 1994 15:55:05 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery To: ipng@sunroof Date: Mon, 31 Oct 1994 15:55:04 -0500 (EST) In-Reply-To: <9410311931.AA17237@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Oct 31, 94 02:31:21 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 3114 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...I word-wraped the following text, and added the ">", but it is otherwise unchanged...] I susspect the original author may have been refering only to ethernet hardware, I am restricting my reply to ethernet hardware, since I don't know how FDDI, ATM, and the like work at the chip interface level. >The limitation of multicast addresses may occur at two levels: > - hardware level - an adapter has a limited number of multicast > address registers. The limit can be 0 - no hardware processing of > multicast address list There is another way ethernet hardware works: Incoming multicast packets have their dest MAC address hashed and that hash value is used as an index into a bit vector, which tells the chip to send the packed on to software, or drop it. I know the AMD Lance works this way (the hash is a 16bit CRC, of which the low 6ish bits to index into a pair of 32bit wide registers). I think this is the same in the C-Lance (which is available as a "glueless" ISA chip, a "glueless" PCI chip, and a "glueless" PCI chip with SCSI2, and I think the quantity prices are fairly low, I seem to remember the ethernet-only chips being around $30 - however the parts are not entirely glueless, but that's a matter for another mailing list...). I beleve the Lance is fairly popular in workstations (all the desktop Sun4's and many Sun3's have them). I don't know how popular the C-Lance is in the PC world. The Intel 82586 also uses (or at least can use) the same method, or at least the documentation implys it (it says that unwanted multicast packets may slip through the hardware, and software should check - it also allows one to specify approx 16384 bytes worth of multicast address). Unfortunitily I can't say how popular this feature is - I only have in-depth knolage of those two ethernet parts. (I have looked at the data books for others, but I didn't pay much attention to multicast at the time) [...] >It is worth to note that when the list of multicast addresses is >processed in software, which is most likely the case if the list is long, >if the list gets longer than a certain number of addresses the address >lookup may become more expensive than listing on 'all-hosts' and letting >address lookup filter at at IPv6 layer level. This depends on >implementation and processor. I know it depends on the implmentation, but I don't see why for any given processer, one couldn't make a lookup on a 6 byte field (the MAC address) at least as fast as the lookup on 16ish bytes (the IPv6 multicast - I know it isn't a full 16 bytes, but I can't recall how many bytes are used to say "the rest of the address is a multicast address", is it 2?). If the objection is that the "MAC test" must be done at intrrupt level, while the IPv6 test could be done at some other level, then I think that is an implemation choice, not something forced by the protocall design. In short, I beleve that nothing stops an implmentation from making the IPv6 lookup as fast as possable, and the multicast-MAC lookup at least as fast - at least assuming the same resources are devoted to both. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 15:56:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09687; Mon, 31 Oct 94 15:56:26 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09681; Mon, 31 Oct 94 15:56:19 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA11952; Mon, 31 Oct 94 15:51:53 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19446; Mon, 31 Oct 94 15:51:13 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA27521; Mon, 31 Oct 94 14:58:24 -0800 Received: by xirtlu.zk3.dec.com; id AA04618; Mon, 31 Oct 1994 17:57:05 -0500 Message-Id: <9410312257.AA04618@xirtlu.zk3.dec.com> To: ipng@sunroof Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Mon, 31 Oct 94 16:25:32 GMT." <3378.bill.simpson@um.cc.umich.edu> Date: Mon, 31 Oct 94 17:56:59 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> What page which spec? >> >Processing p 5. >Looks like I should add a "Link Header (if any)" section to each header >description in the Formats, for cross reference. Will that tie the >documents together better? Will do. I thought you were changing this for some reason? I thought solicited-nodes had become all-nodes-multicast. This changes things and I need to do reset. Yes this type of multicast can be very efficient. I thought you backed off of that at the implementors meeting. >You only send solicitations under certain circumstances. You NEVER, >NEVER, NEVER send router-solicitation after that. You _MUST_ wait for >the advertisement. Bull. I know 1256 and your discovery and this is an issue. But I see no point in talking to you right now your tone is unacceptable. I think we need a new discovery spec and yours is not working. Sorry folks I can't take his attitude anymore he is impossible almost to work with. I will think on this but I believe the working group needs a better spec this one is full of holes and changes with each discussion. Not implementable and I am done working with Bill for right now. The IETF needs an implementable spec. If I respond to anymore of his mail it will not be good. Bill do not send me mail and stay away from me when we are in person anywhere for awhile. Thank you. You have gone beyond the boundary I permit people in my life to go. I have tried to support you, listen to you, and have read in detail all your work and understand it and I have implemented disocovery on the kind of machines I believe you may be working on. Nothing is worth your abuse to me nothing at all. Why did you have to bring it to this point? I can't believe it. You have no clue who your talking to on this list other than they are trying to get something done in the IETF. How can you be so insulting? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 19:47:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09831; Mon, 31 Oct 94 19:47:19 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09825; Mon, 31 Oct 94 19:47:12 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA23994; Mon, 31 Oct 94 19:42:46 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA12283; Mon, 31 Oct 94 19:42:43 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA15176; Mon, 31 Oct 1994 21:38:00 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA17089; Mon, 31 Oct 1994 21:37:59 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA17688; Mon, 31 Oct 1994 21:14:30 -0500 Message-Id: <9411010214.AA17688@brigit.zk3.dec.com> To: ipng@sunroof Cc: conta@zk3.dec.com Subject: Re: (IPng) IPv6 Local File Network Address/Name Support for Transition In-Reply-To: Your message of "Sun, 30 Oct 94 17:23:48 EST." Date: Mon, 31 Oct 94 21:14:30 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: "William Allen Simpson" > Our ngtrans list seems too quiet so I am sending this to the ipng base > group too as I know we have a lot of good implementors and users > listening on this list. Please don't. I *hate* getting things on two lists. And you just sent the message. You expect instant turnaround? You sent it at 1 am! There were at least 48 hours between the message to 'ngtrans' and 'ipng', the way I received them: Fri, 28 Oct 94 01:27:04 -0400 (ngtrans) Sun, 30 Oct 94 01:56:15 -0500 (ipng) And more then 49 hours when they were sent. Resending after two days, is OK for me, and besides it was effective - it got your attention, and others that probably would have ignored it on 'ngtrans'. And at no surprise you're setting despotically the rules again according to what's good for you (-: - by the way the motto here (New Hampshire) on license plates is "live free or die" (-:. Thanks, Jim for being courteous and changing to the other list. ----------------------- From: John Curran Subject: Re: (IPng) IPv6 Local File Network Address/Name Support for Transition At 9:48 AM 10/30/94, William Allen Simpson wrote: >>(Jim Bound) >> I think we need to specify a local file for >> end users as an option. >> >This is a user interface issue, and doesn't belong in a protocol >specification. > >And I disagree. No implementation of mine will need such problematic >user configuration. Hmm. I agree with both of you: o It might be useful (in some arcane situations) to have a convention for directly specifying IPv6 addresses for particular hosts. I can imagine such being useful in lab situations, during development, etc. I agree with Jim and John. I would go a little further and say: a Local file, or other means to store hosts address information.... o How this "feature" is activated is a user interface issue, and doesn't belong anywhere near the protocol specs. If someone wants to post an informational RFC on "How I added an IPv6 address hardwire capability to XX Unix", then others can follow it or not as they see fit. Me too Hmm ... One may miss a separate RFC. I would see a very succinct model for the file's records in the Appendix for the SIT specs. This way people that use a file to store host information would have a common ground, and different vendors that followed the model may echange files without a need for reformatting its records. If other means of storing such information have such large acceptance among various vendors as files, they could be specified in an Appendix too. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 20:18:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09852; Mon, 31 Oct 94 20:18:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09846; Mon, 31 Oct 94 20:18:31 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01988; Mon, 31 Oct 94 20:14:03 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA17640; Mon, 31 Oct 94 20:14:03 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14477(4)>; Mon, 31 Oct 1994 16:19:41 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12172>; Mon, 31 Oct 1994 16:19:29 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) adding extension headers to a packet in flight Date: Mon, 31 Oct 1994 16:19:15 PST From: Steve Deering Message-Id: <94Oct31.161929pst.12172@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Regarding the issue of inserting extension headers or options into packets in flight (i.e., by nodes other than the original source of the packet), I included a cryptic note in section 4.8 of the base IPv6 spec suggesting that such modifications MUST NOT be permitted. The reasons for outlawing in-flight insertions are as follows: (1) It breaks Path MTU Discovery. Imagine a host that sends a 1000-byte packet on a path with a PMTU of 1000 bytes. If a router before the MTU-bottleneck router inserts an extra header into the packet, thus making the packet longer than 1000 bytes, the bottleneck router will send a Packet Too Big message to the original host, telling it that the MTU is 1000 bytes. But, as we've seen, a 1000-byte packet from that host won't fit in that path! Now, you might suggest that the original host should parse the returned packet fragment in the Packet Too Big message and discover that someone had added an extra header, and take that into account when recording the path's MTU, but I think that's rather complicated to do, and probably impossible in some cases. Besides, host implementors are finding PMTU Discovery to be subtle and difficult enough that I am loathe to make it even more so. (2) It can result in error messages being delivered to the wrong node. In particular, if there is an error in the inserted header, it may cause an ICMP message to be sent to the originating host, which was not responsible for the error, doesn't know why the inserted header is there in the first place, and may not even know what the inserted header means. Meanwhile, the perpetrator of the error will failed to learn of its mistake. (3) It can interfere with correct processing of ICMP error messages by hosts. To dispatch an ICMP error message to the right process in the host receiving an error message, the host has to parse the fragment of its own packet, returned in the error message, to find the guilty transport protocol and port. If the inserted header was of a type that the host does not understand, it will not be able to find the transport header. Even if the host can parse the inserted header, the transport protocol or application may legitimately say "I didn't generate that packet!" and ignore it. (4) It can interfere with reception of packets by destination hosts. If a destination gets a packet into which has been inserted a header of a type unknown to that destination, then the packet will just get dropped (and, if unicast, an "unkown type" message would be sent to the source, who wasn't responsible for sending the header in the first place). (5) It can cause a packet to exceed a receiver's reception/reassembly buffer size. A sender can learn a receiver's maximum buffer size by means beyond the ken of intermediate routers (e.g., through the TCP MSS option), and can send packets of exactly that size. If an intermediate router adds a header to the packet, it will cause the packet to exceed that buffer size and it will be dropped by the receiver. There may be other reasons; those are all I can think of right now. But the basic observation is that there are strong assumptions in the architecture that packets will be delivered the same size that they are sent, and that their contents will not be mucked-with by intermediaries except in well- specified and universally-understood ways, such as decrementing the Hop Limit or processing a Route Header. Now, there may be specific instances of header-insertion that sidestep all of these problems (e.g., only happens on "small" packets, avoids making any errors, is stripped out before final delivery), but I think it's wiser just to avoid the practice altogether. Since it is violating fundamental assumptions, there may be other, unanticipated negative consequences. The alternative to header-insertion is en-route encapsulation and decapsulation (aka tunneling, which has none of the above problems. PMTU discovery can be properly implemented by a "tunnel entrance" (encapsulating) node. Error messages caused by the added stuff (the encapsulating header) are correctly returned to the encapsulator, not to the originating host. All the added stuff is deleted (by decapsulation) before final delivery, so there is no problem of exceeding receiver buffer size or of delivering un-parsable information to the receiver. The drawback of encapsulation is the extra overhead of adding a whole IPv6 header (40 bytes), if the amount of extra info needed is much less than that. I suspect that this overhead is only significant when either the original source or the final destination is also one of the tunnel endpoints (otherwise, you need to add two addresses anyway, which is 32 bytes, plus whatever control info you need, which will bump you up to the next multiple of 8, which is 40 bytes). I've just finished reading the ERP draft by Ford, Li, and Rekhter. In that proposal, they do advocate header-insertion en-route, and have specified ways of dealing with *some* of the problems identified above, e.g., by temporarily moving an original source address into an inserted ERP header and putting the inserter's address in the IPv6 Source Address field, so that error messages go to the right place. However, they do not specify that all inserted info is always stripped out before final delivery (sometimes it is and sometimes it isn't, I believe), and they have a section entitled "Path MTU Handling" which is currently empty. Perhaps it can be polished up to work properly (and perhaps thought of as a "compressed" representation of a semantically-equivalent use of encapsulation), but I have a hunch that they would be better off just using encapsulation (with an IPv6 header plus a variable-length ERP header) to change the routing of a packet in flight. However, I found their proposal somewhat difficult to follow, so maybe once I understand it fully, I will come to see the wisdom of their approach. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 20:44:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09882; Mon, 31 Oct 94 20:44:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09876; Mon, 31 Oct 94 20:44:00 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03151; Mon, 31 Oct 94 20:39:32 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA21513; Mon, 31 Oct 94 20:39:33 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id AAA07657 for ipng@sunroof.Eng.Sun.COM; Tue, 1 Nov 1994 00:41:03 -0500 (EST) Date: Tue, 1 Nov 1994 00:41:03 -0500 (EST) From: Scott Bradner Message-Id: <199411010541.AAA07657@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Local File Network Address/Name Support for Transition Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I would see a very succinct model for the file's records in the Appendix for the SIT specs. I do not think this is a good idea. this is getting rather far from the protocol issues. I agree with John Curran, an informational RFC would be fine here but I can't see the IESG putting this type of file format into a protocol standard. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 22:46:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09980; Mon, 31 Oct 94 22:46:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09974; Mon, 31 Oct 94 22:46:01 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06985; Mon, 31 Oct 94 22:41:33 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA01688; Mon, 31 Oct 94 22:41:30 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA27448; Tue, 1 Nov 1994 00:28:18 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA24152; Tue, 1 Nov 1994 00:28:16 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA18247; Tue, 1 Nov 1994 00:04:48 -0500 Message-Id: <9411010504.AA18247@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) IPv6 Local File Network Address/Name Support for Transition In-Reply-To: Your message of "Tue, 01 Nov 94 00:41:03 EST." <199411010541.AAA07657@newdev.harvard.edu> Date: Tue, 01 Nov 94 00:04:47 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Scott Bradner > I would see a very succinct model for the file's records in the Appendix fo ***r the SIT specs. I do not think this is a good idea. this is getting rather far from the protocol issues. I agree with John Curran, an informational RFC would be fine here but I can't see the IESG putting this type of file format into a protocol standard. Scott Let me qualify a little what I said before. The "transition" document, as the name summarizes it, deals, like any transition documents with lots of issues that are not "protocol" issues per se, but rather "protocol" to "protocol" transition issues. Would you agree with that? >From that prospective, anything that allows a smoother transition from one protocol to the other, is welcome in my view. A network manager - I am one at a very low scale, since I manage myself my two workstations (UNIX and OpenVMS) and a PC (MS-DOS) - would be happier if he/she knew that files that he/she has to deal with for transition and afterwords - the use of a local file, could be a preffered mechanism for many that do not trust completely autoconfiguration and DHCP at the beginning of IPv6, or just a fall-back mechanism, in case of DNS malfunction - to have file records that look the same, on any platform. >From a code portability point of view, routines that parse one record format, could be used practically on any platform, as well. With that I make the correction to my previous message - I referred and meant a record format, and not file format, which are two different things. Once more, with that prospective, I don't see the negative side of an "appendix" or "example of a possible record format" in an "appendix", in the transition document, or in a document that is part of a set of transition documents. Alex does not Transition" specification is a protocol to protocol stack transition specification, rather less a protocol specification and much more is less ----------------------------------------------------------------------------- ***- IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/ ***pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 23:03:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09992; Mon, 31 Oct 94 23:03:50 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09986; Mon, 31 Oct 94 23:03:42 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA28880; Mon, 31 Oct 94 22:59:17 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA14432; Sun, 30 Oct 94 01:34:06 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 30 Oct 94 18:26:49 +0859 From: Masataka Ohta Message-Id: <9410300927.AA02789@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) FLOW LABELS To: ipng@sunroof Date: Sun, 30 Oct 94 18:26:47 JST In-Reply-To: <199410281627.MAA26522@clark.net>; from "Howard Berkowitz" at Oct 28, 94 12:27 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > > Are you saying that locally administered MAC address are not to be > > > allowed? > > > > No, I don't think we have to actively forbid it. They are not used > > anyway. > > Sorry, but they are actively used, primarily in non-IP environments. And that is one of the reason why such non-IP environment is not welcomed by system administrators. > If we did this, it definitely would affect DECnet and other systems. I'd like to keep saying "Sorry, Mr. Manager, but we shouldn't use DECnet because it melts the network". :-) Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 23:17:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10004; Mon, 31 Oct 94 23:17:39 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09998; Mon, 31 Oct 94 23:17:32 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA29361; Mon, 31 Oct 94 23:13:06 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA04421; Mon, 31 Oct 94 23:13:03 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA28366; Tue, 1 Nov 1994 02:13:01 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA29573; Tue, 1 Nov 1994 02:12:59 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA18242; Tue, 1 Nov 1994 01:49:31 -0500 Message-Id: <9411010649.AA18242@brigit.zk3.dec.com> To: ipng@sunroof Cc: conta@zk3.dec.com Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Mon, 31 Oct 94 16:25:32 GMT." <3378.bill.simpson@um.cc.umich.edu> Date: Tue, 01 Nov 94 01:49:31 -0500 From: conta@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: "William Allen Simpson" > >All-hosts is not used in discovery. > > Well it should be for solicitation if I don't want to bother the routers. > No, when soliciting, use solicited-node. This avoids bothering a lot of hosts, which are more numerous than the routers. Only hosts join solicited-node. Then why is 'solicited-node' and not 'solicited-hosts', if it is only a hosts group? And if only hosts join the group, you still didn't resolve the hole in your specifications related to accessing a router's host functions, which I previously pointed out. ... Look, you misunderstand several things in the documents. Obviously, I either need more explanation, or I need _less_ explanation so that the topic isn't obscured. There is a third option that I think should be considered vigorously - better explanation. > >If the router entry times out, you cannot use that router! That's the > >point of having lifetimes. > > I agree. But then I can send as a host the all-router-multicast and get > an update without waiting for the router advertisement. > By all the Gods above and below, please re-read the Processing section 3. Or Deering's RFC-1256. Or get somebody to explain verbally. The list turnaround is simply too slow. You only send solicitations under certain circumstances. You NEVER, NEVER, NEVER send router-solicitation after that. You _MUST_ wait for the advertisement. There is a hole in the specification, in that a host that may have a skewed timer, may timeout a router entry in its routers list before the router re-advertizes routing information about itself. This is not a very often case, but your Gods invocations (-:, and your text, didn't help me understand WHY, for the robustness of communications of such hosts, we do not allow router solicitation on router entry expiration. > No my implementation work right now is going to send out an > all-routers-multicast packet before I blow away the application with an > ICMP unreachable. > Then your implementation is simply non-conformant. Obviously since you just changed your mind about multicast addresses that a host has to send to. > We diverge big time here in design views of system discovery. More accurately, you have never implemented router discovery before, and still don't understand the mechanisms. Bill, you're on the wrong list. You should try your psychic talents on a different Internet mailing list. But here on IPng, I would very much prefer not to have to read this. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 31 23:20:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10020; Mon, 31 Oct 94 23:20:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10014; Mon, 31 Oct 94 23:20:25 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07828; Mon, 31 Oct 94 23:15:57 PST Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA04845; Mon, 31 Oct 94 23:15:46 PST Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA05612; Mon, 31 Oct 1994 23:15:45 -0800 Date: Mon, 31 Oct 1994 23:15:45 -0800 From: Tony Li Message-Id: <199411010715.XAA05612@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Mon, 31 Oct 1994 16:19:15 PST <94Oct31.161929pst.12172@skylark.parc.xerox.com> Subject: (IPng) adding extension headers to a packet in flight Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Your note, while interesting, is wholly out of order for this mailing list. Please move this discussion to the sdrp mailing list: sdrp@catarina.usc.edu To Subscribe: sdrp-request@catarina.usc.edu See you there, Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com