From owner-ipng Tue Nov 1 01:38:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10146; Tue, 1 Nov 94 01:38:11 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10140; Tue, 1 Nov 94 01:38:04 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA05141; Tue, 1 Nov 94 01:33:38 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA17551; Tue, 1 Nov 94 01:33:29 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) multiple addresses per interface To: ipng@sunroof Date: Tue, 1 Nov 1994 09:34:14 +0100 (GMT) In-Reply-To: <3377.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Oct 31, 94 04:21:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 848 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > 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? Most of them I suspect. Some (eg 8390) have hashing filters that may or may not scale well depending upon choice of address -> MAC address mapping. A lot of very old PC type ethernet cards have inane limits (eg Multicast YES/NO) but the modern ones seem pretty reasonable. Given that the 8390 chip (in the form of the 3c503, NE2000 + clones and WD80x3) is probably the most common client PC card it might be worth some mathematical person looking into the hash algorithm and seeing how best to map the choice of multicast addresses. 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 Tue Nov 1 04:16:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10280; Tue, 1 Nov 94 04:16:45 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10274; Tue, 1 Nov 94 04:16:36 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA12249; Tue, 1 Nov 94 04:12:09 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA02273; Tue, 1 Nov 94 04:12:06 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA12608; Tue, 1 Nov 94 06:14:32 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA10702; Tue, 1 Nov 94 06:11:46 CST Date: Tue, 1 Nov 94 06:11:46 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411011211.AA10702@anubis.network.com> To: ipng@sunroof.Sun.COM 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 Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: several messages between Bill Simpson and Jim Bound (?, I hope I guessed your name correctly from these messages) >>> 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. Gentlemen, in the document: the whole addresses "all-nodes" and "all-routers" are not defined, they appear in the document: as a NETWORK LAYER ADDRESS (that is: an IPv6 address. The solicited-nodes multicast appears in as a LINK LAYER (multicast) ADDRESS. When reading the drafts it seemed to me as follows: When the NETWORK LAYER ADDRESS is a unicast address, but the LINK LAYER ADDRESS is unknwon we use the SOLICITED-NODES in the LINK LAYER ADDRESS. When the NETWORK LAYER ADDRESS is a unicast address, and the LINK LAYER ADDRESS is knwon we use the correct and known LINK LAYER ADDRESS. When the NETWORK LAYER ADDRESS is ALL_NODES or ALL_ROUTERS, I can't find a specification what LINK LAYER ADDRESS to use, but it can be either: - a link layer broadcast (would be bad protocol design) - the base solicited-nodes multicast - the base solicited-nodes multicast with the ALL NODES or ALL ROUTER address added to it. I agree that this should be specified in the draft documents, Bill I think you should indeed add a LINK LAYER header specification at some places. > 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. Again: The solicited nodes multicast is a link layer address, such as an Ethernet multicast address. There is no reason to reserve that at the IPv6 level, those address can never mix, since they appear at different layers in the packet header. There is no reason to reserve an IPv6 address as solicited-node multicast. >>>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. >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. When the host and router are working well, the timing-out should never happen, when one of them times-out to fast (incorrectly), they might loose eachother. When we allow a host to send router solicitations, no one will ever care about the incorrect timing (all sessions stay alive, so why bother). That might be as bad as in the most terrible case, that the host times out the router after one microsecond in sending 100% LAN load of router solicitations. I agree a very unlike and extremely fast timeing out, but possible. In Bill's proposal of: "Sorry host, you work incorrect, you're lost" the network is saved from this host, the host looses connections, the people working on it start complaining and the pain is were it should be: at the wrong behaving unit. When the host is allowed to send out router solicitations it might fill a substantial part of the LAN or router, putting the pain in the rest of the network. As a conclusion I think: yes let a bad working host loose its connections and protect the rest of the network from that is robust protocol design. >> 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. A router is for networking management an ordinary host, for telnet, ping and snmp it will have to act as a normal host. I can's see how we can manage the routers on a LAN if they are not reacting as normal hosts on things as "solicited-node" multicasts as the LINK LAYER address. The main benefit of this "solicited-node" multicast is not to protect the routers (if they are bridging also, they will take a short look at all frames anyway), but to protect the hosts against 255/256-st of the multicasts. As last remark, it is a point that most draft documents on IPv6 are not yet fully clear in what should be done in every thinkable situation. The drafts on neighbor discovery need some more information on which link layer addresses to use and some cross references on when to send what kind of frame. But please Bill let's not be to rude in discussing this. Fred PS: Sorry Bill, I see this message is too big again, I'll never learn to split in smaller messages. Fred ------------------------------------------------------------------------------ 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 Nov 1 04:30:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10310; Tue, 1 Nov 94 04:30:18 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10304; Tue, 1 Nov 94 04:30:07 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17876; Tue, 1 Nov 94 04:25:39 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA03325; Tue, 1 Nov 94 04:25:39 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id IAA08224 for ipng@sunroof.Eng.Sun.COM; Tue, 1 Nov 1994 08:27:08 -0500 (EST) Date: Tue, 1 Nov 1994 08:27:08 -0500 (EST) From: Scott Bradner Message-Id: <199411011327.IAA08224@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 Alex, I'm not sure what the difference is between transition and non-transition in this case. A suggested record format sould be there or it should not. I would still rather see this as an informational RFC. An IPv6 implementation could use almost any method to store this information up to and inclusing a relational dtabase and I see little reason to put platform specific information into a base protocol specification. And I would expect that there are a number of IESG members who would object to doing so. I don't think the gain is worth the pain. 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 Tue Nov 1 06:04:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10367; Tue, 1 Nov 94 06:04:54 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10361; Tue, 1 Nov 94 06:04:47 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20110; Tue, 1 Nov 94 06:00:18 PST Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA12398; Tue, 1 Nov 94 06:00:10 PST Received: by rodan.UU.NET id QQxodk21138; Tue, 1 Nov 1994 09:00:02 -0500 Date: Tue, 1 Nov 1994 09:00:02 -0500 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM well, I gotta start by saying that I *really* dislike the notion of high-speed header splicing, but at the same time, I see NO way around it. There are a number of scenarios, but the simplest is doing provider selection at boundary routers. the average workstation MUST NOT be saddled with understanding all the policy decisions driving an enterprise-wide routing architecture - it just simply will not work. Therefore, there is NO WAY for a workstation to include the necessary routing headers to steer the packet correctly once it leaves some relatively-modest "local environ" (modest when compared with the complexity of the entire Internet). Therefore, somewhere along the way, while the packet is winding its way to the edge of the source enterprise, some router must ASSERT the entrerprise policy and ENFORCE particular routing decisions, and the only way in hand right now is to insert routing headers. This ability to enforce routing policy independently of whatever workstations are emitting is a REQUIREMENT. We can explain all the reasons why it's a bad idea and that we really don't want to have to do it, but that's tough noogies. Rather like firewalls for routing. Besides, the Yacov's assert that SDRP is the be-all and end-all of routing machinery, and that certainly requires high-speed header splicing. The other obvious scenario is doing encryption of traffic leaving some boundary. same issues follow and it's just as big a requirement. the workstation user may have no idea his traffic is being encrypted on the fly as it leaves the enterprise boundary, nor should he care. Response to identified problems: I don't think this really breaks MTU discovery - if the packets are always modified the same way when they travel the same path, then MTU discover should still work. most of your other concerns are valid at some level, but if we adopt the notion that the such modification should be use SPARINGLY and only as a last resort, then that's the best we can do. -mo ------------------------------------------------------------------------------ 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 Nov 1 06:59:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10458; Tue, 1 Nov 94 06:59:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10452; Tue, 1 Nov 94 06:58:58 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21783; Tue, 1 Nov 94 06:54:29 PST Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA18431; Tue, 1 Nov 94 06:54:22 PST Message-Id: <9411011454.AA18431@Sun.COM> Date: Tue, 1 Nov 94 9:43:42 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Subject: Re: (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, Maybe I missed something. Could you explain how, with encapsulation, the intermediate systems would perform authentication. Do the intermediate systems simply keep parsing headers, logically through each level of encapsulation, until they find "an appropriate" authentication header? (In the case of no authentication header this would imply that each intermediate system concerned with authentication would have to parse each packet up to the transport level in order to make sure that there was no authentication header.) It would seem that a box performing an encapsulation might have to include some authentication of its own, in addition to any provided by the origin of the packet, for intermediate systems that process the packet while it is encapsulated. Thus it seems that stopping at the first authentication header would not be appropriate, and again the box would have to parse to the transport level to make sure any and all authentication headers have been processed. Thanks, 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 Tue Nov 1 06:59:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10470; Tue, 1 Nov 94 06:59:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10464; Tue, 1 Nov 94 06:59:32 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21828; Tue, 1 Nov 94 06:55:03 PST Received: from nic.near.net by Sun.COM (sun-barr.Sun.COM) id AA18510; Tue, 1 Nov 94 06:55:04 PST Received: from jcurran-ppp.near.net by nic.near.net id aa17772; 1 Nov 94 9:54 EST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Nov 1994 09:54:50 -0500 To: ipng@sunroof.Eng.Sun.COM From: John Curran Subject: Re: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 9:00 AM 11/1/94, Mike O'Dell wrote: >well, I gotta start by saying that I *really* dislike the notion of >high-speed header splicing, but at the same time, I see NO way around it. >... > >most of your other concerns are valid at some level, but if we >adopt the notion that the such modification should be use >SPARINGLY and only as a last resort, then that's the best we can do. I'd like to echo these views... if it should prove absolutely necessary to splice headers in transit to achieve a certain functionality, then we simply do it. It's inconceivable that we'd introduce such header munging for a minor performance improvement. Remember, someone's got to figure out what went wrong when one of these maimed packets gets dropped and somewhere an application fails. The fewer minipulations performed in the network, the more deterministic the network appears from an operational viewpoint. /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 Tue Nov 1 07:05:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10490; Tue, 1 Nov 94 07:05:12 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10484; Tue, 1 Nov 94 07:05:05 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22079; Tue, 1 Nov 94 07:00:36 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19463; Tue, 1 Nov 94 07:00:36 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA11515; Tue, 1 Nov 94 06:56:01 -0800 Received: by xirtlu.zk3.dec.com; id AA23878; Tue, 1 Nov 1994 09:55:25 -0500 Message-Id: <9411011455.AA23878@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Tue, 01 Nov 94 06:11:46 CST." <9411011211.AA10702@anubis.network.com> Date: Tue, 01 Nov 94 09:55:19 -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 Previous Discussion Simpson vs Bound, then Conta. ------------------------------------------------- >>>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. >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. --------------------------------------------------- Text from RFC 1256 2. Protocol Overview : Page 3 2cnd Paragraph: ----------------------------------------------------------------- The ICMP router discovery messages are called "Router Advertisements" and "Router Solicitations". Each router periodically multicasts a Router Advertisement from each of its multicast interfaces, announcing the IP address(es) of that interface. Hosts discover the addresses of their neighboring routers simply by listening for advertisements. When a host attached to a multicast link starts up, it may multicast a Router Solicitation to ask for immediate advertisements, rather than waiting for the next periodic ones to arrive; if (and only if) no advertisements are forthcoming, the host may retransmit the solicitation a small number of times, but then must desist from sending any more solicitations. Any routers that subsequently start up, or that were not discovered because of packet loss or temporary link partitioning, are eventually discovered by reception of their periodic (unsolicited) advertisements. (Links that suffer high packet loss rates or frequent partitioning are accommodated by increasing the rate of advertisements, rather than increasing the number of solicitations that hosts are permitted to send.) ----------------------------------------------------------------- Text from RFC 1256 5.3 Host Behavior : Page 16 begin 2cnd paragraph ------------------------------------------------------------------ A host is permitted (but not required) to transmit up to MAX_SOLICITATIONS Router Solicitation messages from any of its multicast interfaces after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. - The PerformRouterDiscovery flag for the interface is changed from FALSE to TRUE by system management. The IP destination address of the solicitations is the configured SolicitationAddress for the interface. The IP source address may contain zero if the host has not yet determined an address for the interface; otherwise it contains one of the interface's addresses. If a host does choose to send a solicitation after one of the above events, it should delay that transmission for a random amount of time between 0 and MAX_SOLICITATION_DELAY. This serves to alleviate congestion when many hosts start up on a link at the same time, such as might happen after recovery from a power failure. (It is recommended that hosts include some unique value, such as one of their IP or link-layer addresses, in the seed used to initialize their pseudo-random number generators. Although the randomization range is specified in units of seconds, the actual randomly-chosen value should not be in units of whole seconds, but rather in units of the highest available timer resolution.) A host may also choose to further postpone its solicitations, subsequent to one of the above events, until the first time it needs to use a default router. Upon receiving a valid advertisement containing at least one neighboring address whose preference level is other than hex 80000000, subsequent to one of the above events, the host must desist from sending any solicitations on that interface (even if none have -------------------------------------------------------------------- I propose that we continue to permit the forward thinking of RFC 1256 that hosts sparingly be permitted to send router-solicitations as suggested in RFC 1256. /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 Nov 1 08:37:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10550; Tue, 1 Nov 94 08:37:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10544; Tue, 1 Nov 94 08:37:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27289; Tue, 1 Nov 94 08:32:57 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA01192; Tue, 1 Nov 94 08:32:52 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA17437; Tue, 1 Nov 94 08:03:21 -0800 Received: by xirtlu.zk3.dec.com; id AA26320; Tue, 1 Nov 1994 11:02:45 -0500 Message-Id: <9411011602.AA26320@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Performance Aggregate Gains in IPv6 (the Big Picture Test) Date: Tue, 01 Nov 94 11:02:38 -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 >Date: Tue, 1 Nov 1994 09:54:50 -0500 >To: ipng@sunroof.eng.sun.com >From: John Curran >Subject: Re: (IPng) high-speed slicing and dicing of headers..... I would like to use John's mail to begat a thread that I think is very important as we design and discuss the implementation details of IPv6 specifications. >I'd like to echo these views... if it should prove absolutely necessary >to splice headers in transit to achieve a certain functionality, then we >simply do it. It's inconceivable that we'd introduce such header munging >for a minor performance improvement. Per John's last sentence the preposition "for a minor performance improvement" (I am not disagreeing with John's mail subject or agreeing just using it as spring board to begat this thread.). We have to realize that security will be used more on the Internet and in private enterprises. We have in IPv6 an Authentication part that will have an order of magnitude performance loss to implementations when this authentication is "turned on". We have also introduced 16bytes into host implementations which will require some adjustments on some implementations to access of buffers. In general IPv6 can (not always or will) introduce performance loss in some cases compared to IPv4. When we work on disocovery, transition, APIs, routing, et al for IPv6 often implementors propose changes that will afford increases in performance either by direct throughput of packets or a reduction in processing time on the node. During this discourse sometimes we ask is the pain worth the gain of the implementor or architect proposing the change? I think this is a valid question, but what we also need to ask ourselves is what are the sum total of gains for all of these proposed changes when the fulcrum of the implementors proposed change is in fact some performance gain, which can be proven over another implementors solution. What I would call this is the "Performance Aggregate Gains in IPv6" test, before we discount any performance improvements from any implementor as a trivial "performance gain". This test will assist us to not only do correct engineering of the IPv6 specifications, but also proper systems engineering of the entire set of specifications. Or in lay terms: "Looking at the Big Picture Too"; hence, this could also be called the Big Picture Test (BPT). Before blowing away a potential pearl from those of us actually implementing IPv6 or those who are so in tune as architects about implementations, I suggest in the course of our work on IPv6 we apply the BPT when reviewing a proposed idea or change from within our working group. /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 Nov 1 09:05:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10567; Tue, 1 Nov 94 09:05:50 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10561; Tue, 1 Nov 94 09:05:39 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA20865; Tue, 1 Nov 1994 09:01:13 -0800 Date: Tue, 1 Nov 1994 09:01:13 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411011701.JAA20865@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199411011327.IAA08224@newdev.harvard.edu> 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 Scott Bradner writes: > I would still rather see this as an informational RFC. An > IPv6 implementation could use almost any method to store this information > up to and inclusing a relational dtabase and I see little reason > to put platform specific information into a base protocol specification. I agree. There is considerable value in defining file formats, but I do not think we should standardize them. An informational RFC would be fine. Suggest that someone (Alex?) take a cut at the file format. 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 Nov 1 09:15:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10579; Tue, 1 Nov 94 09:15:13 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10573; Tue, 1 Nov 94 09:15:06 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00398; Tue, 1 Nov 94 09:10:37 PST Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA07721; Tue, 1 Nov 94 09:09:57 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA20280 for ipng@sunroof.eng.sun.com; Tue, 1 Nov 94 12:08:28 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA05534; Tue, 1 Nov 1994 09:06:55 -0800 Message-Id: <199411011706.JAA05534@aland.bbn.com> To: tli@cisco.com Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) adding extension headers to a packet in flight In-Reply-To: Your message of Mon, 31 Oct 94 23:15:45 -0800. <199411010715.XAA05612@lager.cisco.com> From: Craig Partridge Date: Tue, 01 Nov 94 09:06:54 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM 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 Tony: On the contrary, I found Steve's notes one of the more useful notes I've read on the list -- there's a very real architectural issue of how much header munging goes on and that type of architectural issue belongs on IPNG. (For instance, it is the overall IPNG effort, not the SDRP group, which will decide, in the end, what kinds of header munging are OK). Craig ------------------------------------------------------------------------------ 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 Nov 1 09:19:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10608; Tue, 1 Nov 94 09:19:00 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10602; Tue, 1 Nov 94 09:18:49 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA21411; Tue, 1 Nov 1994 09:14:21 -0800 Date: Tue, 1 Nov 1994 09:14:21 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411011714.JAA21411@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199411010715.XAA05612@lager.cisco.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 Tony, > Your note, while interesting, is wholly out of order for this mailing > list. I must admit I got a chuckle reading the above. The notion that something is out of order on an IETF mailing list is a concept I had not heard before. Must be a good AI project out there which could do this kind of checking automatically :-) Seriously, the topic was the use of IPng extension headers. This is part of the basic architecture of IPng and should be discussed on the IPng list. 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 Nov 1 09:32:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10631; Tue, 1 Nov 94 09:32:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10625; Tue, 1 Nov 94 09:32:06 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01914; Tue, 1 Nov 94 09:27:37 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA09602; Tue, 1 Nov 94 09:25:26 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-25.dialip.mich.net [141.211.7.36]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA18887 for ; Tue, 1 Nov 1994 12:12:51 -0500 Date: Tue, 1 Nov 94 16:08:20 GMT From: "William Allen Simpson" Message-Id: <3381.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) multiple addresses per interface Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Reply-To: ipng@sunroof.eng.sun.com Halleluia! They fixed the % hack problem! > From: iialan@iifeak.swan.ac.uk (Alan Cox) > > Dunno if it works on all chips. What chip did you have in mind? > > Most of them I suspect. Some (eg 8390) have hashing filters that may or may > not scale well depending upon choice of address -> MAC address mapping. A lot > of very old PC type ethernet cards have inane limits (eg Multicast YES/NO) > but the modern ones seem pretty reasonable. Given that the 8390 chip (in > the form of the 3c503, NE2000 + clones and WD80x3) is probably the most > common client PC card it might be worth some mathematical person looking into > the hash algorithm and seeing how best to map the choice of multicast > addresses. > Yes. I asked Matt Crawford in a private message if he'd run it through his n,000 node database, but haven't heard anything. Exclusive-or was what was suggested by Christian when he proposed it. Until a better algorithm is proposed, I'll just stick with that. 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 Nov 1 09:37:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10644; Tue, 1 Nov 94 09:37:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10637; Tue, 1 Nov 94 09:37:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02320; Tue, 1 Nov 94 09:32:45 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB09602; Tue, 1 Nov 94 09:27:40 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-25.dialip.mich.net [141.211.7.36]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA18891 for ; Tue, 1 Nov 1994 12:12:54 -0500 Date: Tue, 1 Nov 94 16:14:02 GMT From: "William Allen Simpson" Message-Id: <3382.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM 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: fredr@anubis.network.com (Fred Rabouw (Gouda office)) > >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. > > > in the document: the whole addresses > "all-nodes" and "all-routers" are not defined, they appear in the document: hinden-ipng-addr-00.txt> as a NETWORK LAYER ADDRESS (that is: an IPv6 address. > The solicited-nodes multicast appears in > as a LINK LAYER (multicast) ADDRESS. > Thank you for the careful and accurate reading. > When the NETWORK LAYER ADDRESS is a unicast address, but the LINK LAYER ADDRESS is > unknwon we use the SOLICITED-NODES in the LINK LAYER ADDRESS. > When the NETWORK LAYER ADDRESS is a unicast address, and the LINK LAYER ADDRESS is > knwon we use the correct and known LINK LAYER ADDRESS. Yes. > When the NETWORK LAYER ADDRESS is ALL_NODES or ALL_ROUTERS, I can't find a > specification what LINK LAYER ADDRESS to use, but it can be either: > - a link layer broadcast (would be bad protocol design) > - the base solicited-nodes multicast > - the base solicited-nodes multicast with the ALL NODES or ALL ROUTER > address added to it. The IP to IEEE mapping of these addresses is specified by Postel in RFC-1700. He probably won't put in the IPv6 formula until IPv6 is done. Bob should have an Appendix in the address draft. That would help. > I agree that this should be specified in the draft documents, Bill I > think you should indeed add a LINK LAYER header specification at > some places. > Yes, I will do that. > > 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. > > Again: The solicited nodes multicast is a link layer address, such as an Ethernet > multicast address. There is no reason to reserve that at the IPv6 level, those > address can never mix, since they appear at different layers in the packet header. > There is no reason to reserve an IPv6 address as solicited-node multicast. > I have reserved IP multicast numbers, because we are using the IP reserved IEEE block. IEEE charges serious money for these blocks. We can't let some other IP application use the numbers, so we reserve them. > >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. > > When the host and router are working well, the timing-out should never happen, when > one of them times-out to fast (incorrectly), they might loose eachother. > Actually, Conta hadn't noticed that the lifetime is not the same rate as the advertisements. By default, the LifeTime is three (3) times as long as the maximum advertisement interval. (Processing p 10) So, the host would have missed 3 adverts, and also timed out too soon! A host that is missing 3 packets is either a very bad implementation or on a very bad link. The rest of your analysis is very good. Thanks. > >> 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. > (To Conta) There is no "hole". You always examine the router list first. This is already extensively described in "Next Hop Decision", paragraphs (c) and (d). Since you match the router, and already have a media address entry for the router (obtained from the router advert), there is never any reason to solicit the router for host functions. Also, Processing page 4 reads: Although the Hop Cache, the lists of default routers, and a table of static routes are described as conceptually distinct, in practice they may be combined into a single "routing table" data structure. So, in practice, you can even keep the routers and specific destinations in the same list. I don't know how to make it simpler. (And this note is directly from RFC-1122 p 51, so it should have been in your implementation already!) It seems that mostly you object to the NAME! Could it be that you have had this misunderstanding all along? Changing the name is pretty easy, and I would be happy to do that if it engenders understanding. > As last remark, it is a point that most draft documents on IPv6 are not yet fully > clear in what should be done in every thinkable situation. We usually don't try to describe _every_ situation in the protocol documents. That could get HUGE. In the past, we have just described the protocols, and then tested them. People have written separate papers about the testing, and their implementations. > But please Bill let's not be > to rude in discussing this. > Fred, you haven't begun to see rudeness on my part. I have said "PLEASE", I have begged, I have pleaded. I'm tired of it. I wish that everyone would be as careful in reading the drafts as you have been (even when we disagree). 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 Nov 1 10:59:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10704; Tue, 1 Nov 94 10:59:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10698; Tue, 1 Nov 94 10:59:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09048; Tue, 1 Nov 94 10:55:08 PST Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA16914; Tue, 1 Nov 94 10:55:06 PST Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id MAA17365; Tue, 1 Nov 1994 12:45:38 -0500 Message-Id: <199411011745.MAA17365@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing and dicing of headers..... In-Reply-To: Your message of "Tue, 01 Nov 1994 09:00:02 EST." From: Valdis.Kletnieks@vt.edu Date: Tue, 01 Nov 1994 12:45:37 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Tue, 01 Nov 1994 09:00:02 EST, Mike O'Dell said: > Therefore, somewhere along the way, while the packet is winding its way > to the edge of the source enterprise, some router must ASSERT the entrerprise > policy and ENFORCE particular routing decisions, and the only way in > hand right now is to insert routing headers. OK.. question 1: What other ways, not in hand, are there to enforce policy decisions for things like this? How many mechanisms are there (or should there be) for handling this *other* than inserting routing headers? Is "gratuitously smash the packet" acceptable (it might be, if it was a military site, and we were about to send a classified packet over an unsecure link). Is "ignore the objectionable header" an option? Is inappropriate choice of route the only problem, or do we also have TOS and/or resource reservation headaches to deal with (wait till the CEO's teleconference gets choppy and noisy because somebody in the mail room is running a porn movie over the net during his lunch break ;) I think if we are going to worry about packets that violate a policy, we need a *general* scheme for policy enforcement that covers more than just routing/provider selection... Question 2: if the problem is "random workstation X using an inappropriate provider selection/route/whatever", would a better solution be "make sure workstation X never learns the correct magic cookie needed to use the service it shouldn't be using"? (Yes, this gets back to the "dumb host, smart router" model)... 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 Tue Nov 1 11:18:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10731; Tue, 1 Nov 94 11:18:48 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10725; Tue, 1 Nov 94 11:18:41 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23074; Tue, 1 Nov 94 11:14:22 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA20146; Tue, 1 Nov 94 11:13:46 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 2 Nov 94 03:08:36 +0900 From: Masataka Ohta Message-Id: <9411011808.AA16241@necom830.cc.titech.ac.jp> Subject: Re: (IPng) multiple addresses per interface To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 94 3:08:35 JST In-Reply-To: <3381.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Nov 1, 94 4:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > From: iialan@iifeak.swan.ac.uk (Alan Cox) > > > Dunno if it works on all chips. What chip did you have in mind? > > > > Most of them I suspect. Some (eg 8390) have hashing filters that may or may > > not scale well depending upon choice of address -> MAC address mapping. A lot > > of very old PC type ethernet cards have inane limits (eg Multicast YES/NO) > > but the modern ones seem pretty reasonable. It seems to me that it works. > > Given that the 8390 chip (in > > the form of the 3c503, NE2000 + clones and WD80x3) is probably the most > > common client PC card it might be worth some mathematical person looking into > > the hash algorithm and seeing how best to map the choice of multicast > > addresses. > > > Yes. I asked Matt Crawford in a private message if he'd run it through > his n,000 node database, but haven't heard anything. > > Exclusive-or was what was suggested by Christian when he proposed it. > Until a better algorithm is proposed, I'll just stick with that. If a subnet is smaller than 256, bytewise exclusive-or gives perfect hash. So, it is very good, as subnets should be small. The problem is rather in the selection of MAC multicast addresses. If there are any (defacto) standard on the hardware hash algorithm (are there?), MAC multicast addresses should be choosed so that the hardware hash results do not duplicate with each other or with the MAC broadcast address. 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 Nov 1 11:58:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10780; Tue, 1 Nov 94 11:58:09 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10774; Tue, 1 Nov 94 11:58:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27136; Tue, 1 Nov 94 11:53:43 PST Received: from venera.isi.edu by Sun.COM (sun-barr.Sun.COM) id AA26880; Tue, 1 Nov 94 11:53:22 PST Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Tue, 1 Nov 1994 07:10:32 -0800 From: bmanning@ISI.EDU Posted-Date: Tue, 1 Nov 1994 07:09:32 -0800 (PST) Message-Id: <199411011509.AA11885@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 1 Nov 1994 07:09:32 -0800 Subject: Re: (IPng) high-speed slicing and dicing of headers..... To: ipng@sunroof.Eng.Sun.COM Date: Tue, 1 Nov 1994 07:09:32 -0800 (PST) In-Reply-To: from "Mike O'Dell" at Nov 1, 94 09:00:02 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: 353 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Besides, the Yacov's assert that SDRP is the be-all and end-all of > routing machinery, and that certainly requires high-speed header > splicing. > Have you seen his replacement for SDRP work? If not, I'll dredge up a copy of the ERP spec and punt it over... IDRP is warmed over BGP4 SDRP is warmed over IDRP ERP is warmed over SDRP.... --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 Tue Nov 1 12:43:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10855; Tue, 1 Nov 94 12:43:01 PST From: owner-ipng Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10614; Tue, 1 Nov 94 09:28:32 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01552; Tue, 1 Nov 94 09:24:03 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA09383; Tue, 1 Nov 94 09:23:52 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14492(8)>; Tue, 1 Nov 1994 09:23:18 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12172>; Tue, 1 Nov 1994 09:23:04 -0800 To: Tony Li Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) adding extension headers to a packet in flight In-Reply-To: tli's message of Mon, 31 Oct 94 23:15:45 -0800. <199411010715.XAA05612@lager.cisco.com> Date: Tue, 1 Nov 1994 09:22:57 PST >From: Steve Deering Message-Id: <94Nov1.092304pst.12172@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 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 Tony, No, your statement above is wholly out of order. My note was an attempt to write down the rationale/motivation for a statement that I have ended up repeating at almost every SIPP or IPv6 related meeting and that is written in the current IPv6 spec. I was finally prodded into writing it by the recent discussions of header insertion as part of the address resolution mechanism proposed by Alex Conta. Dave Clark has also leaned on me in the past to make my assumption/requirement of no header-insertion en route more explicit and to explain my reasons. I claim (in fact, as co-chair, I *rule* :-)) that my note is appropriate for the ipng list. You seem to have read my message as a long pre-amble to a critique of ERP, when in fact I intended the final paragraph (the part about ERP) to be interpreted merely as a postscript, pointing out that there was work going on on ERP which, when finished, might cause me to change my mind. I apologize for the sloppy writing that led you to a false conclusion. BTW, I will be posting comments on the ERP draft (later today, I hope), and of course those will be sent to the sdrp list. 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 Tue Nov 1 13:46:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10995; Tue, 1 Nov 94 13:46:00 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10989; Tue, 1 Nov 94 13:45:53 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18313; Tue, 1 Nov 94 13:41:34 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA16395; Tue, 1 Nov 94 13:40:55 PST Received: from alpha.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA26811; Tue, 1 Nov 1994 16:20:52 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA15545; Tue, 1 Nov 1994 16:20:45 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA18811; Tue, 1 Nov 1994 15:57:16 -0500 Message-Id: <9411012057.AA18811@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Tue, 01 Nov 94 06:11:46 CST." <9411011211.AA10702@anubis.network.com> Date: Tue, 01 Nov 94 15:57:16 -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: fredr@anubis.network.com (Fred Rabouw (Gouda office)) You mentioned Bill and Jim, but in fact teh mail message was from me. So.. >>>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. >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. When the host and router are working well, the timing-out should never happen when one of them times-out to fast (incorrectly), they might loose each other. Perhaps I was not clear enough that I was not talking about a host that has a timer so bad that it should be reported as a hardware failure. I am talking about hosts that are operating in the vicinity of normality. Two different hosts timers are in general skewed. There is a certain value generally accepted as interval timer precision, but the deviation, and the loss of timer interrupts makes it almost a rule that two hosts will timeout differently for the same delta time. The question is how different are the timeouts in the boundary of normal or quite normal behavior. Do the specs provide for such cases? When we allow a host to send router solicitations, no one will ever care about the incorrect timing (all sessions stay alive, so why bother). That might be as bad as in the most terrible case, that the host times out the router after one microsecond in sending 100% LAN load of router solicitations. I agree a very unlike and extremely fast timeing out, but possible. I would remind you that according to the specs, a host sends a router solicitation not more than 3 times at 3 seconds intervals, if my interpretation is correct. So if an implementation follows the specs in this regard, the case you mention is rather an impossible one. Furthermore the lifetime granularity is 1 second, which makes your case once more impossible, in what I was considering. In Bill's proposal of: "Sorry host, you work incorrect, you're lost" the network is saved from this host, the host looses connections, the people working on it start complaining and the pain is were it should be: at the wrong behaving unit. We disagree here. The genereal principle of robustness in IP is design for the worst case. The specifications already provide for that in regulating the number of solicitations, and the time between two consecutive solicitations. The part I am bringing under scrutiny, given timers skewing, in the vicinity of normality, is whether it makes sense to allow hosts solicitations, and how much would that cost. In my opinion the cost, given the protection alraedy in place is minimal. When the host is allowed to send out router solicitations it might fill a substantial part of the LAN or router, putting the pain in the rest of the network. As a conclusion I think: yes let a bad working host loose its connections and protect the rest of the network from that is robust protocol design. As I said, we disagree, in the circumstances described so far. If a host behaves in the vicinity of normality, and works fine with other communications protocols, including IPv4, but times-out with IPv6, people will say that IPv6 is fragile, i.e. our design is not as good as it could have been. With that prosecptive, I would rather have all other protocols timeout, while IPv6 connections stay up. Then people will say IPv6 is robusti, i.e. we did a good desing. In order to achieve that, we have to provide for the worst case, while protecting the network and routers from meltdowns, which we already do. >> 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. A router is for networking management an ordinary host, for telnet, ping and snmp it will have to act as a normal host. I can's see how we can manage the routers on a LAN if they are not reacting as normal hosts on things as "solicited-node" multicasts as the LINK LAYER address. So you emphasize on the situation I had in mind. The main benefit of this "solicited-node" multicast is not to protect the routers (if they are bridging also, they will take a short look at all frames anyway), but to protect the hosts against 255/256-st of the multicasts. Routers joining the solicited-node group, is in 180% opposition to what Bill said in his previous mail message to which I responded, i.e. "only hosts join the solicited-node group". As last remark, it is a point that most draft documents on IPv6 are not yet fully clear in what should be done in every thinkable situation. The drafts on neighbor discovery need some more information on which link layer addresses to use and some cross references on when to send what kind of frame. But please Bill let's not be to rude in discussing this. What you just said, has been said for quite sometime. 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 Nov 1 14:01:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11024; Tue, 1 Nov 94 14:01:05 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11018; Tue, 1 Nov 94 14:00:58 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21348; Tue, 1 Nov 94 13:56:38 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA03900; Mon, 31 Oct 94 14:22:37 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14749(8)>; Mon, 31 Oct 1994 14:11:54 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12172>; Mon, 31 Oct 1994 14:11:08 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) RFC1710 and address size? In-Reply-To: tpoernomo's message of Sat, 29 Oct 94 10:51:19 -0800. <9410291748.AA02074@csupomona.edu> Date: Mon, 31 Oct 1994 14:10:58 PST From: Steve Deering Message-Id: <94Oct31.141108pst.12172@skylark.parc.xerox.com> 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 :) Ted, Yes, it is confusing -- we in the IETF do not do a very good job in presenting a coherent story to "the market". I like to think that's because we are engineers and not marketeers. (Lame excuse, I know.) Anyway, yes, SIPP and IPv6 are different. IPv6 is primarily based on SIPP, but one of the most important ways in which it differs is that IPv6 has 128-bit addresses, whereas SIPP has 64-bit addresses. Just to add to the confusion, there is/was an Internet Draft entitled "Simple Internet Protocol Plus (SIPP) Specification (128-bit address version)" dated July 17, 1994, which was SIPP modified as requested by the IPng Area Directors to serve as the base IPv6 spec. In retrospect, it should simply have been entitled "IP Version 6", rather than muddying what "SIPP" had come to mean. 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 Tue Nov 1 15:33:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11251; Tue, 1 Nov 94 15:33:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11245; Tue, 1 Nov 94 15:33:28 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09023; Tue, 1 Nov 94 15:29:09 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05522; Tue, 1 Nov 94 15:28:35 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-20.dialip.mich.net [35.1.48.101]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA22631 for ; Tue, 1 Nov 1994 18:28:21 -0500 Date: Tue, 1 Nov 94 23:04:44 GMT From: "William Allen Simpson" Message-Id: <3386.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) 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 > if (and only if) no advertisements are forthcoming, the host > may retransmit the solicitation a small number of times, but then > must desist from sending any more solicitations. See Processing p 8: If (and only if) no advertisements from neighboring routers are forthcoming, the node MAY retransmit the Router Solicitation a small number of times, but then MUST desist from sending more solicitations. > A host is permitted (but not required) to transmit up to > MAX_SOLICITATIONS Router Solicitation messages from any of its > multicast interfaces after any of the following events: > > - The interface is initialized at system startup time. > > - The interface is reinitialized after a temporary interface > failure or after being temporarily disabled by system > management. > > - The system changes from being a router to being a host, by > having its IP forwarding capability turned off by system > management. > > - The PerformRouterDiscovery flag for the interface is > changed from FALSE to TRUE by system management. > See Processing p 8: A IPv6 node is required to transmit up to MAX_SOLICITATIONS messages from any of its interfaces after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - A router has its forwarding capability turned off by system management. > I propose that we continue to permit the forward thinking of RFC 1256 > that hosts sparingly be permitted to send router-solicitations as > suggested in RFC 1256. > I thank you for your support. Note that the host MUST NOT send solicitations under _any_ other circumstances, such as the router advert timeout, as you had earlier requested. 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 Nov 1 16:29:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11403; Tue, 1 Nov 94 16:29:38 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11396; Tue, 1 Nov 94 16:29:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19699; Tue, 1 Nov 94 16:24:58 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB17781; Tue, 1 Nov 94 16:24:48 PST Subject: Re: (IPng) IPv6 Local file Network Address/Name Support To: IPng Mailing list Date: Tue, 1 Nov 1994 13:25:05 -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: 1498 Message-Id: <9411011825.aa13247@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM With all of this talk about having at one's disposal a local name<->address table, I should show everyone what we have done so far here at NRL. =====================(Cut up to and including here.)====================== beech(~)[0]% cat /etc/hosts # # Host Database # This file should contain the addresses and aliases # for local hosts that share this file. # It is used only for "ifconfig" and other operations # before the nameserver is started. # # 127.0.0.1 loopback 132.250.198.1 lazer9.nrl.navy.mil lazer9 132.250.90.16 beech.itd.nrl.navy.mil beech localhost 132.250.90.15 molly.itd.nrl.navy.mil molly # Additonal sipp addresses. This is experimental. # Old SIPP #0:0:0:1 loopback #6000:0020:af0c:5f58 beech localhost #6000:000:000:0 sipp-local-use #6000:0020:af09:ee46 molly # New IPv6 fe00::0 local-use fe00::1 loopback fe00::20:af0c:5f58 beech fe00::20:af09:ee46 molly 132.250.90.0 b26-sipp 127.0.0.0 localnet =====================(Cut up to and including here.)====================== Craig Metz did this as a quick-n-dirty way to make stubs of the DNS calls (as defined in the BSD API document) available to apps. It works, because the two addressing schemes with their different separators ('.' vs. ':') is trivial to parse. (The grammar is not ambiguous, for you theory weenies.) It seems to work just fine for us! Dan McD. ------------------------------------------------------------------------------ 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 Nov 1 22:40:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11653; Tue, 1 Nov 94 22:40:07 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11647; Tue, 1 Nov 94 22:40:00 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25119; Tue, 1 Nov 94 22:35:42 PST Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA17224; Tue, 1 Nov 94 22:35:32 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA15100; Tue, 1 Nov 94 22:32:56 -0800 Received: by xirtlu.zk3.dec.com; id AA19987; Wed, 2 Nov 1994 01:32:48 -0500 Message-Id: <9411020632.AA19987@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Tue, 01 Nov 94 23:04:44 GMT." <3386.bill.simpson@um.cc.umich.edu> Date: Wed, 02 Nov 94 01:32:42 -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 >From: "William Allen Simpson" >> From RFC 1256 >> >> A host is permitted (but not required) to transmit up to >> MAX_SOLICITATIONS Router Solicitation messages from any of its >> multicast interfaces after any of the following events: >> >> - The interface is initialized at system startup time. >> >> - The interface is reinitialized after a temporary interface >> failure or after being temporarily disabled by system >> management. >> >> - The system changes from being a router to being a host, by >> having its IP forwarding capability turned off by system >> management. Why is the above sentence not in the IPv6 system discovery spec? >> >> - The PerformRouterDiscovery flag for the interface is >> changed from FALSE to TRUE by system management. Why is the above sentence not in the IPv6 system discovery spec? >See Processing p 8: > A IPv6 node is required to transmit up to MAX_SOLICITATIONS messages > from any of its interfaces after any of the following events: Why in IPv6 system discovery does the above sentence state required, but in RFC 1256 above it states "A host is permitted (but not required)..".? > - The interface is initialized at system startup time. > - The interface is reinitialized after a temporary interface failure > or after being temporarily disabled by system management. > - A router has its forwarding capability turned off by system > management. A node can be both a host and a router in one computer. Does the above sentence apply to the router implementation on that computer only? >> I propose that we continue to permit the forward thinking of RFC 1256 >> that hosts sparingly be permitted to send router-solicitations as >> suggested in RFC 1256. >I thank you for your support. >Note that the host MUST NOT send solicitations under _any_ other >circumstances, such as the router advert timeout, as you had earlier >requested. I cannot find the above sentence in the version I am using to review the processing spec? I will send at a later time to the working group why stating that the host MUST NOT send router-solicitations under _any_ other circumstances, such as router advert timeout, in the system discovery specifications, does not sit well with me from an IPv6 architecture perspective. Possibly this may be accompanied by a proposed change to the system discovery specification, to make it more flexible and optional for the host implementation. These are the system discovery specs I have at this time. Are these the most up to date? draft-simpson-ipv6-discov-formats-00.txt draft-simpson-ipv6-discov-process-00.txt draft-simpson-ipv6-discovery-req-00.txt /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 Nov 1 23:12:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11681; Tue, 1 Nov 94 23:12:47 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11675; Tue, 1 Nov 94 23:12:40 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26259; Tue, 1 Nov 94 23:08:21 PST Received: from databus.databus.com by Sun.COM (sun-barr.Sun.COM) id AA21769; Tue, 1 Nov 94 23:07:57 PST Date: Wed, 2 Nov 94 02:07 EST Message-Id: <9411020208.AA02976@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Interpretation for IPv6 System Discovery Content-Length: 1089 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Wed, 02 Nov 94 01:32:42 -0500 > From: bound@zk3.dec.com > > I will send at a later time to the working group why stating that the host > MUST NOT send router-solicitations under _any_ other circumstances, such as > router advert timeout, in the system discovery specifications, does not sit > well with me from an IPv6 architecture perspective. Possibly this may > be accompanied by a proposed change to the system discovery > specification, to make it more flexible and optional for the host > implementation. Surely designs that use advertising must set the timeout to several times the advertising interval, so if you've timed out a stale advertisement, the router is certainly dead? It's not just a matter of somebody's clock frequency being off a few percent. This implies that you can't detect a dead router until you've missed 3-6 advertisements, so Wall Streeters and other impatient folk will need to keep the advertising interval short. But that sort of network can afford, say, a packet per second per router on an Ethernet. 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 Tue Nov 1 23:44:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11793; Tue, 1 Nov 94 23:44:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11787; Tue, 1 Nov 94 23:44:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27742; Tue, 1 Nov 94 23:40:19 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26691; Tue, 1 Nov 94 23:40:09 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA07781; Tue, 1 Nov 94 23:39:45 -0800 Received: by xirtlu.zk3.dec.com; id AA20613; Wed, 2 Nov 1994 02:39:08 -0500 Message-Id: <9411020739.AA20613@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) Performance Aggregate Gains in IPv6 (Big Picture Test) Date: Wed, 02 Nov 94 02:39:02 -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 >Date: Tue, 1 Nov 1994 09:54:50 -0500 >To: ipng@sunroof.eng.sun.com >From: John Curran >Subject: Re: (IPng) high-speed slicing and dicing of headers..... I would like to use John's mail to begat a thread that I think is very important as we design and discuss the implementation details of IPv6 specifications. >I'd like to echo these views... if it should prove absolutely necessary >to splice headers in transit to achieve a certain functionality, then we >simply do it. It's inconceivable that we'd introduce such header munging >for a minor performance improvement. Per John's last sentence the preposition "for a minor performance improvement" (I am not disagreeing with John's mail subject or agreeing just using it as spring board to begat this thread.). We have to realize that security will be used more on the Internet and in private enterprises. We have in IPv6 an Authentication part that will have an order of magnitude performance loss to implementations when this authentication is "turned on". We have also introduced 16bytes into host implementations which will require some adjustments on some implementations to access buffers. In general IPv6 can (not always or will) introduce performance loss in some cases compared to IPv4. When we work on disocovery, transition, APIs, routing, et al for IPv6 often implementors propose changes that will afford increases in performance either by direct throughput of packets or a reduction in processing time on the node. During this discourse sometimes we ask is the pain worth the gain of the implementor or architect proposing the change? I think this is a valid question, but what we also need to ask ourselves is what are the sum total of gains for all of these proposed changes when the fulcrum of the implementors proposed change is in fact some performance gain, which can be proven over another implementors solution. What I would call this is the "Performance Aggregate Gains in IPv6" test, before we discount any performance improvements from any implementor as a trivial "performance gain". This test will assist us to not only do correct engineering of the IPv6 specifications, but also proper systems engineering of the entire set of specifications. Or in lay terms: "Looking at the Big Picture Too"; hence, this could also be called the Big Picture Test (BPT). Before blowing away a potential pearl from those of us actually implementing IPv6 or those who are so in tune as architects about implementations, I suggest in the course of our work on IPv6 we apply the BPT when reviewing a proposed idea or change from within our working group. /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 Nov 2 01:57:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12056; Wed, 2 Nov 94 01:57:21 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12050; Wed, 2 Nov 94 01:57:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03344; Wed, 2 Nov 94 01:52:56 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA11067; Wed, 2 Nov 94 01:52:45 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21620; Wed, 2 Nov 94 03:55:13 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA25076; Wed, 2 Nov 94 03:52:25 CST Date: Wed, 2 Nov 94 03:52:25 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411020952.AA25076@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM 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 To (alphabetical order): Alex Conta Bill Simpson Jim Bound Other people that might be interested From: Fred Rabouw Subject; Trying to clean up this thread. Gentlemen, On this thread, which is named: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery we are at the moment arguing on several subjects on which some of them we might agree without knowing it and on which some of them we talk about different things without realizing it. As far as I can see, we discussed in the last few days at least the following seven subjects: (1) Which multicast/broadcast addresses do exist? (The issue about Solicited-Node vs All-hosts) (2) Is the solicited-node group worth the effort? (Might not be granular enough) (2a) The effect of multiple IPv6 addresses on older interface cards (although there is a separate thread for that) (3) Are routers included in the solicited-node multicast? (4) Media Address Resolution and routers? (Yes/no when from/to router) (5) RFC 1256 allows for more things than the document draft-simpson-ipv6-discov-process. (5a) permits vs requires router-solicitation when host boots (5b) host might do router-solicitation when router entry times out (5c) what to do when host entry times out (5d) what to do when router changes to host (5e) system management sets PerformRouterDisc (6) The mapping of specific layer 3 multicasts on IEEE addresses. At the moment I have the feeling we never reach a conclusion when we keep all that in a single thread with people disagreeing on one item and in the meanwhile forgetting to decide they agree on other items. If you all agree I will start threads on each of these subjects individually hoping that at least some of them can be solved. Bill, Jim and Alex, I will send a copy of each first message to the ipng- mailing list, but also to you individually to make sure you won't miss it. Don't be afraid, all later messages will go to ipng only. Fred ------------------------------------------------------------------------------ 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 Nov 2 04:04:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12176; Wed, 2 Nov 94 04:04:16 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12170; Wed, 2 Nov 94 04:04:09 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08199; Wed, 2 Nov 94 03:59:50 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA22940; Wed, 2 Nov 94 03:59:35 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21958; Wed, 2 Nov 94 06:02:01 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA25643; Wed, 2 Nov 94 05:59:01 CST Date: Wed, 2 Nov 94 05:59:01 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411021159.AA25643@anubis.network.com> To: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: which multicasts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To (alphabetical order): Alex Conta Bill Simpson Jim Bound Other people that might be interested From: Fred Rabouw Subject; (IPng) IPv6 System Discovery: which multicasts Of my announced list of six (not seven) subjects: Number 1: Which multicast/broadcast addresses do exist? Short summary: The discussion was which types of multicasts do exist for discovery: either All-Host-Multicasts All-Router-Multicasts All-Node-Multicasts (note: all three are defined in hinden-ipng- addr) or all-nodes all-routers solicited-nodes My last contribution was: All-nodes and all-routers are layer 3 addresses, solicited-nodes is a layer 2 multicast When reading the draft-simpson-ipv6-discov-process I think I understand when what is used in the discovery process: When the NETWORK LAYER ADDRESS is a unicast address, but the LINK LAYER ADDRESS is unknwon we use the SOLICITED-NODES in the LINK LAYER ADDRESS. When the NETWORK LAYER ADDRESS is a unicast address, and the LINK LAYER ADDRESS is known we use the correct and known LINK LAYER ADDRESS. When the NETWORK LAYER ADDRESS is ALL_NODES or ALL_ROUTERS, I can't find a specification what LINK LAYER ADDRESS to use One point to specify: which link layer address to use for IPv6-multicasts? (to Bill: I agree the value of the address should be in RFC1700 or succesor, but a specification, such as "base-solicited-address" or whatever can be in your draft). The first question is: Do we all agree this is as it is specified? The second question is: Is this all we need for the neighbor discovery? (apart from IEEE address for last point) I say "yes" to both questions. Fred ------------------------------------------------------------------------------ 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 Nov 2 04:05:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12210; Wed, 2 Nov 94 04:05:22 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12204; Wed, 2 Nov 94 04:05:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08275; Wed, 2 Nov 94 04:00:56 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA23000; Wed, 2 Nov 94 04:00:15 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21961; Wed, 2 Nov 94 06:02:41 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA25646; Wed, 2 Nov 94 05:59:42 CST Date: Wed, 2 Nov 94 05:59:42 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411021159.AA25646@anubis.network.com> To: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: solicited-node Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To (alphabetical order): Alex Conta Bill Simpson Jim Bound Other people that might be interested From: Fred Rabouw Subject; (IPng) IPv6 System Discovery: solicited-node group? Of my announced list of six (not seven) subjects: Number 2: Is the solicited-node group worth the effort? Short summary: One opinion: we use a layer 2 address that is a so called: base-solicited-node multicast hashed with IPv6 destination address. The other opinion: this might not give any useful granularity and is not worth the effort. My comment: One a LAN with less than (let's say) 50 IPv6 nodes I really don't care about being selective with the IPv6 multicasts. Since IPv6 shouldn't multicast to much anyway, the number of multicasts per second will be that low that even a 386-PC can handle them. With more than 50 nodes I agree any hashing algorithm can turn out to be ineffective and map all addresses on the same multicast, but how likely is that? The proposed algorithm will work in 99.99% of the networks by saving my end-station for at least half the multicasts and most likely for much more. Note: There is a separate thread on many IPv6 addresses per interface and the effect of that on the interface card having to handle multiple multicasts. (1) There is hardly any reason for a host that is not a router AND not a server to have multiple IPv6 addresses, so the average endstation can do with one IPv6 address and by that with listening to only a few multicasts. (2) Routers or servers might want to have many IPv6 addresses, but they will should have up-to-date interfaces that can handle the multicast load I do not yet see the issue. Fred ------------------------------------------------------------------------------ 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 Nov 2 04:06:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12222; Wed, 2 Nov 94 04:06:18 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12216; Wed, 2 Nov 94 04:06:09 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08332; Wed, 2 Nov 94 04:01:51 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA23081; Wed, 2 Nov 94 04:01:38 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21970; Wed, 2 Nov 94 06:04:05 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA25667; Wed, 2 Nov 94 06:01:05 CST Date: Wed, 2 Nov 94 06:01:05 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411021201.AA25667@anubis.network.com> To: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: routers in solicited-node? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To (alphabetical order): Alex Conta Bill Simpson Jim Bound Other people that might be interested From: Fred Rabouw Subject; (IPng) IPv6 System Discovery: routers in solicited-node? Of my announced list of six (not seven) subjects: Number 3: Are routers included in the solicited-node multicast? Short summary: One opinion: for network management, a router is a normal host, so it should act as a normal host. That means it should listen to the solicited-node multicast. The other opinion: routers should ignore the (layer 2) solicited-node multicast. Since a router sends router-advertisements, its Media Address is known already. My comment: (1) Network management is especially useful when there are problems, one problem might be a router not sending correct router advertisements. Another problem might be that some router advertisements are lost and the router entry is timed out. In order to reach to that router it should react as a normal host on the solicited-node multicast. (2) Page 21 of draft-simpson-ipv6-discov-process states "It is desirable to store more than one default router in the list". That leaves the freedom of not storing all discovered routers. If such an endstation wants to telnet or ping to a router, he doesn't realize its a router and will use simple solicited-node multicast. My conclusion: A router should listen to the solicited-node multicast of his own address(es), there is no reason to listen to the other solicited-node-multicasts. Fred ------------------------------------------------------------------------------ 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 Nov 2 04:07:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12234; Wed, 2 Nov 94 04:07:36 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12228; Wed, 2 Nov 94 04:07:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08430; Wed, 2 Nov 94 04:03:07 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA23153; Wed, 2 Nov 94 04:02:20 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21973; Wed, 2 Nov 94 06:04:47 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA25670; Wed, 2 Nov 94 06:01:41 CST Date: Wed, 2 Nov 94 06:01:41 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411021201.AA25670@anubis.network.com> To: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: MAR and routers? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To (alphabetical order): Alex Conta Bill Simpson Jim Bound Other people that might be interested From: Fred Rabouw Subject; (IPng) IPv6 System Discovery: MAR and routers? Of my announced list of six (not seven) subjects: Number 4: Media Address Resolution and routers? Short summary Opinion one: A host doesn't need Media Address resolution to find a router, from the router- advertisement the Media Address is already learned. Opinion two: A router should accept Media Address resolution. My comment: I don't see much reason to argue: According to the specs, a node learns the Media Address of a router from the Router-Advertisement. So in a normal situation a host will never ask for the Media Address of a router. A router will need to use Media Address resolution to find endnodes. I think we all agree on that. Only when a node A doesn't realize another node B is a router, but he wants to talk to B, router B will have to answer incoming Media Address resolution. This is in fact the same situation as: Should a router listen to the solicited node multicast. There I already suggested it should. Fred ------------------------------------------------------------------------------ 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 Nov 2 04:09:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12264; Wed, 2 Nov 94 04:09:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12258; Wed, 2 Nov 94 04:08:52 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08512; Wed, 2 Nov 94 04:04:34 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA23384; Wed, 2 Nov 94 04:04:11 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21984; Wed, 2 Nov 94 06:06:38 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA25682; Wed, 2 Nov 94 06:03:38 CST Date: Wed, 2 Nov 94 06:03:38 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411021203.AA25682@anubis.network.com> To: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: permitted solicitations Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To (alphabetical order): Alex Conta Bill Simpson Jim Bound Other people that might be interested From: Fred Rabouw Subject; (IPng) IPv6 System Discovery: what solicitations are permitted Of my announced list of six (not seven) subjects: Number 5: RFC 1256 allows for more things than the document draft-simpson-ipv6-discov-process.Such as: (5a) permits vs requires router-solicitation when host boots (5b) host might do router-solicitation when router entry times out (5c) what to do when host entry times out (5d) what to do when router changes to host (5e) system management sets PerformRouterDisc I know this is the hotest one, we might have to split this one again. I will not give too much comment yet, first a short overview: Short overview of 5a: permits vs required router- solicitations. The facts: draft-simpson-ipv6-discov-process specifies: a host is required to send router-solicitations when ..... RFC1256 specifies: a host is permitted to ..... My comment: Very weak: RFC1256 works in an IPv4 world were many other nodes (including routers) have no idea about RFC1256. In the IPv6 we have the change to fix the actions before the implementations are there. As a result we might decide to change parts of RFC1256. Is it needed to do so ? ? ? Short overview of 5b, 5d, 5e: host doing router- solicitation later on. The issue is (very hot): Is a host allowed to send out router sollicitations after the first ten seconds after starting an interface. According to draft-simpson-ipv6-discov-process that is not allowed. In RFC1256 there is an option of allowing a host to do so. According to both specifications a router sends Router- Advertisements and timing out takes more than 3 advertisement intervals. So we discuss the situation that either a host missed the three advertisements of all routers in a row or the hosts timers are malfunctioning (Alex, I agree that my example of a host timing out every microsecond is very unlikely and heavily overcharged. On the other hand, bugs can cause any kind of problems.) I don't want to suggest anything yet, I see the point from both sides and did not yet make up my mind. Short overview of 5c: host looses another hosts entry. I might have missed it before, but I only saw it in one answer on one of my messages, where I really didn't have it in mind. Situation: What if a host X talks to another host Y and the entry on X for Y times out. My comment: It has nothing to do with router discovery. The draft-simpson-ipv6-discov-process document specifies what to do: The entry is lost, the next frame to Y is send to a known IPv6 address, but to an unknown IEEE address, resulting in sending it to the IEEE address "hashed-solicitated-node" address, so the frame is still send and no connection is lost. Directly after the data frame a General Sollicitation is send to Y to ask for its Media Address, resulting in later frames send to the Y's correct IEEE address again. No data is lost, no sessions are influenced. The only effect are two or more IEEE multicasts on the LAN. Fred ------------------------------------------------------------------------------ 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 Nov 2 04:09:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12316; Wed, 2 Nov 94 04:09:59 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12265; Wed, 2 Nov 94 04:09:20 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08539; Wed, 2 Nov 94 04:05:01 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA23479; Wed, 2 Nov 94 04:04:48 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21989; Wed, 2 Nov 94 06:07:15 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA25689; Wed, 2 Nov 94 06:04:15 CST Date: Wed, 2 Nov 94 06:04:15 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411021204.AA25689@anubis.network.com> To: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: IPv6 multicast to IEEE Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To (alphabetical order): Alex Conta Bill Simpson Jim Bound Other people that might be interested From: Fred Rabouw Subject; (IPng) IPv6 System Discovery: IPv6 multicast to IEEE Of my announced list of six (not seven) subjects: Number 6: The mapping of specific layer 3 multicasts on IEEE addresses. Short summary: At the moment the IPv6 specifications don't talk about which IEEE address to use for the multicasts. It was mentioned not to bother since that should be in a succesor of RFC1700 My comment: I don't care about the numerical value, but I do care about how many IEEE addresses will be used: If we map all IPv6 multicasts to a single IEEE multicast, it puts the lowest burden on the interface card and the highest burden on the CPU. We can deal with multicasts as if they are normal IPv6 addresses and map the to the base-solicited-node address + hashing value. That would mean that endnodes need to listen to multiple IEEE multicasts. We can map all multicasts that are send to routers and to servers to separate IEEE addresses to save the CPU's and map all IPv6 multicasts for endnodes to a single IEEE address to save their interface cards. That would result in the average endnode having to listen to two IEEE- multicasts: his hashed-solicited-node multicast (layer 2 multicast, layer 3 singlecast) and the endnodes-multicast (one layer 2 address serving many layer 3 multicasts). Fred ------------------------------------------------------------------------------ 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 Nov 2 05:01:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12702; Wed, 2 Nov 94 05:01:25 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12696; Wed, 2 Nov 94 05:01:18 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09909; Wed, 2 Nov 94 04:56:59 PST Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA27022; Wed, 2 Nov 94 04:56:48 PST Received: by rodan.UU.NET id QQxogx09998; Wed, 2 Nov 1994 07:56:35 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing and dicing of headers..... In-Reply-To: Your message of "Tue, 01 Nov 1994 12:45:37 EST." <199411011745.MAA17365@black-ice.cc.vt.edu> Date: Wed, 02 Nov 1994 07:56:35 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yes indeedy. It would be wonderful if we could provide an inexpensive "general policy enforcement mechanism," but since we don't even have a general policy expression mechanism, I think we'll have to put the "enforcement mechanism" on the RESEARCH TOPICS list. The routing issues, though, are real, live operational requirements which are reasonably well-understood today and will need to get addressed much sooner than some general DO-WHAT-I-SHOULD-HAVE-WANTED thingie can be achieved. -mo ------------------------------------------------------------------------------ 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 Nov 2 06:42:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12842; Wed, 2 Nov 94 06:42:11 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12830; Wed, 2 Nov 94 06:41:51 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13683; Wed, 2 Nov 94 06:37:32 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA10202; Wed, 2 Nov 94 06:37:22 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-29.dialip.mich.net [35.1.48.110]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA16696 for ; Wed, 2 Nov 1994 09:37:20 -0500 Date: Wed, 2 Nov 94 03:33:58 GMT From: "William Allen Simpson" Message-Id: <3388.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Local file Network Address/Name Support Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Dan McDonald > With all of this talk about having at one's disposal a local name<->address > table, I should show everyone what we have done so far here at NRL. > Heavens, an old "host" file -- even MacTCP uses the newer DNS text format. Anyway, looks fine to me. And we didn't need to put it in the protocol specification, either. 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 Nov 2 06:42:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12843; Wed, 2 Nov 94 06:42:15 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12836; Wed, 2 Nov 94 06:41:53 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13687; Wed, 2 Nov 94 06:37:35 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA10215; Wed, 2 Nov 94 06:37:25 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-29.dialip.mich.net [35.1.48.110]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA16699 for ; Wed, 2 Nov 1994 09:37:22 -0500 Date: Wed, 2 Nov 94 14:02:37 GMT From: "William Allen Simpson" Message-Id: <3389.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) 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 > >> - The system changes from being a router to being a host, by > >> having its IP forwarding capability turned off by system > >> management. > > Why is the above sentence not in the IPv6 system discovery spec? > It is! > > - A router has its forwarding capability turned off by system > > management. > Note that this is more correct, by the specific IPv6 definitions. BTW, in response to a private question, I have since changed the text to: A router has its forwarding capability for that interface turned off by system management. > >> > >> - The PerformRouterDiscovery flag for the interface is > >> changed from FALSE to TRUE by system management. > > Why is the above sentence not in the IPv6 system discovery spec? > Because Router Discovery is required in IPv6. > >See Processing p 8: > > > A IPv6 node is required to transmit up to MAX_SOLICITATIONS messages > > from any of its interfaces after any of the following events: > > Why in IPv6 system discovery does the above sentence state required, but > in RFC 1256 above it states "A host is permitted (but not > required)..".? > Because Router Discovery is required in IPv6. > > - A router has its forwarding capability turned off by system > > management. > > A node can be both a host and a router in one computer. Does the > above sentence apply to the router implementation on that computer > only? > ??? I cannot parse your sentences. 1) A node cannot be both a host and a router, according to the IPv6 definitions. 2) How can the words "A router" apply to more than one computer? > >Note that the host MUST NOT send solicitations under _any_ other > >circumstances, such as the router advert timeout, as you had earlier > >requested. > > I cannot find the above sentence in the version I am using to review > the processing spec? > It would be very surprising if that sentence appeared anywhere in the draft, since it refers to an email exchange. Processing page 8: If (and only if) no advertisements from neighboring routers are forthcoming, the node MAY retransmit the Router Solicitation a small number of times, but then MUST desist from sending more solicitations. Perhaps you don't understand the word "desist" (taken from 1256)? 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 Nov 2 07:23:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12946; Wed, 2 Nov 94 07:23:52 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12940; Wed, 2 Nov 94 07:23:42 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15796; Wed, 2 Nov 94 07:19:23 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA17443; Wed, 2 Nov 94 07:19:01 PST Received: by nero.dcrc.com (4.1/1.34) id AA04108; Wed, 2 Nov 94 10:18:39 EST Date: Wed, 2 Nov 94 10:18:39 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411021518.AA04108@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <3389.bill.simpson@um.cc.umich.edu> Subject: What's a host? (was (IPng) Interpretation for IPv6 System Discovery) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 94 14:02:37 GMT From: "William Allen Simpson" > From: bound@zk3.dec.com . . . > A node can be both a host and a router in one computer. Does the > above sentence apply to the router implementation on that computer > only? > ??? I cannot parse your sentences. 1) A node cannot be both a host and a router, according to the IPv6 definitions. . . . It's probably too late to debate terms, but permit me to make the observation that the IPv6 usage of the terms 'host' and 'router' is not congruent to what many people have internalized for these words. Many people (not excluding me) seem to use router as something like "a device capable of forwarding packets," in the IPv6 vein, but use host to mean something like "a communications endpoint" or "a device running application layer softare." Whether a node is a host by this definition is clearly independent of whether it is a router. (For example, a user can telnet to/from our routers or SNMP to them, which would lead some to think of them as hosts.) The point of this observation is twofold: (1) I believe Bill (and others who jump on the Host/Router terminology really do understand (or are capable of understanding) the questions when they are asked. For example if I turn on my router, and want to telnet from it before it has its routing, or from an interface that isn't participating in routing, what may/must I do with respect to Discovery, etc? (2) Perhaps we *should* consider tweaking the formal definition of "host" to conform to usage, instead of vice versa. -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 Wed Nov 2 07:52:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12992; Wed, 2 Nov 94 07:52:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12968; Wed, 2 Nov 94 07:51:41 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17578; Wed, 2 Nov 94 07:47:22 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA23035; Wed, 2 Nov 94 07:47:12 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA22830 for ; Wed, 2 Nov 1994 10:47:10 -0500 Date: Wed, 2 Nov 94 14:25:02 GMT From: "William Allen Simpson" Message-Id: <3391.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) solicited-node 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)) > Number 2: Is the solicited-node group worth the effort? > > One a LAN with less than (let's say) 50 IPv6 nodes I > really don't care about being selective with the IPv6 > multicasts. I care. On a mobile net, those nodes may be sleeping. We don't want to wake them with packets for other nodes. Saves power. Very important! > The proposed algorithm will work in 99.99% of the > networks by saving my end-station for at least half > the multicasts and most likely for much more. > Yep. On an autoconfigured net (which we expect), the distribution should be nearly perfect. Hand configuration could screw it up, but that's not our fault. > I do not yet see the issue. > Perhaps someone has a counter argument? 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 Nov 2 07:52:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12993; Wed, 2 Nov 94 07:52:21 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12974; Wed, 2 Nov 94 07:51:43 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17581; Wed, 2 Nov 94 07:47:24 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA23040; Wed, 2 Nov 94 07:47:14 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA22833 for ; Wed, 2 Nov 1994 10:47:12 -0500 Date: Wed, 2 Nov 94 14:34:28 GMT From: "William Allen Simpson" Message-Id: <3392.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) which multicasts 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)) > which link layer address to use for IPv6-multicasts? > (to Bill: I agree the value of the address should be > in RFC1700 or succesor, but a specification, such as > "base-solicited-address" or whatever can be in your > draft). > Actually, the address draft is where it belongs. > The first question is: Do we all agree this is as it is > specified? All is overly inclusive. We are looking only for reasons it might be broken. > The second question is: Is this all we need for the > neighbor discovery? (apart from IEEE address for last > point) > > I say "yes" to both questions. > 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 Nov 2 07:52:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12994; Wed, 2 Nov 94 07:52:28 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12980; Wed, 2 Nov 94 07:51:46 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17587; Wed, 2 Nov 94 07:47:27 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA23045; Wed, 2 Nov 94 07:47:17 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA22837 for ; Wed, 2 Nov 1994 10:47:14 -0500 Date: Wed, 2 Nov 94 14:37:16 GMT From: "William Allen Simpson" Message-Id: <3393.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) routers in solicited-node? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > One opinion: for network management, a router is a > normal host, so it should act as a normal > host. That means it should listen to the > solicited-node multicast. > The other opinion: routers should ignore the (layer 2) > solicited-node multicast. Since a > router sends router-advertisements, > its Media Address is known already. > This is not "opinion", it is part of the design. A "feature" that you missed is that Solicitation packets which are destined for a host will not be sent to a router. Routers are already busy. Another problem is that if a router gets the datagram, it will discover that it is not destined for itself, and a broken implementation would forward a duplicate to the host, wasting bandwidth. Of course, a broken multicast implementation might intercept multicast packets for groups it had not joined, resulting in the same problem. Both problems are completely solved by the simple IP requirement that datagrams may be duplicated. > My comment: > (1) Network management is especially useful when there are > problems, one problem might be a router not sending correct > router advertisements. Then the entire subnet would be down, and no communication would be possible (on that interface). If the management station was on that link, it wouldn't even have an autoconfigured address yet. If it was on another link, then it should use that other link to communicate with the router. > Another problem might be that some > router advertisements are lost and the router entry is > timed out. In which case the router is presumed dead. LifeTime is for black-hole detection. We can't assume that a black-hole isn't really black, just sort of gray. > In order to reach to that router it should react > as a normal host on the solicited-node multicast. > No. Only when routing is turned off for that interface. And this presumes that a router which had a broken router Neighbor Discovery implementation would have a correctly functioning host Neighbor Discovery implementation. Bad assumption. > (2) Page 21 of draft-simpson-ipv6-discov-process states "It > is desirable to store more than one default router in the > list". That leaves the freedom of not storing all > discovered routers. If such an endstation wants to telnet > or ping to a router, he doesn't realize its a router and > will use simple solicited-node multicast. > But, if the node doesn't have enough storage for the routers, where is it going to store the next hop? It's probably the same table. This is actually a leftover from the "send all packets to the router, which will re-direct". In that case, the default router would have told you the other router's address. 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 Nov 2 07:52:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13001; Wed, 2 Nov 94 07:52:33 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12985; Wed, 2 Nov 94 07:51:48 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17592; Wed, 2 Nov 94 07:47:29 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA23051; Wed, 2 Nov 94 07:47:19 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA22840 for ; Wed, 2 Nov 1994 10:47:17 -0500 Date: Wed, 2 Nov 94 15:09:29 GMT From: "William Allen Simpson" Message-Id: <3394.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 multicast to IEEE 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)) > At the moment the IPv6 specifications don't talk about > which IEEE address to use for the multicasts. It was > mentioned not to bother since that should be in a succesor > of RFC1700 > Actually, the mapping is the same as IPv4, into the same 23-bit IEEE block. > I don't care about the numerical value, but I do care about > how many IEEE addresses will be used: > If we map all IPv6 multicasts to a single IEEE multicast, > it puts the lowest burden on the interface card and the > highest burden on the CPU. > It was our intention to place the highest burden on the interface card, and the lowest on the CPU. > map all IPv6 multicasts for endnodes to a single IEEE > address to save their interface cards. That would result in > the average endnode having to listen to two IEEE- > multicasts: > his hashed-solicited-node multicast (layer 2 multicast, > layer 3 singlecast) > and the endnodes-multicast (one layer 2 address serving > many layer 3 multicasts). > This is not a discovery issue. It rather destroys the whole purpose of getting the 23-bit IEEE block for IP multicast. We WANT many addresses on the interface. 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 Nov 2 07:53:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13022; Wed, 2 Nov 94 07:53:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12995; Wed, 2 Nov 94 07:52:31 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17620; Wed, 2 Nov 94 07:48:12 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA23063; Wed, 2 Nov 94 07:47:22 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA22844 for ; Wed, 2 Nov 1994 10:47:19 -0500 Date: Wed, 2 Nov 94 15:13:19 GMT From: "William Allen Simpson" Message-Id: <3395.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) permitted solicitations 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)) > Number 5: RFC 1256 allows for more things than the > document draft-simpson-ipv6-discov-process.Such as: > (5a) permits vs requires router-solicitation > when host boots Yes. Support for Router Discovery is not required in IPv4, and _is_ required for IPv6. So, this is not an issue. > (5b) host might do router-solicitation when > router entry times out This is not allowed in RFC-1256, which specifically allows only certain circumstances in which a solicitation is sent. Is the same in IPv6, with the sole exception of (5e) below. > (5c) what to do when host entry times out A Neighbor Discovery issue, has nothing to do with Routers. Is exactly the same in IPv6 as IPv4 ARP. > (5d) what to do when router changes to host Is exactly the same in IPv6. > (5e) system management sets PerformRouterDisc > Since Neighbor Discovery is required in IPv6, this parameter no longer exists. (It was never put in the IF-MIB anyway.) Reducing configuration is a criteria of IPv6. > Short overview of 5b, 5d, 5e: host doing router- > solicitation later on. > The issue is (very hot): Is a host allowed to send out > router sollicitations after the first ten seconds after > starting an interface. > > In RFC1256 there is an option of allowing a host to do so. > Where? It is explicitly forbidden in the words (RFC-1256 page 3): When a host attached to a multicast link starts up, it may multicast a Router Solicitation to ask for immediate advertisements, rather than waiting for the next periodic ones to arrive; if (and only if) no advertisements are forthcoming, the host may retransmit the solicitation a small number of times, but then must desist from sending any more solicitations. Any routers that subsequently start up, or that were not discovered because of packet loss or temporary link partitioning, are eventually discovered by reception of their periodic (unsolicited) advertisements. Note "must desist". The problems of "packet loss" and "link partitioning" are explicitly covered. The same language is used in IPv6. (IPv6 terms are used, and Steve's run-on sentence is fixed.) > According to both specifications a router sends Router- > Advertisements and timing out takes more than 3 > advertisement intervals. So we discuss the situation that > either a host missed the three advertisements of all > routers in a row Again, note that this problem is explicitly addressed in the draft. > or the hosts timers are malfunctioning Nobody addresses this problem, but what's the problem? That damn host is malfunctioning, and will probably be sending all kinds of garbage, at a very high rate. Turn it off. > Situation: What if a host X talks to another host Y and the > entry on X for Y times out. > My comment: It has nothing to do with router discovery. Correct. Neighbor Discovery. > The entry is lost, the next frame to Y is send to a known > IPv6 address, but to an unknown IEEE address, resulting in > sending it to the IEEE address "hashed-solicitated-node" > address, so the frame is still send and no connection is > lost. > Directly after the data frame a General Sollicitation is > send to Y to ask for its Media Address, resulting in later > frames send to the Y's correct IEEE address again. > No data is lost, no sessions are influenced. The only > effect are two or more IEEE multicasts on the LAN. > Yep. Fast, Simple, Efficient. Uses Multicast, Reduced Bandwidth, Low Storage. Doesn't bother the routers. 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 Nov 2 07:58:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13041; Wed, 2 Nov 94 07:58:51 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13035; Wed, 2 Nov 94 07:58:44 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18209; Wed, 2 Nov 94 07:54:25 PST Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA24150; Wed, 2 Nov 94 07:53:50 PST Message-Id: <9411021553.AA24150@Sun.COM> Date: Wed, 2 Nov 94 10:47:27 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Performance Aggregate Gains in IPv6 (the Big Picture Test) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, The notion of a "Big Picture Test" raises the following issue. It seems that a lot of effort went into the design of the IPv6 packet headers to make sure that all fields were aligned on natural boundaries. After 64-bit addresses were replaced by 128-bit addresses, the fields are no longer aligned. I certainly expect 128-bit CPU chips within the design lifetime of IPv6, and they will most likely suffer performance hits when accessing the now mis-aligned fields. Will the final IPv6 headers be reworked to realign things? 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 Wed Nov 2 09:08:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13250; Wed, 2 Nov 94 09:08:53 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13243; Wed, 2 Nov 94 09:08:41 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24461; Wed, 2 Nov 94 09:04:22 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA04788; Wed, 2 Nov 94 09:01:30 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA24697; Wed, 2 Nov 94 08:59:28 -0800 Received: by xirtlu.zk3.dec.com; id AA14932; Wed, 2 Nov 1994 11:58:48 -0500 Message-Id: <9411021658.AA14932@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Wed, 02 Nov 94 14:02:37 GMT." <3389.bill.simpson@um.cc.umich.edu> Date: Wed, 02 Nov 94 11:58:41 -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 Bill, Thanks for the answers to my questions in previous mail. > 1) A node cannot be both a host and a router, according to the IPv6 > definitions. > 2) How can the words "A router" apply to more than one computer? I will take this thread to the one started by Mike Davis this a.m. 11/9. This issue relates to more than this discussion. >Processing page 8: > If (and only if) no advertisements from neighboring routers are > forthcoming, the node MAY retransmit the Router Solicitation a small > number of times, but then MUST desist from sending more > solicitations. In the above sentence it does not prevent an implementation from sending a solicitation, when the router advert has timed out after some period, and there has been no advertisements from neighboring routers forthcoming. /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 Nov 2 09:20:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13322; Wed, 2 Nov 94 09:20:22 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13313; Wed, 2 Nov 94 09:20:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25678; Wed, 2 Nov 94 09:15:53 PST Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA06313; Wed, 2 Nov 94 09:12:42 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA25481; Wed, 2 Nov 94 09:07:23 -0800 Received: by xirtlu.zk3.dec.com; id AA15346; Wed, 2 Nov 1994 12:06:44 -0500 Message-Id: <9411021706.AA15346@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: What's a host? (was (IPng) Interpretation for IPv6 System Discovery) In-Reply-To: Your message of "Wed, 02 Nov 94 10:18:39 EST." <9411021518.AA04108@nero.dcrc.com> Date: Wed, 02 Nov 94 12:06:38 -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 Mike, >It's probably too late to debate terms, but permit me to make the >observation that the IPv6 usage of the terms 'host' and 'router' is >not congruent to what many people have internalized for these words. >Many people (not excluding me) seem to use router as something like "a >device capable of forwarding packets," in the IPv6 vein, but use host >to mean something like "a communications endpoint" or "a device >running application layer softare." Whether a node is a host by this >definition is clearly independent of whether it is a router. (For >example, a user can telnet to/from our routers or SNMP to them, which >would lead some to think of them as hosts.) Its not too late to debate terms. I think your points of difference in functionality are correct. A vendor can build a node that supports Application Layer Software, for example a Server, and in that same node support IPv6 routing. The point of this observation is twofold: >(1) I believe Bill (and others who jump on the Host/Router terminology >really do understand (or are capable of understanding) the questions >when they are asked. For example if I turn on my router, and want to >telnet from it before it has its routing, or from an interface that >isn't participating in routing, what may/must I do with respect to >Discovery, etc? Exactly. >(2) Perhaps we *should* consider tweaking the formal definition of >"host" to conform to usage, instead of vice versa. I agree. 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 Wed Nov 2 09:34:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13415; Wed, 2 Nov 94 09:34:18 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13408; Wed, 2 Nov 94 09:34:11 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27517; Wed, 2 Nov 94 09:29:50 PST Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA08217; Wed, 2 Nov 94 09:24:56 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26439; Wed, 2 Nov 94 09:17:10 -0800 Received: by xirtlu.zk3.dec.com; id AA16387; Wed, 2 Nov 1994 12:16:30 -0500 Message-Id: <9411021716.AA16387@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) BSD Socket API sent to X/Open List fyi Date: Wed, 02 Nov 94 12:16: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 This is good that Ran did this because if X/Open will track our API now it will happen for XTI/TLI more expediently and in POSIX 1003.12 too. p.s. Dan M. - We should talk off line as I just about have what I believe the security API should be for IPv6 completed and proposed wording. Might not want competing specs for security API to go to X/Open, plus mine will go to POSIX too. It would also be nice if it was part of BSD API present spec too. /jim >From XoXTI-request@xopen.co.uk Wed Nov 2 09:25:57 1994 Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA17880; Wed, 2 Nov 1994 09:25:56 -0500 Received: from xopen.xopen.co.uk by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01886; Wed, 2 Nov 1994 09:25:52 -0500 Received: by xopen.xopen.co.uk (1.36.108.3/15.6) id AA10416; Wed, 2 Nov 94 14:16:57 GMT Message-Id: <9411021416.AA10416@xopen.co.uk> Received: by xopuk.xopen.co.uk (1.36.108.3/16.2) id AA29383; Wed, 2 Nov 94 14:16:43 GMT Date: Wed, 2 Nov 94 14:16:43 GMT From: Petr Janecek To: XoXTI@xopen.co.uk Subject: (XoXTI 610) Re: IPng (IPv6) and POSIX 1003.1g Sender: XoXTI-request@xopen.co.uk Comments: (XoXTI 610) Status: R Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) From: Ran Atkinson Date: Wed, 2 Nov 1994 08:50:12 -0500 To: Chris Harding , "P1003.1g" Subject: Re:IPng (IPv6) and POSIX 1003.1g Comments: (c.harding 2640,p.janecek 10117) Folks might want to examine the current draft of the Sockets API for use with IPv6 for information and review. It is available online from: ftp://ds.internic.net/internet-drafts/draft-gilligan-ipv6-bsd-api-*.txt Implementations of that API exist or are underway several places, including within my IPv6 group at NRL. Comments are welcome. If someone were TLI/XTI knowledgable and wanted to contribute a draft of TLI/XTI extensions for IPv6, that would be useful. Bob Gilligan is probably a good POC for the IPv6 API issues. IPv6 Security API Extensions for the above IPv6 BSD API are currently being developed by Dan McDonald (NRL) and should appear online fairly soon now. Regards, Ran atkinson@itd.nrl.navy.mil ------- 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 Wed Nov 2 11:21:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13613; Wed, 2 Nov 94 11:21:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13607; Wed, 2 Nov 94 11:21:33 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB15136; Wed, 2 Nov 94 11:17:11 PST Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA25001; Wed, 2 Nov 94 11:14:01 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA05975; Wed, 2 Nov 94 10:56:06 -0800 Received: by xirtlu.zk3.dec.com; id AA19212; Wed, 2 Nov 1994 13:55:27 -0500 Message-Id: <9411021855.AA19212@xirtlu.zk3.dec.com> To: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Cc: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 System Discovery: permitted solicitations In-Reply-To: Your message of "Wed, 02 Nov 94 06:03:38 CST." <9411021203.AA25682@anubis.network.com> Date: Wed, 02 Nov 94 13:55:21 -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 >Subject; (IPng) IPv6 System Discovery: what solicitations >are permitted >Of my announced list of six (not seven) subjects: >Number 5: RFC 1256 allows for more things than the >document draft-simpson-ipv6-discov-process.Such as: > (5a) permits vs requires router-solicitation > when host boots > (5b) host might do router-solicitation when > router entry times out > (5c) what to do when host entry times out > (5d) what to do when router changes to host > (5e) system management sets PerformRouterDisc I think Bill in an early response settled 5e for me that router discovery is required in IPv6? I agree. >Short overview of 5a: permits vs required router- >solicitations. The facts: >draft-simpson-ipv6-discov-process specifies: a host is >required to send router-solicitations when ..... >RFC1256 specifies: a host is permitted to ..... I agree with RFC 1256 and Bill pointed out in his response the differences between 1256 and IPv6 discovery. I agree with his reasoning. Where we don't agree is the use of all-routers solicitation for discovery. If in fact we determine as a working group the solicited-nodes multicasdt is not a good idea, then we have to go back and determine when and why all-hosts and all-routers is used. So it appears to me we need to first decide if all-solicited nodes is going to be used in IPv6. This is one reason why I am still arguing for all-router solicitations on hosts. >My comment: Very weak: RFC1256 works in an IPv4 world were >many other nodes (including routers) have no idea about >RFC1256. In the IPv6 we have the change to fix the actions >before the implementations are there. As a result we might >decide to change parts of RFC1256. >Is it needed to do so ? ? ? Absolutely. IPv6 will cause changes to RFC 1122 too, and OSPF and other IPv4 specs. The question is are they just changes or rewrites? This needs to be discussed in the IETF. >Short overview of 5b, 5d, 5e: host doing router- >solicitation later on. >The issue is (very hot): Is a host allowed to send out >router sollicitations after the first ten seconds after >starting an interface. I will defer to Fred, Alex, Bill and others on this one and need to see more discusion. >Short overview of 5c: host looses another hosts entry. >I might have missed it before, but I only saw it in one >answer on one of my messages, where I really didn't have it >in mind. >Situation: What if a host X talks to another host Y and the >entry on X for Y times out. >My comment: It has nothing to do with router discovery. The >draft-simpson-ipv6-discov-process document specifies what >to do: >The entry is lost, the next frame to Y is send to a known >IPv6 address, but to an unknown IEEE address, resulting in >sending it to the IEEE address "hashed-solicitated-node" >address, so the frame is still send and no connection is >lost. >Directly after the data frame a General Sollicitation is >send to Y to ask for its Media Address, resulting in later >frames send to the Y's correct IEEE address again. >No data is lost, no sessions are influenced. The only >effect are two or more IEEE multicasts on the LAN. This should be orthogonal to multicast solicitation type and it confuses the discussion. Bill proposes data packet > request packet > reply packet. Alex proposes data-request-packet > reply packet in the case where the MTU is not broken via a hop-by-hop option. Alex points out that for 80% of the packets on a LAN that the MTU will not be exceeded because of the hop-by-hop option and I think its 90%. For the case where the MTU is exceeded then Alex proposes request packet > reply packet > data packet. Alex's proposal reduces processing time on the hosts, and reduces the packets sent when media address resolution must occur to 2 packets in 90% of the cases on the LAN. I think this is a net gain in performance for IPv6, which is a substantive benefit. I think Alex's proposal is the correct approach for IPv6 discovery. /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 Nov 2 11:22:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13629; Wed, 2 Nov 94 11:22:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13623; Wed, 2 Nov 94 11:22:10 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15314; Wed, 2 Nov 94 11:17:50 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA24977; Wed, 2 Nov 94 11:12:57 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA06290; Wed, 2 Nov 94 10:59:38 -0800 Received: by xirtlu.zk3.dec.com; id AA19274; Wed, 2 Nov 1994 13:58:59 -0500 Message-Id: <9411021858.AA19274@xirtlu.zk3.dec.com> To: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Cc: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 System Discovery: IPv6 multicast to IEEE In-Reply-To: Your message of "Wed, 02 Nov 94 06:04:15 CST." <9411021204.AA25689@anubis.network.com> Date: Wed, 02 Nov 94 13:58:53 -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 This one is easy for me to respond to. I think the solicited-nodes multicast is not scalable. As far as the IEEE for Multicast I would like to also hear from Steve Deering on this one too. /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 Nov 2 13:21:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13811; Wed, 2 Nov 94 13:21:58 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13805; Wed, 2 Nov 94 13:21:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05536; Wed, 2 Nov 94 13:17:27 PST Received: from vangogh.CS.Berkeley.EDU ([128.32.33.5]) by Sun.COM (sun-barr.Sun.COM) id AA16100; Wed, 2 Nov 94 13:12:08 PST Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Alpha.3/8.6.9.Beta0) id NAA25462 for ipng@sunroof.Eng.Sun.COM; Wed, 2 Nov 1994 13:10:13 -0800 (PST) Date: Wed, 2 Nov 1994 13:10:13 -0800 (PST) From: Keith Sklower Message-Id: <199411022110.NAA25462@vangogh.CS.Berkeley.EDU> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) replacement for gethostbyname() Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim Bound suggested that I send this to the mailing list **before** filing it as an internet draft: Network Working Group Keith Sklower INTERNET DRAFT University of California, Berkeley Expires: May 1, 1995 Getconninfo(): An alternative to Gethostbyname() draft-ietf-sklower-conninfo-1.txt 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 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories to learn the current status of any Internet Draft. Abstract This document proposes a uniform programmatic interface to the Internet name resolution system, in which differences between IPv4, IPv6, and CLNP are irrelevant to the applications programmer. This work was originally motivated by the desire to minimize the impact on standard BSD utilities to support TUBA, but work equally well for IPv6. Acknowledgements The author specifically wishes to thank William Durst of the MITRE coporation, Steven Wise of IBM, Michael Karels of BSDI, and Eric Allman of the University of California at Berkeley for many useful discussions of the subject, and thorough review of early versions of the proposal, and especially thank Eric Allman for implementing a prototype. The observation that specifying the pair of name and service would suffice for connecting to a service independent of protocol details was made by Marshall Rose in a proposal to X/Open Sklower [Page 1] Draft Getconninfo November 1994 for a "Uniform Network Interface". 1. Introduction Although the IETF normally concerns itself with the details of how information is exchanged between computers, the advent of a revision to the IP protocol has implications for application writers, and a series of comments and suggestions have been made concerning this. In the present BSD programming environment, and in the internet protocol context, an applications writer must perform a name-to- address and service-to-port translation before issuing socket primitives to initiate a connection to service, or to offer a service. The programmer then combines this information into a protocol specific addressing structure. Aside from the process of combining the information, it may be possible to code up the rest of the service in a way that makes no other reference IP specific details. Our experience with implementing TCP serivces over CLNP has given us a few cases-in- point. We give the details of a prototype implementation done at Berkeley; and afterwards discuss some alternatives. A similar interface called getaddrinfo() has been proposed in the IEEE Posix networking subcomittee[1], but the author is not aware of any prototype implementation of it. 2. A proposal The C-language interface is provided by two routines: struct conninfo * getconninfo(char *host, char *service, struct conninfo *clues); void freeconninfo(struct conninfo *nuked); where the conninfo structure is defined below. This structure contains either the information obtained from the name server, and/or broken-out fields from a line in /etc/hosts, and /etc/services. If the local name server is not running these routines do a lookup in those static files and possibly others. The getconninfo() function returns a pointer to a linked list of objects. The ``clues'' parameter may be omitted, in which case all possible matches in all address families are returned; or it may be Sklower [Page 2] Draft Getconninfo November 1994 used to limit the queries to return a prespecified set of protocols, with or without aliasing. The ``host'' parameter may be null or ``'', meaning allow connections on any interface in the case of active open or connect to the local host on active opens. This currently works for all implementations. For future protocols where this cannot be made to work, extensions could be either permitting ``*passive*'' for the host name in the passive case, or requiring a flag on supplied third parameter (clues). The conninfo struct is given by: struct conninfo { int ci_flags; #define CI_NOALIAS 0x01 /* no mx agents, or aliases */ #define CI_THISAF 0x02 /* only retrieve in this AF */ #define CI_THISTYPE 0x04 /* only retrieve this socktype */ #define CI_THISPROTO 0x08 /* only retrieve this proto */ #define CI_PASSIVE 0x80 /* intended for bind() + listen() */ #define CI_CANONICAL 0x100 /* request canonical name */ int ci_af; int ci_socktype; int ci_proto; int ci_namelen; char *ci_canon; struct sockaddr *ci_name; struct conninfo *ci_next; }; Members of this structure are: ci_flags This modifies the behavior of getconninfo in ways described above; ci_af The type of address being returned. ci_socktype The socket type required as the second argument in a call to socket(). ci_proto The specific protocol required as the third argument in a call to socket(). Sklower [Page 3] Draft Getconninfo November 1994 ci_name The binary address, suitable for use as an argument to connect() or bind(). ci_namelen The length, in bytes, of the address. ci_canon The canonical name for the host. This is an output of the function, and is only provided if the CI_CANNONICAL flag is set on the clues paramater. When using the Internet nameserver, getconninfo() would search for the named host in the current domain and its parents unless the name ends in a dot. If the name contains no dot, and if the environment variable ``HOSTALIASES'' contains the name of an alias file, the alias file will first be searched for an alias matching the input name. Getconninfo() will also translate hosts specified in internet dotted-quad notation according to the syntax ``[a.b.c.d]'', and will accept ascii renditions of integers for service names, eg. ``6''. Error return status from getconninfo() is indicated by return of a null pointer. The external variable h_errno may then be checked to see whether this is a temporary failure or an invalid or unknown host. The variable h_errno can have the following values: HOST_NOT_FOUND No such host is known. TRY_AGAIN This is usually a temporary error and means that the local server did not receive a response from an authoritative server. A retry at some later time may succeed. NO_RECOVERY Some unexpected server failure was encountered. This is a non- recoverable error. NO_DATA The requested name is valid but does not have an IP address; this is not a temporary error. This means that the name is known to the name server but there is no address associated with this name. Another type of request to the name server using this domain name will result in an answer; for example, a mail- forwarder may be registered for this domain. Sklower [Page 4] Draft Getconninfo November 1994 3. Alternatives The proposal being discussed by Posix differs from getconninfo primarily in two ways: the reporting of errors, and the returning of values as a single chunk rather than a linked list. The function itself returns 0 on successs or the error number if unsucessful, and the user is required to provide an argument pointer which will be overwritten with a pointer to the informatin obtained. We view these differences as relatively minor. What was of concern to the author was that the number of parameters to the function be very small and that the encoding of optional behavior be made by interpretation of elements in a structure argument rather than separate parameters. 4. References [1] IEEE, "Information Technology-Portable Operating System Interface (Posix), P1003.12 Draft 5.0" IEEE, July 1994. 5. Authors' Addresses Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-9587 E-mail: sklower@CS.Berkeley.EDU 6. Expiration Date of this Draft May 1, 1995 Sklower [Page 5] ------------------------------------------------------------------------------ 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 Nov 2 13:40:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13879; Wed, 2 Nov 94 13:40:59 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13873; Wed, 2 Nov 94 13:40:51 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09373; Wed, 2 Nov 94 13:36:32 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20099; Wed, 2 Nov 94 13:36:21 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA02722; Wed, 2 Nov 94 10:22:06 -0800 Received: by xirtlu.zk3.dec.com; id AA18948; Wed, 2 Nov 1994 13:21:27 -0500 Message-Id: <9411021821.AA18948@xirtlu.zk3.dec.com> To: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Cc: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 System Discovery: routers in solicited-node? In-Reply-To: Your message of "Wed, 02 Nov 94 06:01:05 CST." <9411021201.AA25667@anubis.network.com> Date: Wed, 02 Nov 94 13:21:21 -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 Number 3: Are routers included in the solicited-node multicast? >Short summary: >One opinion: for network management, a router is a > normal host, so it should act as a normal > host. That means it should listen to the > solicited-node multicast. >The other opinion: routers should ignore the (layer 2) > solicited-node multicast. Since a > router sends router-advertisements, > its Media Address is known already. Fred - Point of discussion order. In my last mail I stated that based on your mail I do not think solicited-nodes should be used. Here you assume it has been agreed to in the summary. I will do my best to make it clear what my issues are here without assuming solicited-node. Do we have to fix this point of discussion order to come to resolution? thanks Now assuming that solicited-nodes are not going to be used not that this is the decision, but I need to state a different hypothesis. Multicast Solicitation Scenario #1 Should all nodes listen to all-hosts multicast solicitation or only hosts? If they do then nothing has be gained by moving to multicast once this is permitted. Also in this case if routers are listening to all-hosts multicast then any proposal where a piggyback unicast datagram accompanies an all-hosts solicitation will cause a fault at the router if it trys to forward that datagram because it is for that subnet. This would imply we need to either oullaw piggybacking or state that a router needs to know its an all-host multicast, or set the hop-count to some value so it will not be forwarded, or within the piggyback datagram recognize it in fact is a piggyback datagram. Multicast Solicitation Scenerio #2 Should a host use all-routers multicast when sending a solicitation to a router. This implies that the host will keep the state necessary in its implementation that if it cannot find a media address for the node it can determine if the destination node on the LAN is a router or host. The benefit here is that the hosts are not bothered by an all-router solicitation and the routers are not bothered by an all-hosts solicitation. The complexity in the host to accomplish this needs further discussion from host implementors regarding complexity, performance costs, and robustness. This will also work when the router also has to support application layer software such as telnet, snmp, or DHCPng. I think Scenaro #2 is the right choice. >My comment: >(1) Network management is especially useful when there are >problems, one problem might be a router not sending correct >router advertisements. Another problem might be that some >router advertisements are lost and the router entry is >timed out. I believe that to communicate with a router the all-router solicitation should be used as stated above for media address resolution. /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 Nov 2 13:41:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13891; Wed, 2 Nov 94 13:41:30 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13885; Wed, 2 Nov 94 13:41:23 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09436; Wed, 2 Nov 94 13:37:04 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20187; Wed, 2 Nov 94 13:36:47 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA28119; Wed, 2 Nov 94 09:36:21 -0800 Received: by xirtlu.zk3.dec.com; id AA18253; Wed, 2 Nov 1994 12:35:42 -0500 Message-Id: <9411021735.AA18253@xirtlu.zk3.dec.com> To: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Cc: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 System Discovery: which multicasts In-Reply-To: Your message of "Wed, 02 Nov 94 05:59:01 CST." <9411021159.AA25643@anubis.network.com> Date: Wed, 02 Nov 94 12:35:35 -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 >From: Fred Rabouw >Number 1: Which multicast/broadcast addresses do exist? >The first question is: Do we all agree this is as it is >specified? I agree. The second question is: Is this all we need for the neighbor discovery? (apart from IEEE address for last point) I can't say yes or no yet. I believe solicited-nodes is very efficient. But will solicited-nodes scale for all cases of IPv6 addresses? I am also unclear when I would use ALL-NODES-MULTICAST vs SOLICITED-NODES-MULTICAST? Do we need both? So I can't answer yes or no without some focused discussion on this thread. /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 Nov 2 13:58:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13940; Wed, 2 Nov 94 13:58:37 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13934; Wed, 2 Nov 94 13:58:30 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12519; Wed, 2 Nov 94 13:54:06 PST Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA22092; Wed, 2 Nov 94 13:48:56 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA08871 for ipng@sunroof.eng.sun.com; Wed, 2 Nov 94 16:47:51 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id NAA09011; Wed, 2 Nov 1994 13:46:15 -0800 Message-Id: <199411022146.NAA09011@aland.bbn.com> To: Keith Sklower Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) replacement for gethostbyname() In-Reply-To: Your message of Wed, 02 Nov 94 13:10:13 -0800. <199411022110.NAA25462@vangogh.CS.Berkeley.EDU> From: Craig Partridge Date: Wed, 02 Nov 94 13:46:13 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Keith: Interesting idea. A few suggestions. The term getconninfo() suggests this gets connection information, in which case it would be irrelevant to connectionless protocols like UDP. Why not call it getservinfo()? Also, the draft seems to bite its tail in a few places. At one level it says it is for interfacing with the Internet, yet I can specify an arbitrary AF. Why not make it a generic mechanism for pulling up an address based on a name and an AF and remove mentions of Internet and IP? Finally, and this is just my preference, I'd much prefer the interface to look like this: struct sockaddr *getconninfo(char *host, char *service, int cf, int socktype, int proto, int flags, int *namelen, char *cname) so my call might be: if (sa = getconninfo(name,serv,AF_INET,SOCK_STREAM,0,0,&len,(char *)0)) { (void) fprintf(stderr,"can't find name %s (h_errno = %d)\n", name,h_errno); exit(1); } the struct just looks clumsy. If we need some way to create linked-lists of sockaddrs, fine, let's create that generic structure and use it here. Say struct socklist { struct sockaddr *sl_sa; struct socklist *sl_next; } Finally, we really need namelen now that sockaddrs have their length built into them? Thanks! Craig ------------------------------------------------------------------------------ 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 Nov 2 14:53:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13998; Wed, 2 Nov 94 14:53:24 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13989; Wed, 2 Nov 94 14:53:12 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21955; Wed, 2 Nov 94 14:48:53 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA02417; Wed, 2 Nov 94 14:46:09 PST Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA12250; Wed, 2 Nov 1994 17:44:28 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA23218; Wed, 2 Nov 1994 17:44:27 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA19738; Wed, 2 Nov 1994 17:20:57 -0500 Message-Id: <9411022220.AA19738@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com, conta@zk3.dec.com Subject: Re: (IPng) Performance Aggregate Gains in IPv6 (Big Picture Test) In-Reply-To: Your message of "Wed, 02 Nov 94 02:39:02 EST." <9411020739.AA20613@xirtlu.zk3.dec.com> Date: Wed, 02 Nov 94 17:20:57 -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 .... Per John's last sentence the preposition "for a minor performance improvement" (I am not disagreeing with John's mail subject or agreeing just using it as spring board to begat this thread.). .... When we work on disocovery, transition, APIs, routing, et al for IPv6 often implementors propose changes that will afford increases in performance either by direct throughput of packets or a reduction in processing time on the node. During this discourse sometimes we ask is the pain worth the gain of the implementor or architect proposing the change? I think this is a valid question, but what we also need to ask ourselves is what are the sum total of gains for all of these proposed changes when the fulcrum of the implementors proposed change is in fact some performance gain, which can be proven over another implementors solution. Jim, Good points. And true facts. I may not say something new, or something nobody knows. What I learned in sports, I learned later in networking. Every fraction of a second of getting better at running the 100m sprint, meant days and days of perfecting every feet and legs motioni, the angle or position of my body, and hands. Later in networking I learned that in an implementation BIG performance gains come from the SUM of MANY SMALL gains. And so I learned that to have a final BIGGER performance gain I better do not disregard any SMALL gain. What I would call this is the "Performance Aggregate Gains in IPv6" test, before we discount any performance improvements from any implementor as a trivial "performance gain". Many times how to qualify a performance gain depends on perspective. For instance if from a communication of 50000 packets in 30 minutes, I reduced the number of packets with 3, then it is obvious it does not look like a big deal. But if I look only at address resolution, and see that instead of 6 address resolution packets I sent only 3, that is a 50% gain (it was assumed address resolution cache timout = 10 min). 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 Nov 2 15:17:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14122; Wed, 2 Nov 94 15:17:09 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14116; Wed, 2 Nov 94 15:17:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26408; Wed, 2 Nov 94 15:12:42 PST Received: from bells.cs.ucl.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA11265; Wed, 2 Nov 94 09:44:05 PST Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Nov 1994 17:11:59 +0000 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Performance Aggregate Gains in IPv6 (the Big Picture Test) In-Reply-To: Your message of "Wed, 02 Nov 94 10:47:27 EST." <9411021553.AA24150@Sun.COM> Date: Wed, 02 Nov 94 17:11:58 +0000 Message-Id: <3088.783796318@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Charlie, and will the ATM people re-size their cells so an integrated cut thru switch/bridge/router can do filter tests on the first cell of any AAL frame (i.e. so it will hold optional MAC and 802 header, IP6 header + TCPng, or IP6 + UDP + RTP)? the thought of trying to buffer the first cell or two before making a decision is worrying me....and i bet people will want such boxes... 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 Wed Nov 2 15:34:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14156; Wed, 2 Nov 94 15:34:36 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14150; Wed, 2 Nov 94 15:34:28 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29559; Wed, 2 Nov 94 15:30:09 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA10161; Wed, 2 Nov 94 15:28:03 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00706; Wed, 2 Nov 94 10:01:08 -0800 Received: by xirtlu.zk3.dec.com; id AA18590; Wed, 2 Nov 1994 13:00:25 -0500 Message-Id: <9411021800.AA18590@xirtlu.zk3.dec.com> To: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Cc: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 System Discovery: solicited-node In-Reply-To: Your message of "Wed, 02 Nov 94 05:59:42 CST." <9411021159.AA25646@anubis.network.com> Date: Wed, 02 Nov 94 13:00:19 -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 >Number 2: Is the solicited-node group worth the effort? >One a LAN with less than (let's say) 50 IPv6 nodes I >really don't care about being selective with the IPv6 >multicasts. Since IPv6 shouldn't multicast to much >anyway, the number of multicasts per second will be >that low that even a 386-PC can handle them. With >more than 50 nodes I agree any hashing algorithm can >turn out to be ineffective and map all addresses on >the same multicast, but how likely is that? I believe that more than 50 nodes on a LAN will be common. >The proposed algorithm will work in 99.99% of the >networks by saving my end-station for at least half >the multicasts and most likely for much more. We should not build into the link layer in IPv6 a dependency that a LAN will become less efficient as it grows in number of nodes. We need to be more flexible in the IPv6 architecture. So I do not support solicited-nodes multicast strategy in the discovery specifications. I suggest we clearly state when and why all-hosts, all-routers, and all-nodes are used for IPv6 in the specifications. >Note: >There is a separate thread on many IPv6 addresses per >interface and the effect of that on the interface card >having to handle multiple multicasts. >(1) There is hardly any reason for a host that is > not a router AND not a server to have multiple > IPv6 addresses, so the average endstation can do > with one IPv6 address and by that with listening > to only a few multicasts. >(2) Routers or servers might want to have many IPv6 > addresses, but they will should have up-to-date > interfaces that can handle the multicast load >I do not yet see the issue. For IPv6: 1. Multiple subnets can exist on a link, but cannot span multiple links. 2. An interface can support more than one IPv6 address. >From my work in engineering I have often seen cases where customers in IPv4 wanted to support multiple addresses on one interface. I think we cannot try to second guess what customers will want to do with IPv6 and assume that the majority of users will not use multiple addresses on an interface for IPv6. I can't support such a thinking process to determine our multicast architecture strategy for IPv6. We should clearly define how to use all-hosts, all-routers, and all-nodes multicast addresses. This will reduce the processing time on nodes over the present broadcast scheme in IPv4 by selection of the correct multicast solicitation. A key point of the definitions TBD for the types of mulicast packets is when can packets be discarded at the link layer. /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 Nov 2 15:46:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14177; Wed, 2 Nov 94 15:46:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14171; Wed, 2 Nov 94 15:46:09 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01697; Wed, 2 Nov 94 15:41:50 PST Received: from inet-gw-3.pa.dec.com ([16.1.0.33]) by Sun.COM (sun-barr.Sun.COM) id AA12093; Wed, 2 Nov 94 15:39:14 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA03818; Wed, 2 Nov 94 10:33:36 -0800 Received: by xirtlu.zk3.dec.com; id AA19045; Wed, 2 Nov 1994 13:32:58 -0500 Message-Id: <9411021832.AA19045@xirtlu.zk3.dec.com> To: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Cc: bill.simpson@um.cc.umich.edu, bound@zk3.dec.com, conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 System Discovery: MAR and routers? In-Reply-To: Your message of "Wed, 02 Nov 94 06:01:41 CST." <9411021201.AA25670@anubis.network.com> Date: Wed, 02 Nov 94 13:32:52 -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 Number 4: Media Address Resolution and routers? >Short summary >Opinion one: A host doesn't need Media Address resolution > to find a router, from the router- > advertisement the Media Address is already > learned. >Opinion two: A router should accept Media Address > resolution. >My comment: >I don't see much reason to argue: I disagree and must argue per my last message. I do not think now solicited-node multicast is a good idea. >According to the specs, a node learns the Media Address of >a router from the Router-Advertisement. So in a normal >situation a host will never ask for the Media Address of a >router. Per my last message I gave an option for use of all-routers solicitation for discovery.. >A router will need to use Media Address resolution to find >endnodes. I think we all agree on that. Yes. >Only when a node A doesn't realize another node B is a >router, but he wants to talk to B, router B will have to >answer incoming Media Address resolution. This is in fact >the same situation as: Should a router listen to the >solicited node multicast. There I already suggested it >should. Yes but I do not think solicited-nodes address is a good idea on the first discussion topic. Then in the second topic I proposed using the three models all-hosts, all-routers, and all-nodes (not clear when this is used but I know we need it). Hence, I am saying there is a new requirement in IPv6 for a host to perform all-routers multicast that is in RFC 1256. The key reasoning for this is that I believe that there should be a differentiation between all-hosts and all-routers multicast solicitations in IPv6. And that the solicited-node multicast is not a good idea, because its efficiency is effective for a miniumu number of nodes on a LAN. /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 Nov 2 15:52:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14195; Wed, 2 Nov 94 15:52:08 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14183; Wed, 2 Nov 94 15:51:52 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02753; Wed, 2 Nov 94 15:47:33 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA13607; Wed, 2 Nov 94 15:46:39 PST Subject: Re: (IPng) Performance Aggregate Gains in IPv6 (the Big Picture Test) To: IPng Mailing list Date: Wed, 2 Nov 1994 12:30:23 -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: 1860 Message-Id: <9411021730.aa14892@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >The notion of a "Big Picture Test" raises the following issue. It >seems that a lot of effort went into the design of the IPv6 packet >headers to make sure that all fields were aligned on natural >boundaries. After 64-bit addresses were replaced by 128-bit >addresses, the fields are no longer aligned. They are still 64-bit aligned, but they are NOT 128-bit aligned. That wording could be misinterpreted by those whose feathers easily ruffle. >I certainly expect >128-bit CPU chips within the design lifetime of IPv6, My friend in the processor design business has said that 128-bit CPU's on the desktop could surface around 2010-2020. He has also said that his employer wonders if even 64-bit processors are overkill. From what I've seen in the market, 64-bit processors are only now digging in. I suspect that 128-bit processors will be dig in toward the latter part of the dates given above. >and they will >most likely suffer performance hits when accessing the now mis-aligned >fields. The misaligned fields are misaligned by 64-bits. Current 64-bit processors are more forgiving for off-by-half aligment errors than they are for other brain-damage. >Will the final IPv6 headers be reworked to realign things? I think that's a bit of overkill. If I was designing a 128-bit IPv6 engine, I could place the incoming packet on an odd-64-bit boundary such that the addresses lie on 128-bit boundaries. Bottom line: I think we'll need IPv[89] (for reasons yet unknown) by the time 128-bit processors become commonplace. -- 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 Wed Nov 2 17:17:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14407; Wed, 2 Nov 94 17:17:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14401; Wed, 2 Nov 94 17:17:38 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16600; Wed, 2 Nov 94 17:13:17 PST Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA12780; Wed, 2 Nov 94 09:55:49 PST Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id MAA20777; Wed, 2 Nov 1994 12:18:42 -0500 Message-Id: <199411021718.MAA20777@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing and dicing of headers..... In-Reply-To: Your message of "Wed, 02 Nov 1994 07:56:35 EST." From: Valdis.Kletnieks@vt.edu Date: Wed, 02 Nov 1994 12:18:41 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Wed, 02 Nov 1994 07:56:35 EST, you said: > It would be wonderful if we could provide an inexpensive "general > policy enforcement mechanism," but since we don't even have a > general policy expression mechanism, I think we'll have to put > the "enforcement mechanism" on the RESEARCH TOPICS list. That's the logic that got us the IP V4 TOS field, and its corresponding widespread use and support. Even if we don't have a general expression mechanism, I think that *this* time around, we need to define a better interface than "We'll leave this byte open for when we decide what we want to do". Not having all the specs in front of me, protocol issues that pop off the top of my head include: "Should a router have a seperate ICMP_POLICY_PROB error, as well as HOST/NET_Unreachable"? "Should there be an ICMP Policy_redirect?", and so on. > The routing issues, though, are real, live operational requirements > which are reasonably well-understood today and will need to > get addressed much sooner than some general DO-WHAT-I-SHOULD-HAVE-WANTED > thingie can be achieved. Different environments have different requirements. In ours, routing policy is not an issue, since 98% of the time, a host or router has only 1 real choice per destination. On the other hand, with some 8,000+ SLIP addresses assigned, we *could* use things like a "no video on this link" policy, and so on... /Valdis ------------------------------------------------------------------------------ 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 Nov 2 17:28:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14429; Wed, 2 Nov 94 17:28:51 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14418; Wed, 2 Nov 94 17:28:42 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA08295; Wed, 2 Nov 94 17:24:14 PST Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA28450; Wed, 2 Nov 94 17:22:04 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 3 Nov 1994 09:11:17 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 2 Nov 1994 13:19:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 2 Nov 1994 14:18:22 +1000 Date: Wed, 2 Nov 1994 14:18:22 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941102 10:58:20 007] X400-Content-Type: P2-1984 (2) Content-Identifier: 941102 10:58:20 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941102 10:58:20*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng (Non Receipt Notification Requested) Subject: (IPng) RE: (IPNG) ANNOUNCEMENT OF NEW MAILING-LIST (CORRECTION) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM masataka, I appreciate the need for this list, but I thought the work was how IP6 might use a connection less service interface over ATM (ie use the AAL Convergent Sublayer for the transportation of Datagrams). The work I suppose is mapping IP 'QOS' to the connection parameter values as specified in Q.2931 for AAL parameters and throughput, etc. Plus of course how one intends to deal with address mapping (whoops - a logical internetwork onto a real dependent geographically based numbering plan (E.164)) and other levels of B- ISDN service such as connection/disconnection processing inc multicast / multiparty calls, and those issues of address resolution. In some earlier discussion I did raise my concerns with flow ids and that I thought the concept of them was unimplementable. Some responses told me that this issue has been, because of difficulty, put aside. This is because one is taking an internetworking user value of QOS and trying to propagate it across a network which may or may not be managed, have different link types, or in fact relate that QOS specification to a network dependent signalling protocol. So I think that the carriers will be (are) building up the features of ATM and B-ISDN including that of AAL service, QOS, signalling, multi party calls, etc. I really do not think that much redesign can be done here outside of the ITU. It will be a question of designing IP6 to fit over ATM/AAL services with the requirements as listed above. Otherwise there will be a "router" view of ATM services and a carrier B-ISDN view of services which are supported by the IN and TMN type interactions. I am curious how far IPng wants to go with this development. Are we including in the IP/ATM work the issues of driving the AAL, meta signalling, F4 and F5 flows, traffic management, etc and Multicast / Group interactions? So there are some serious issues here. Is it possible to scope what bits of the IP/ATM/B-ISDN will be candidates for IP/ATM design, will use elements of the ITU work and; use totally the current recommendations. Regards Alan@Oz So ------------------------------------------------------------------------------ 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 Nov 2 17:29:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14431; Wed, 2 Nov 94 17:29:01 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14424; Wed, 2 Nov 94 17:28:49 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA08307; Wed, 2 Nov 94 17:24:20 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB28450; Wed, 2 Nov 94 17:24:15 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 3 Nov 1994 09:13:26 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 2 Nov 1994 13:26:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 2 Nov 1994 14:25:52 +1000 Date: Wed, 2 Nov 1994 14:25:52 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941102 10:11:48 008] X400-Content-Type: P2-1984 (2) Content-Identifier: 941102 10:11:48 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941102 10:11:48*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> To: ipng (Non Receipt Notification Requested) Subject: (IPng) RE: RE: (IPNG) ATM..MASATAKA'S COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM masataka. your assumption that carriers will use IP6 addressing not E.164. Have you tested this on any carrier? E.164 (and E.163) is used for the Worlds Telephone Network, the ISDN network, the Fastpac (Australian dqdb MAN 802.6) network, the B-ISDN network, etc. It strikes me that as data and voice and video combine (over B-ISDN and ATM) that the signalling scheme used will be that as OWNED by the ITU and carriers. IP4 and IP6 may be offered as access (and routing) services by the carriers, but the bottom line is it will be over the point to point or digital cross connect services (PDH/SDH) or over switched ISDN (nailed up or other wise). I dont think that E.164 will be dropped instead of IP6 addressing simply because of all the equipment and commercial agreements in place between carriers, let alone all the billing systems which relate E.163/4 to customers. AND the ITU have not ratified it. AND the whole of the worlds telecommunications runs on it. (even some of the comments on addressing eg. remapping, dynamic assignment, its only used for routing,etc, etc, seem to miss this minor point about global networking. Just imagine receiving a "worlds telephone directory" every minute because the addressing was dynamic!) So mapping IP4 and IP6 addresses to E.164 and to switched environments is one issue that: can be left to implementors or; has to be dealt with in ARP, resource reservation, discovery, circuit management, etc within the IPng framework. 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 Nov 2 17:29:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14443; Wed, 2 Nov 94 17:29:18 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14432; Wed, 2 Nov 94 17:29:01 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA08325; Wed, 2 Nov 94 17:24:33 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB28450; Wed, 2 Nov 94 17:24:22 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 2 Nov 1994 08:34:49 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 2 Nov 1994 08:38:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 2 Nov 1994 09:37:32 +1000 Date: Wed, 2 Nov 1994 09:37:32 +1000 X400-Originator: ALAN.LLOYD@DCTHQ.datacraft.telememo.au X400-Recipients: ipng X400-Mts-Identifier: [/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/;dcpmel 941102 08:34:38 001] X400-Content-Type: P2-1984 (2) Content-Identifier: 941102 08:34:38 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941102 08:34:38*/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) NOSI BOF - STRONG COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have been away for a few days. Thanks for the support jim. The comments from bill and kre. I will just add that IP4 is an example of the addressing problems that the world has hit, that is why it must be dealt with in IP6. Surely those who disagree with my comments must see what has happened across this planet (and the problems with IP4 addressing) and the impact that will have to upgrade all IP nodes and the Internet. I do not want to see the same mistake again. On a philosophical point, some of the responses about buildings were amusing. (Its good to have a smile sometimes, we all need to occasionally.) Why do people quote historical examples (eg. for random building addressing) and "its ok for the locals"? Global networks are not for the "locals" and today we have town planning. Progress! Learn from history for the future, not cite it to make the same mistake. Any one can design a protocol with an "address field". See any protocol spec. Scale it, administer it, and operate it thats where the engineering really comes in. Traditional as I am, the comments that say implement the protocol and apply the addressing are a worry. Been there, done that! What happens when you find bugs at 1m nodes, 10m nodes and 100m nodes and they relate to addressing, routing, discovery, mobility, security and management? I am not promoting all theory here or kings and votes, but if we can qualify the design and implementations on the basis of scale and administration, I will be happier chap. 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 Nov 2 17:48:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14515; Wed, 2 Nov 94 17:48:26 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14509; Wed, 2 Nov 94 17:48:19 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23015; Wed, 2 Nov 94 17:44:00 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA02578; Wed, 2 Nov 94 17:43:32 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA27070; Wed, 2 Nov 94 09:24:12 -0800 Received: by xirtlu.zk3.dec.com; id AA17147; Wed, 2 Nov 1994 12:23:34 -0500 Message-Id: <9411021723.AA17147@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Wed, 02 Nov 94 03:52:25 CST." <9411020952.AA25076@anubis.network.com> Date: Wed, 02 Nov 94 12:23:28 -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 Fred, >From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) >If you all agree I will start threads on each of these >subjects individually hoping that at least some of them >can be solved. Thanks for doing this I think this is an excellent approach to try and resolve the differences and technical issues quickly. So we can begin prototype development again on IPv6. I am going to begin a clarity review of the discovery specs too, and if I see more bullets I will send that out as a subject bullet. I will label the clarity input as Clarity in the subject line. Thanks for taking the time to figure this out. /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 Nov 2 18:01:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14565; Wed, 2 Nov 94 18:01:27 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14529; Wed, 2 Nov 94 18:00:43 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25053; Wed, 2 Nov 94 17:56:24 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA05222; Wed, 2 Nov 94 17:56:00 PST Subject: Re: (IPng) IPv6 System Discovery: which multicasts To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 1994 14:47:48 -0500 (EST) From: Dan McDonald In-Reply-To: <9411021159.AA25643@anubis.network.com> from "Fred Rabouw (Gouda office)" at Nov 2, 94 05:59:01 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: 943 Message-Id: <9411021947.aa15449@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > When the NETWORK LAYER ADDRESS is a unicast address, > but the LINK LAYER ADDRESS is unknwon we use the > SOLICITED-NODES in the LINK LAYER ADDRESS. Using a SOLICITED-NODES LINK LAYER ADDRESS is good, but what I think people have a problem with is plowing a WHOLE packet PLUS a solicitation to this address. I think many people like the queueing up of packets that ARP does. I'll leave this can of worms to someone else, or maybe, this should be another separate question. > When the NETWORK LAYER ADDRESS is ALL_NODES or > ALL_ROUTERS, I can't find a specification what > LINK LAYER ADDRESS to use It isn't specified, but I've heard from Mr. Multicast himself (Steve Deering) that the IPv4 algorithm of low-23 bits get appended to some IEEE prefix be used in IPv6. We have this implemented in our multicast code already, and it works for what little of multicast we have working so far. (Can you say "all-nodes?") 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 Wed Nov 2 18:01:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14566; Wed, 2 Nov 94 18:01:37 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14535; Wed, 2 Nov 94 18:00:46 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25061; Wed, 2 Nov 94 17:56:27 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB05222; Wed, 2 Nov 94 17:56:15 PST Subject: Re: (IPng) IPv6 System Discovery: routers in solicited-node? To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 1994 14:48:28 -0500 (EST) From: Dan McDonald In-Reply-To: <9411021201.AA25667@anubis.network.com> from "Fred Rabouw (Gouda office)" at Nov 2, 94 06:01:05 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: 177 Message-Id: <9411021948.aa15464@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > My conclusion: A router should listen to the solicited-node > multicast of his own address(es), there is no reason to > listen to the other solicited-node-multicasts. Yes. ------------------------------------------------------------------------------ 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 Nov 2 18:01:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14567; Wed, 2 Nov 94 18:01:46 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14541; Wed, 2 Nov 94 18:00:48 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25067; Wed, 2 Nov 94 17:56:29 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB05222; Wed, 2 Nov 94 17:56:18 PST Subject: Re: (IPng) IPv6 System Discovery: solicited-node To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 1994 14:49:29 -0500 (EST) From: Dan McDonald In-Reply-To: <9411021159.AA25646@anubis.network.com> from "Fred Rabouw (Gouda office)" at Nov 2, 94 05:59:42 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: 689 Message-Id: <9411021949.aa15479@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Of my announced list of six (not seven) subjects: > Number 2: Is the solicited-node group worth the effort? > > Short summary: > One opinion: we use a layer 2 address that is a > so called: base-solicited-node multicast > hashed with IPv6 destination address. > The other opinion: this might not give any useful > granularity and is not worth the effort. > > The proposed algorithm will work in 99.99% of the > networks by saving my end-station for at least half > the multicasts and most likely for much more. Absolutely. Again, what gets sent to this base-solicited-node link layer address, is, IMHO, worthy of further debate. 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 Wed Nov 2 18:01:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14568; Wed, 2 Nov 94 18:01:54 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14547; Wed, 2 Nov 94 18:00:54 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25082; Wed, 2 Nov 94 17:56:35 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB05222; Wed, 2 Nov 94 17:56:21 PST Subject: Re: (IPng) IPv6 System Discovery: MAR and routers? To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 1994 14:50:12 -0500 (EST) From: Dan McDonald In-Reply-To: <9411021201.AA25670@anubis.network.com> from "Fred Rabouw (Gouda office)" at Nov 2, 94 06:01:41 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: 433 Message-Id: <9411021950.aa15494@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > A router will need to use Media Address resolution to find > endnodes. I think we all agree on that. > > Only when a node A doesn't realize another node B is a > router, but he wants to talk to B, router B will have to > answer incoming Media Address resolution. This is in fact > the same situation as: Should a router listen to the > solicited node multicast. There I already suggested it > should. Once again, YES. 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 Wed Nov 2 18:01:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14569; Wed, 2 Nov 94 18:01:58 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14553; Wed, 2 Nov 94 18:00:57 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25085; Wed, 2 Nov 94 17:56:38 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB05222; Wed, 2 Nov 94 17:56:26 PST Subject: Re: (IPng) IPv6 System Discovery: permitted solicitations To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 1994 14:57:58 -0500 (EST) From: Dan McDonald In-Reply-To: <9411021203.AA25682@anubis.network.com> from "Fred Rabouw (Gouda office)" at Nov 2, 94 06:03:38 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: 580 Message-Id: <9411021957.aa15544@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Short overview of 5a: permits vs required router- > solicitations. The facts: > draft-simpson-ipv6-discov-process specifies: a host is > required to send router-solicitations when ..... > RFC1256 specifies: a host is permitted to ..... I believe that it isn't being made clear in IPv6 documents that ROUTER DISCOVERY IS REQUIRED. People keep shouting this, but it isn't clear in many IPv6 draft documents. > The issue is (very hot): Is a host allowed to send out > router sollicitations after the first ten seconds after > starting an interface. No comment for now. 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 Wed Nov 2 18:02:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14570; Wed, 2 Nov 94 18:02:05 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14559; Wed, 2 Nov 94 18:01:01 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25101; Wed, 2 Nov 94 17:56:42 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB05222; Wed, 2 Nov 94 17:56:30 PST Subject: Re: (IPng) IPv6 System Discovery: IPv6 multicast to IEEE To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 1994 15:02:33 -0500 (EST) From: Dan McDonald In-Reply-To: <9411021204.AA25689@anubis.network.com> from "Fred Rabouw (Gouda office)" at Nov 2, 94 06:04:15 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: 1057 Message-Id: <9411022002.aa15562@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Before I continue, this is the last of a series of replies from the IPv6 folks at NRL (Ran, and myself) to Fred's wonderful breakdown of the discussion over the past week or two. > Short summary: > At the moment the IPv6 specifications don't talk about > which IEEE address to use for the multicasts. It was > mentioned not to bother since that should be in a succesor > of RFC1700 Like I said earlier I think using the IPv4 algorithm for right now is the Right Thing to do. > If we map all IPv6 multicasts to a single IEEE multicast, > it puts the lowest burden on the interface card and the > highest burden on the CPU. We don't want to do this. We want to keep the CPU burden relatively light, because the CPU might be some tiny 80{86,186,286} in some embedded box somewhere. (Bill, does this sound familiar? :) Look at the current BSD implementation of IPv4 multicast and see how the mcast->IEEE mcast mapping was done. My IPv6 code does the identical mapping. (Of course, this means the low 23 bits better be spread out pretty well!) 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 Wed Nov 2 18:03:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14607; Wed, 2 Nov 94 18:03:25 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14601; Wed, 2 Nov 94 18:03:16 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25497; Wed, 2 Nov 94 17:58:57 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07202; Wed, 2 Nov 94 12:22:38 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08055; Wed, 2 Nov 94 11:18:37 -0800 Received: by xirtlu.zk3.dec.com; id AA19517; Wed, 2 Nov 1994 14:17:58 -0500 Message-Id: <9411021917.AA19517@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Performance Aggregate Gains in IPv6 (the Big Picture Test) In-Reply-To: Your message of "Wed, 02 Nov 94 10:47:27 EST." <9411021553.AA24150@Sun.COM> Date: Wed, 02 Nov 94 14:17:52 -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 Charlie, >The notion of a "Big Picture Test" raises the following issue. It >seems that a lot of effort went into the design of the IPv6 packet >headers to make sure that all fields were aligned on natural >boundaries. After 64-bit addresses were replaced by 128-bit >addresses, the fields are no longer aligned. I certainly expect >128-bit CPU chips within the design lifetime of IPv6, and they will >most likely suffer performance hits when accessing the now mis-aligned >fields. Will the final IPv6 headers be reworked to realign things? All is aligned on 64bit boundaries or an integer multiple of 8 octets. Are you saying align on 128bit boundaries and use an integer multiple of 16 octets? /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 Nov 2 19:51:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14969; Wed, 2 Nov 94 19:51:36 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14963; Wed, 2 Nov 94 19:51:27 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06702; Wed, 2 Nov 94 19:47:09 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26152; Wed, 2 Nov 94 19:46:51 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27924; Thu, 3 Nov 1994 14:46:41 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) "Host" vs "Router" In-Reply-To: Your message of "Wed, 02 Nov 1994 14:02:37 GMT." <3389.bill.simpson@um.cc.umich.edu> Date: Thu, 03 Nov 1994 14:46:37 +1100 Message-Id: <11880.783834397@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 94 14:02:37 GMT From: "William Allen Simpson" Message-ID: <3389.bill.simpson@um.cc.umich.edu> 1) A node cannot be both a host and a router, according to the IPv6 definitions. That's fine, they can certainly be defined that way, and there may be merit in doing exactly that. Right now I'm not sure what it is, but never mind. However, with that definition, you're going to have to use the words "a router or host" almost everwhere you would have preferred to just say "a host" - either than or almost always use an all encompassing term like "a node" instead of "a host" as there's almost nothing I can even imagine that a host (your definition) would ever do that a router wouldn't also have to do. You certainly cannot rely on all hosts (or routers) knowing the MAC addresses of all the routers, and not having to go through some kind of solicitation to discover them, no matter what procedures the routers are supposed to follow to make their MAC addresses known. Routers do everything that hosts do at the network level and below, which is what is of concern here (at application level, of course not, they typically have no mailers, etc...). They do more, which is what makes them special, they certainly don't do less. 2) How can the words "A router" apply to more than one computer? I don't think this is a very serious topic, but this is all going to depend on your precise definition of "computer" and "router" surely? If I define "computer" as something with a processor, memory, and which is capable of running stand alone (ie: not just one cpu of a multi-cpu box necessarily), and a "router" as an entity that implements the requirements of (some future edition of) router requirements, then I could certainly imagine many computers acting together to implement one router (perhaps something just like existed on the previous NSFnet). Of course, you could alter the definition of "computer" beyond normal interpretations, and say that any group of processors that are acting together for a common purpose is "a computer", in which case my workstation, my mail hub, several machines at Sun, and your systems would all be "a computer" as they're all acting together to deliver this message. Personally that seems a little far fetched to me. But as I said - not a serious topic. 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 Wed Nov 2 23:23:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15172; Wed, 2 Nov 94 23:23:24 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15166; Wed, 2 Nov 94 23:23:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA19854; Wed, 2 Nov 94 23:18:58 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA24674; Wed, 2 Nov 94 23:18:41 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05391; Thu, 3 Nov 1994 17:44:14 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 System Discovery: solicited-node In-Reply-To: Your message of "Wed, 02 Nov 1994 13:00:19 CDT." <9411021800.AA18590@xirtlu.zk3.dec.com> Date: Thu, 03 Nov 1994 17:44:11 +1100 Message-Id: <11929.783845051@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 02 Nov 94 13:00:19 -0500 From: bound@zk3.dec.com Message-ID: <9411021800.AA18590@xirtlu.zk3.dec.com> I believe that more than 50 nodes on a LAN will be common. I think this is going to depend on the type of LAN, and the costs of interconnecting with routers. Personally on an ethernet I think 32 is too many (bridges or not). (Its too many for FDDI too, but that's just because FDDI interfaces still cost too much to afford that many...) From my work in engineering I have often seen cases where customers in IPv4 wanted to support multiple addresses on one interface. I have seen that too - but I think that looking at this at surface level is not productive. No-one I'm aware of has seriously wanted two addresses just because its sexy to have more than one. There's always some other problem they're trying to solve, and two addresses seems to be the way to the solution. With IPv4 it often is - we need to look at the problems being solved and see if perhaps IPv6 won't offer a better method (or even just a different method). As I recall it (what little I know) DECNET doesn't allow multiple addresses for a node, let alone an interface, and that doesn't seem to be an insurmountable problem. Nor does it seem to be on appletalk which allows only one address per interface. Perhaps the desire for this in v4 is purely the result of other problems - like limited support for variable width subnets, and difficulties renumbering hosts, etc, and that if v6 solves those problems, which it certainly should (it had better), then multiple IPv6 addresses per interface won't be an issue at all. kre ps: I am still looking for (even a hint of) an available v6 implementation for some class of PC unix (one of the ones for which kernel sources are easy to get: bsdi, netbsd, freebsd, etc). No-one at all replied to my last request - if you didn't because you thought someone else would be sure to, then please reply (to just me, not the list) this time... Its very hard to believe there is nothing. I'm not looking for anything complete, perfect, or even necessarily working... Thanks. ------------------------------------------------------------------------------ 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 Nov 3 01:14:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15229; Thu, 3 Nov 94 01:14:11 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15223; Thu, 3 Nov 94 01:14:04 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24094; Thu, 3 Nov 94 01:09:45 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA05704; Thu, 3 Nov 94 01:09:33 PST Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA12669; Thu, 3 Nov 1994 04:09:31 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA06734; Thu, 3 Nov 1994 04:09:29 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA20271; Thu, 3 Nov 1994 03:45:59 -0500 Message-Id: <9411030845.AA20271@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) ALL-XXX-MULTICAST Interpretation for IPv6 System Discovery In-Reply-To: Your message of "Tue, 01 Nov 94 16:14:02 GMT." <3382.bill.simpson@um.cc.umich.edu> Date: Thu, 03 Nov 94 03:45:59 -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" > >There is a hole in the specification, in that a host that may have a skewe ***d > >timer, may timeout a router entry in its routers list before the router > >re-advertizes routing information about itself. > > When the host and router are working well, the timing-out should never happ ***en, when > one of them times-out to fast (incorrectly), they might loose eachother. > Actually, Conta hadn't noticed that the lifetime is not the same rate as the advertisements. By default, the LifeTime is three (3) times as long as the maximum advertisement interval. (Processing p 10) For the sake of accuracy, actually I did. But the specs say (Processing p 12 in the draft I look which is from October 1994) that "Must be [AdvertismentLifetime] no less than MaxAdvertismentInterval" which implies that AdvertismentLifetime = MaxAdvertismentInterval is a valid value, which one can set. So, the host would have missed 3 adverts, and also timed out too soon! A host that is missing 3 packets is either a very bad implementation or on a very bad link. In light of what I just said, the above is true only in "only timed out to soon", which is the point I was making. Recomendation: Change Processing p 12 from: "Must be no less than MaxAdvertismentInterval" to: "Must be greater than MaxAdvertismentInterval + MinAdvertismentInterval" > >> Only hosts join solicited-node. > > Then why is 'solicited-node' and not 'solicited-hosts', if it is only a h ***osts > > group? And if only hosts join the group, you still didn't resolve the ho ***le > > in your specifications related to accessing a router's host functions, > > which I previously pointed out. > (To Conta) There is no "hole". You always examine the router list first. This is already extensively described in "Next Hop Decision", paragraphs (c) and (d). Since you match the router, and already have a media address entry for the router (obtained from the router advert), there is never any reason to solicit the router for host functions. Also, Processing page 4 reads: Although the Hop Cache, the lists of default routers, and a table of static routes are described as conceptually distinct, in practice they may be combined into a single "routing table" data structure. So, in practice, you can even keep the routers and specific destinations in the same list. I don't know how to make it simpler. (And this note is directly from RFC-1122 p 51, so it should have been in your implementation already!) It seems that mostly you object to the NAME! Could it be that you have had this misunderstanding all along? Changing the name is pretty easy, and I would be happy to do that if it engenders understanding. To Simpson: 3(+2) paragraphs above make the point, yours, and in fact mine as well. I would love to be able to say that changing the name would be sufficient, but it is not the case. Recommending a text would be very difficult - there are too many pages involved, and need more time. My general recommendation consists in: - rewrite the text - forget about RFC 1122, and its formatting, this way you may find a better way to link the ideas, and also make them clearer - RFC1620 is such a good instance of clarity. There are other specs, in IPv6 as well, that can be cited for clarity. - when you rewrite the text, put yourself in place of the first time reader. - use consistently the same minimal set of names throughout the spec. > But please Bill let's not be > to rude in discussing this. > Fred, you haven't begun to see rudeness on my part. I have said "PLEASE", I have begged, I have pleaded. I'm tired of it. I wish that everyone would be as careful in reading the drafts as you have been (even when we disagree). To Simpson: The assumption made that the documents are fine, and the reader is the problem, which is often made is not constructive at all. The discovery specs are far from perfection. And this round is not the last one! A very positive example of how a document can evolve when the editor is inventive, but also receptive, and collaborative to all flavors of criticisms, and to many people, is Bob Gilligan's transition document. Being tired is not an excuse, but it is in fact a matter of choice. In my opinion anyways... 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 Thu Nov 3 01:36:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15241; Thu, 3 Nov 94 01:36:37 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15235; Thu, 3 Nov 94 01:36:30 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24623; Thu, 3 Nov 94 01:32:11 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA06996; Thu, 3 Nov 94 01:31:55 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11568; Thu, 3 Nov 1994 20:31:49 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? In-Reply-To: Your message of "Wed, 02 Nov 1994 14:37:16 GMT." <3393.bill.simpson@um.cc.umich.edu> Date: Thu, 03 Nov 1994 20:31:44 +1100 Message-Id: <11950.783855104@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 94 14:37:16 GMT From: "William Allen Simpson" Message-ID: <3393.bill.simpson@um.cc.umich.edu> Another problem is that if a router gets the datagram, it will discover that it is not destined for itself, and a broken implementation would forward a duplicate to the host, wasting bandwidth. Of course, a broken multicast implementation might intercept multicast packets for groups it had not joined, resulting in the same problem. Both problems are completely solved by the simple IP requirement that datagrams may be duplicated. "Solved" is the wrong word there - you mean we can ignore the problem because of this attribute (not requirement). However, if someone has a Brian Carpenter type net, with 8000 nodes connected, and a few hundred of them happen to be routers that decide they should forward the packet, I doubt anyone would be happy to be told "ignore the packet burst, its just IP behaving normally" ... > In order to reach to that router it should react > as a normal host on the solicited-node multicast. > No. Only when routing is turned off for that interface. I don't think this can possibly work. Consider a case where my host wants to send a packet to another host, which it knows is on the local cable, but doesn't know its MAC address (first packet ever sent there). It has been receiving router advertisments, knows its default router, and has also remembered a backup. The reason my host is sending this packet is because I have done "ping foo", or "telnet foo". Are you telling me that my host is supposed to know whether or not "foo" happens to be a router (from which it had previously ignored router advertisments perhaps as being of too low preference to matter), and act differently than if "foo" is any other host? Pull the other leg. But, if the node doesn't have enough storage for the routers, where is it going to store the next hop? It's probably the same table. I have built IP implementations where the host has space for exactly 1 remote IP address/MAC address combination at a time. This thing does exactly one thing at a time, and finishes what it is doing before going on to the next step. That is, it starts by acquiring its own address, etc. When it needs to communicate, if the destination is not local, it looks for a router, and remembers the router & its MAC address, and then all further packets go that path. If it later wants to communicate on the local cable, it will discard all knowledge of its default router, and instead ARP (this is V4 of course) for the destination MAC address, and remember that - all packets go there for the duraction of this activity. Later the (or rather, a) router may be acquired again for some other activity. Don't imagine everything is a workstation with megabytes to waste on storing network overhead data - there are plenty of applications using embedded processors (and no external RAM at all) where every available bit is precious. They aren't going away. 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 Nov 3 01:59:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15260; Thu, 3 Nov 94 01:59:22 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15254; Thu, 3 Nov 94 01:59:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25154; Thu, 3 Nov 94 01:54:57 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA08315; Thu, 3 Nov 94 01:54:43 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPv6 System Discovery: IPv6 multicast to IEEE To: ipng@sunroof.Eng.Sun.COM Date: Thu, 3 Nov 1994 09:55:42 +0100 (GMT) In-Reply-To: <9411022002.aa15562@sundance.itd.nrl.navy.mil> from "Dan McDonald" at Nov 2, 94 03:02:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 959 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > If we map all IPv6 multicasts to a single IEEE multicast, > > it puts the lowest burden on the interface card and the > > highest burden on the CPU. > > We don't want to do this. We want to keep the CPU burden relatively light, > because the CPU might be some tiny 80{86,186,286} in some embedded box > somewhere. (Bill, does this sound familiar? :) I pointed out a while back that this is all irrelevant. The fact you can't guarantee your little 8086 won't happen to be hashed into the same multicast MAC as a multicast TV station means you cannot deploy any such multicasts even on the same network as such hosts. Without a clear planning of MAC and IP multicasts so you are guarateed to get a seperate group area for high bandwidth multicast service delivery as opposed to administration and low bandwidth multicasts; IP v6 for small machines on fast networks will be a problem. And as the networks get faster the problem will get bigger. 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 Nov 3 02:00:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15282; Thu, 3 Nov 94 02:00:28 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15276; Thu, 3 Nov 94 02:00:21 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25221; Thu, 3 Nov 94 01:56:02 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA08428; Thu, 3 Nov 94 01:55:48 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12113; Thu, 3 Nov 1994 20:55:22 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) permitted solicitations In-Reply-To: Your message of "Wed, 02 Nov 1994 15:13:19 GMT." <3395.bill.simpson@um.cc.umich.edu> Date: Thu, 03 Nov 1994 20:54:36 +1100 Message-Id: <11955.783856476@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 2 Nov 94 15:13:19 GMT From: "William Allen Simpson" Message-ID: <3395.bill.simpson@um.cc.umich.edu> This is not allowed in RFC-1256, ... Is the same in IPv6, ... It is explicitly forbidden in the words (RFC-1256 page 3): The same language is used in IPv6. In another message, a while ago now, you also used words something like such an implementation would not be conformant Frankly, all of that I doubt is of any benefit. Implementors will obey the rules only when they are required in order to make the implementation work. Its that way for v4, I can't think of a reason its going to change in v6. If I'm implementing v6 (especially commercially) and I perceive (even wrongly) that if I do X, my product is going to be somehow better in some sense (performance, user friendliness, ...) than you can guarantee I'm going to simply ignore the rules and do what I think works better. That's the situation now, its not about to change. The only way that this can be avoided is to explain quite precisely exactly why following the rules is going to give the best result - not for the "net as a whole" nor for some other node, but for my particular implementation. Obviously that implies that the rules have to actually posess that property. 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 Nov 3 02:17:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15352; Thu, 3 Nov 94 02:17:26 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15336; Thu, 3 Nov 94 02:08:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25553; Thu, 3 Nov 94 02:03:56 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA09133; Thu, 3 Nov 94 02:03:43 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) replacement for gethostbyname() To: ipng@sunroof.Eng.Sun.COM Date: Thu, 3 Nov 1994 10:04:45 +0100 (GMT) In-Reply-To: <199411022146.NAA09011@aland.bbn.com> from "Craig Partridge" at Nov 2, 94 01:46:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 636 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The term getconninfo() suggests this gets connection information, > in which case it would be irrelevant to connectionless protocols like > UDP. Why not call it getservinfo()? This would be better, as for many protocols you do query specifically for services (eg IPX SAP). > Finally, and this is just my preference, I'd much prefer the > interface to look like this: > > struct sockaddr *getconninfo(char *host, char *service, > int cf, int socktype, int proto, int flags, int *namelen, char *cname) So long as you keep the freeconninfo() function - otherwise you can't use it sensibly in a threaded library. 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 Nov 3 03:13:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15447; Thu, 3 Nov 94 03:13:10 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15441; Thu, 3 Nov 94 03:13:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27464; Thu, 3 Nov 94 03:08:44 PST Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA16800; Thu, 3 Nov 94 03:08:30 PST Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA15234; Thu, 3 Nov 1994 12:10:29 +0100 Message-Id: <199411031110.AA15234@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? In-Reply-To: Your message of "Thu, 03 Nov 1994 20:31:44 +1100." <11950.783855104@munnari.OZ.AU> Date: Thu, 03 Nov 1994 12:10:28 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "However, if someone has a Brian Carpenter type net, with 8000 nodes connected, and a few hundred of them happen to be routers that decide they should forward the packet, I doubt anyone would be happy to be told "ignore the packet burst, its just IP behaving normally" ... Yup. I believe that this is the big problem with making ARP and initial transmission simultaneous. As long as the address is not "resolved" (i.e. not cached), there are a few solutions which work: 1) Send packet to the "preferred router" (obtained through router discovery), get a redirect if you missed the target. Pro: stateless in the hosts (no need to queue and resubmit) no duplication or multiple deliveries single action in routers Con: router overload (maybe) double hop for local packets dependency on router (black hole effect) That solution has some merit, and in fact nothing prevents an host from implementing it. But it is not a complete solution: routers still have to discover the next hop. 2) Send packet to some mcast address, e.g. "all hosts", "all sollicited hosts" or maybe "all hosts whose addresses end by the 23 bits XXXXXX". Protect against duplicate delivery by setting the hop count to 1, so that routers will not relay the packet. Pro: stateless in the hosts (no need to queue and resubmit) single transmission on local net Con: mcast transmission "wakes up" many more hosts than necessary mcast transmission reaches all routers routers may well send "hop count exceeded" ICMP potential "black hole" effect - no ICMP or ARP feedback. This solution is a natural complement to the previous one, typically a fall back case in the absence of router on the net. It should not be employed when one router has been discovered, due to the ICMP problem. As such, it is not a good solution for the "router to host" problem. 3) Queue the packet, sends "solicitation" to the "all hosts", "all sollicited hosts" or maybe "all hosts whose addresses end by the 23 bits XXXXXX". If a response is obtained, transmit the packet; else, re-solicit until fed-up or declare the host unreachable. Pro: no risk of packet duplication, no risk of ICMP storms, allows recycling of all the ARP know-how (proxy ARP, etc) (Is this really a pro?) Con: stateful (need to queue the packet) mcast transmission "wakes up" many more hosts than necessary mcast transmission reaches all routers need to send three packets (where-are-you, I-am-here, take-this) requires knowledge of the topology (dest is normally on this subnet) This is probably the only safe option for routers. Once it is defined for routers, nothing prevents hosts from using it, either as the "isolation" fall back (in absence of router) or as the first alternative (if they have a sufficient knowledge of the topology). There is in fact a 4th solution, the plain ES-IS model where routers discover who is on the cable through unsolicited hosts' annoucements. But I thing we ruled that out. To allow the 3 possibilities mentioned above, we need to: 1) mandate router discovery (done). 2) mandate default hash (being done, if I understand correctly). mandate that no host use that trick if a router has been discovered. 3) define ICMP "solicit" (being done, if I understand correctly). Isn't it the case that we are pretty near from converging? 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 Thu Nov 3 03:17:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15461; Thu, 3 Nov 94 03:17:28 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15455; Thu, 3 Nov 94 03:17:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27573; Thu, 3 Nov 94 03:12:56 PST Received: from ncc.ripe.net by Sun.COM (sun-barr.Sun.COM) id AA17150; Thu, 3 Nov 94 03:12:44 PST Received: from belegen.ripe.net by ncc.ripe.net with SMTP id AA05114 (5.65a/NCC-2.9); Thu, 3 Nov 1994 12:12:36 +0100 Received: from localhost.ripe.net by belegen.ripe.net with SMTP id AA05402 (5.65a/NCC-2.2); Thu, 3 Nov 1994 12:12:35 +0100 Message-Id: <9411031112.AA05402@belegen.ripe.net> To: ipng@sunroof.Eng.Sun.COM From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: (IPng) IPv6 System Discovery: IPv6 multicast to IEEE In-Reply-To: Your message of "Thu, 03 Nov 1994 09:55:42 MET." Date: Thu, 03 Nov 1994 12:12:35 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Thu, 3 Nov 1994 09:55:42 +0100 (GMT) Alan Cox wrote: > > > If we map all IPv6 multicasts to a single IEEE multicast, > > > it puts the lowest burden on the interface card and the > > > highest burden on the CPU. > > > > We don't want to do this. We want to keep the CPU burden relatively light, > > because the CPU might be some tiny 80{86,186,286} in some embedded box > > somewhere. (Bill, does this sound familiar? :) > > I pointed out a while back that this is all irrelevant. The fact you can't > guarantee your little 8086 won't happen to be hashed into the same multicast > MAC as a multicast TV station means you cannot deploy any such multicasts > even on the same network as such hosts. Without a clear planning of MAC > and IP multicasts so you are guarateed to get a seperate group area for > high bandwidth multicast service delivery as opposed to administration and > low bandwidth multicasts; IP v6 for small machines on fast networks will > be a problem. And as the networks get faster the problem will get bigger. And worse, there is lots of ethernet hardware out there that cannot handle intensive usage of multicast properly. I know of at least two 'printerport' pocket adapters which can only enable/disable multicast traffic as a whole, i.e. not per address. These devices can only handle a limited amount of traffic because of bandwith limitation on the pronterport, making multicast unusable on high-load networks (i.e. only usable for multicast rwho or something like that). In practice, that means that these devices are usually used without multicast enabled. Will they still be usable with IPv6? Another ethernet chip, 8390, which is used often (this chip and its deratives are used in the vast majority of PC ethernet cards), uses the ethernet CRC generator of the receiver to hash the multicast address into 64 slots. This chip can only enable/disable multicast reception for each of these slots, not for each mulcast address. As alan wrote, we are doomed if a high-bandwith mulcast transmission happens to clash with router info or something else which is *required* to an IPv6 host to receive, and this is hard to predict. Broadcast has the advantage that its drawbacks are well understood, i.e. keep broadcast traffic per net *very* low or the whole net will suffer. Historically this has kept bandwith requirements for broadcast addresses low. If IPv6 is going to require boxes to receive multicast, then a minimal functionality set must be available for boxes that cannot do mulcast properly. Geert Jan ------------------------------------------------------------------------------ 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 Nov 3 03:48:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15490; Thu, 3 Nov 94 03:48:49 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15484; Thu, 3 Nov 94 03:48:41 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28061; Thu, 3 Nov 94 03:44:22 PST Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA18878; Thu, 3 Nov 94 03:44:04 PST Received: by rodan.UU.NET id QQxokk12084; Thu, 3 Nov 1994 06:44:04 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) first data on ARP Date: Thu, 03 Nov 1994 06:44:03 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This whole discussion of "first data with ARP" has me feeling very queasy. I will assert my philosophical point of view and why I think this conversation is COMPLETELY out of scope for the IP6 discussion at hand. And of course, everyone will pay it as much mind as it deserves (grin!). (1) ARP is a cache-miss resolution protocol for a virtual address translation. IP4 (and I continue to hope IP6) addresses are virtual addresses which must be translated into physical next-hops. If a sending station does not have the needed translation in its cache, a translation fault occurs and ARP is used to fill the cache with the missing data. (2) ARP is part of the ENCAPSULATION for specific types of links because it is not the only cache-miss resolution protocol which could be used. It is, however, part of the Ethernet and FDDI encapsulations for IP4 datagrams. Therefore, to discuss sending "first data with ARP" is to open the box of how IP6 is to be encapsulated on various kinds of media and has NOTHING to do with IP6, per se. Because of this, I strongly believe this discussion is OUT OF SCOPE for now. With the IP4 encapsulations so well-understood, I do not understand why we are wasting cycles tinkering with encapsulations when so much work remains on getting IP6 tidied up. If someone can show how there is a fundamental failure in the encapsulation of IP4 which will prevent it's effective re-use with IP6, rather than what would appear to be a failure to optimize, then there are clear grounds for examining the encapsulation. But so far, I have seen no compelling evidence this is a problem which needs to be broken right now. There are lots of pretty colored strings in the carpet - we don't have to pull on every one of them. -Mike O'Dell Resident Crank ------------------------------------------------------------------------------ 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 Nov 3 04:03:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15502; Thu, 3 Nov 94 04:03:06 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15496; Thu, 3 Nov 94 04:02:59 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28330; Thu, 3 Nov 94 03:58:40 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA19630; Thu, 3 Nov 94 03:58:28 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04303; Thu, 3 Nov 94 06:00:58 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23731; Thu, 3 Nov 94 05:58:09 CST Date: Thu, 3 Nov 94 05:58:09 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031158.AA23731@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: IPv6 multicast to IEEE Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 multicast to IEEE >>>> Bill Simpson replying to Fred Rabouw > map all IPv6 multicasts for endnodes to a single IEEE > address to save their interface cards. That would result in > the average endnode having to listen to two IEEE- > multicasts: > his hashed-solicited-node multicast (layer 2 multicast, > layer 3 singlecast) > and the endnodes-multicast (one layer 2 address serving > many layer 3 multicasts). This is not a discovery issue. It rather destroys the whole purpose of getting the 23-bit IEEE block for IP multicast. We WANT many addresses on the interface. You're right, it's not a discovery issue. But be careful with demanding many addresses per interface, I wonder how many cheap Ethernet cards and cheap PCs or MACs can effectively handle many addresses. Don't forget that the largest amount of nodes in this world and people don't like to upgrade hardware. ------------------------------------------------------------------------------ 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 Nov 3 04:04:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15514; Thu, 3 Nov 94 04:04:09 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15508; Thu, 3 Nov 94 04:04:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28382; Thu, 3 Nov 94 03:59:43 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA19722; Thu, 3 Nov 94 03:59:30 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) first data on ARP To: ipng@sunroof.Eng.Sun.COM Date: Thu, 3 Nov 1994 12:00:31 +0100 (GMT) In-Reply-To: from "Mike O'Dell" at Nov 3, 94 06:44:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 628 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Because of this, I strongly believe this discussion is OUT OF SCOPE > for now. With the IP4 encapsulations so well-understood, I do not > understand why we are wasting cycles tinkering with encapsulations > when so much work remains on getting IP6 tidied up. Seconded. In fact it would be much more appropriate for a different group of people to try this with IPv4 and show it works then submit it. There seem to be enough vocal people on here to do that ;) > There are lots of pretty colored strings in the carpet - we don't have > to pull on every one of them. The trouble is its fun - until the carpet unravels. 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 Nov 3 04:04:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15521; Thu, 3 Nov 94 04:04:24 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15515; Thu, 3 Nov 94 04:04:11 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28393; Thu, 3 Nov 94 03:59:52 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AB19728; Thu, 3 Nov 94 03:59:34 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04308; Thu, 3 Nov 94 06:02:04 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23743; Thu, 3 Nov 94 05:59:08 CST Date: Thu, 3 Nov 94 05:59:08 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031159.AA23743@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@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 Thu Nov 3 04:05:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15538; Thu, 3 Nov 94 04:05:42 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15532; Thu, 3 Nov 94 04:05:34 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28479; Thu, 3 Nov 94 04:01:14 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA19913; Thu, 3 Nov 94 04:01:02 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04319; Thu, 3 Nov 94 06:03:32 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23765; Thu, 3 Nov 94 06:00:43 CST Date: Thu, 3 Nov 94 06:00:43 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031200.AA23765@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: what solicitations are permitted? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: RE: (IPng) permitted solicitations To Bill Simpson, Bill thanks for your long reply on this issue. Sorry for not copying the your message in my reply and discussing all the details. i will only do a summarize: >> (5a) permits vs requires router-solicitation >> when host boots >Yes. Support for Router Discovery is not required in IPv4, and _is_ >required for IPv6. So, this is not an issue. So we agree >> (5b) host might do router-solicitation when >> router entry times out >This is not allowed in RFC-1256, which specifically allows only certain >circumstances in which a solicitation is sent. I should not have talked about with RFC on 5b, only at 5e, I apologize. >> (5e) system management sets PerformRouterDisc >Since Neighbor Discovery is required in IPv6, this parameter no longer >exists. (It was never put in the IF-MIB anyway.) Again we agree. After reading also Jim's answer I finally realize that the dsicussion between the two of you was not on details of your drafts. The situation as I see it now is, Jim (and Alex(?)) would like to see a complete different draftw with major changes from your paper. Don't expect me to be the judge that can convince all of you. I'm willing to write some proposal in between Bills drafts and what I guess Jim wants, but it might be to close to Bills drafts. ------------------------------------------------------------------------------ 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 Nov 3 04:08:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15581; Thu, 3 Nov 94 04:08:00 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15575; Thu, 3 Nov 94 04:07:53 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28645; Thu, 3 Nov 94 04:03:35 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA20143; Thu, 3 Nov 94 04:03:22 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04338; Thu, 3 Nov 94 06:05:44 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23798; Thu, 3 Nov 94 06:02:54 CST Date: Thu, 3 Nov 94 06:02:54 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031202.AA23798@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: which multicasts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From Fred Rabouw answerinf a mail from Dan McDonald Subject: which multicasts From: Dan McDonald >> When the NETWORK LAYER ADDRESS is a unicast address, >> but the LINK LAYER ADDRESS is unknwon we use the >> SOLICITED-NODES in the LINK LAYER ADDRESS. Using a SOLICITED-NODES LINK LAYER ADDRESS is good, but what I think people have a problem with is plowing a WHOLE packet PLUS a solicitation to this address. I think many people like the queueing up of packets that ARP does. I'll leave this can of worms to someone else, or maybe, this should be another separate question. So the discussion is: should we queue up packets and send one multicast? or can we send two multicasts? Since this solicited-nodes-multicast is going to only 1/256 of the IPv6 nodes, I still like the idea of sending it directly instead of queueing up packets. I now start seeing Jim Bounds point of scaling up (Sorry Jim, I didn't get it before), but we indeed have twice as much multicasts as when we queue. On the other hand the queueing doesn't scale well in the memory. ......... It comes back to the discussion on how big do we expect subnets to be? How often will we time out a node? Thanks for all the other "yes"-es in other messages. ------------------------------------------------------------------------------ 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 Nov 3 04:09:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15597; Thu, 3 Nov 94 04:09:15 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15591; Thu, 3 Nov 94 04:09:08 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28721; Thu, 3 Nov 94 04:04:49 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA20319; Thu, 3 Nov 94 04:04:35 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04349; Thu, 3 Nov 94 06:07:05 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23821; Thu, 3 Nov 94 06:04:10 CST Date: Thu, 3 Nov 94 06:04:10 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031204.AA23821@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: which multicasts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: which multicasts >>>> Jim Bound replying to Fred Rabouw > The second question is: Is this all we need for the > neighbor discovery? (apart from IEEE address for last > point) I can't say yes or no yet. I believe solicited-nodes is very efficient. But will solicited-nodes scale for all cases of IPv6 addresses? I am also unclear when I would use ALL-NODES-MULTICAST vs SOLICITED-NODES-MULTICAST? Do we need both? So I can't answer yes or no without some focused discussion on this thread. I see the ALL-NODES-MULTICAST as a layer three multicast, while the SOLLICITED- NODES-MULTICAST is a layer two multicast. When we try to solve the layer two address of a known IPv6 address, we never need the layer three multicast (since we know the layer three address), so we don't use the ALL-NODE-MULTICAST. The only needed multicast is the SOLICITED-NODES-MULTICAST. Whether it scales well for all cases? I can only see that SOLICITED-NODES- MULTICAST will scale much better than a multicast send to all IPv6 nodes, but no one can predict howmany nodes per subnet will be normal/average/minimum/maximum in the year 2010 nore what the processor power to handle multicast will be. On the other hand for address resolution we only need ONE of these SOLICITED-NODES- MULTICASTs and only 1/256 of the nodes will look at it. When we would send to all nodes than 256/256 of the nodes will look at that. That can never scale better. ------------------------------------------------------------------------------ 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 Nov 3 04:10:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15609; Thu, 3 Nov 94 04:10:37 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15603; Thu, 3 Nov 94 04:10:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28796; Thu, 3 Nov 94 04:06:10 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA20447; Thu, 3 Nov 94 04:05:56 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04359; Thu, 3 Nov 94 06:08:26 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23832; Thu, 3 Nov 94 06:05:37 CST Date: Thu, 3 Nov 94 06:05:37 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031205.AA23832@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: what solicitations are permitted? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: IPv6 System Discovery: host looses another hosts entry >>>>>> Jim Bound replying to Fred Rabouw >Situation: What if a host X talks to another host Y and the >entry on X for Y times out. >My comment: It has nothing to do with router discovery. The >draft-simpson-ipv6-discov-process document specifies what >to do: >The entry is lost, the next frame to Y is send to a known >......... >end to Y to ask for its Media Address, resulting in later >frames send to the Y's correct IEEE address again. >No data is lost, no sessions are influenced. The only >effect are two or more IEEE multicasts on the LAN. This should be orthogonal to multicast solicitation type and it confuses the discussion. Bill proposes data packet > request packet > reply packet. Alex proposes data-request-packet > reply packet in the case where the ......... I [Jim] think Alex's proposal is the correct approach for IPv6 discovery. I [Fred] agree that a combination of data + request would save a packet on the LAN. On the other hand I know exactly how Bill's proposal works (see draft documents), so I can judge on it. Is there any place to get a document on Alex's proposal in this? ------------------------------------------------------------------------------ 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 Nov 3 04:11:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15621; Thu, 3 Nov 94 04:11:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15615; Thu, 3 Nov 94 04:11:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28870; Thu, 3 Nov 94 04:07:18 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA20618; Thu, 3 Nov 94 04:06:56 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04379; Thu, 3 Nov 94 06:09:26 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23846; Thu, 3 Nov 94 06:06:31 CST Date: Thu, 3 Nov 94 06:06:31 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031206.AA23846@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: solicited-node group? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Is the solicited-node group worth the effort? >>>> Jim Bound replying to Fred Rabouw I believe that more than 50 nodes on a LAN will be common. >The proposed algorithm will work in 99.99% of the >networks by saving my end-station for at least half >the multicasts and most likely for much more. We should not build into the link layer in IPv6 a dependency that a LAN will become less efficient as it grows in number of nodes. We need to be more flexible in the IPv6 architecture. But what other discovery mechanism do we have that will not become less efficient when the number of nodes grow? So I do not support solicited-nodes multicast strategy in the discovery specifications. When looking at IPv4, IPX, AppleTalk, SNA, DECnet, OSI, there are basiclly three ways to do layer 3 to layer 2 resolution: (1) Use broadcast/multicasts to find a layer 2 address. That might not scale perfectly, but when multicasts are used sparsely it can scale to hundreds of nodes per subnet. I think that what we do in IPv6. (2) preconfigure every address as SNA is doing. That is exactly what no one likes of SNA and why IBM tries to do things as APPN. (3) have a arithemtic conversion, such as DECnet IV (or in fact IPX). Which is too cramped and gives major problems when one considers multiple addresses per interface. What other stategy do we have? I suggest we clearly state when and why all-hosts, all-routers, and all-nodes are used for IPv6 in the specifications. Everyone will agree that a specification on the use is needed, but none of the three are used in neighbor discovery as defined by Bill Simpson in his draft documents. >I do not yet see the issue. For IPv6: 1. Multiple subnets can exist on a link, but cannot span multiple links. 2. An interface can support more than one IPv6 address. I know IPv6 allows many addresses per interface (so does in fact IPv4), but I can't see a reason why my Powerbook, on which IP is only used to telnet and ftp to a single SUN station, should ever have more than one IPv6 address. I believe that this is truth for 9 out of each 10 client stations. ------------------------------------------------------------------------------ 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 Nov 3 04:12:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15633; Thu, 3 Nov 94 04:12:50 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15627; Thu, 3 Nov 94 04:12:42 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28936; Thu, 3 Nov 94 04:08:23 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA20758; Thu, 3 Nov 94 04:08:03 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04383; Thu, 3 Nov 94 06:10:27 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23853; Thu, 3 Nov 94 06:07:37 CST Date: Thu, 3 Nov 94 06:07:37 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031207.AA23853@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: solicited-node group? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) solicited-node >>>> Bill Simpson replying to Fred Rabouw > One a LAN with less than (let's say) 50 IPv6 nodes I > really don't care about being selective with the IPv6 > multicasts. I care. On a mobile net, those nodes may be sleeping. We don't want to wake them with packets for other nodes. Saves power. Very important! I indeed forgat about portables and so, but my point was: Alex Conta in an earlier message gave an example of a few nodes with careful choisen addresses which all map to the same IEEE multicast. I tried to express that in real life that might sometimes happen with a small LAN, but only very seldomly and I didn't want to care about that seldom ocassion. Normally even on a small LAN there will already be a spreading over the differened IEEE multicasts. ------------------------------------------------------------------------------ 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 Nov 3 04:13:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15645; Thu, 3 Nov 94 04:13:46 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15639; Thu, 3 Nov 94 04:13:39 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28997; Thu, 3 Nov 94 04:09:20 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA20864; Thu, 3 Nov 94 04:08:59 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04392; Thu, 3 Nov 94 06:11:26 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23865; Thu, 3 Nov 94 06:08:36 CST Date: Thu, 3 Nov 94 06:08:36 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031208.AA23865@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: routers in solicited-node? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: IPv6 System Discovery: routers in solicited-node? >>>>>> Jim Bound replying to Fred Rabouw >Short summary: >One opinion: for network management, a router is a > normal host, so it should act as a normal > host. That means it should listen to the > solicited-node multicast. >The other opinion: routers should ignore the (layer 2) > solicited-node multicast. Since a > router sends router-advertisements, > its Media Address is known already. Fred - Point of discussion order. In my last mail I stated that based on your mail I do not think solicited-nodes should be used. Here you assume it has been agreed to in the summary. I will do my best to make it clear what my issues are here without assuming solicited-node. Do we have to fix this point of discussion order to come to resolution? thanks Sorry, I send all those seven E-mails of yesterday without reading responses in between. At this moment I realize you don't want the solicited-node-multicast, when I wrote that E-mail I did not yet realize that. I skip your Multicast Solicitation #1, since you yourself prefer number 2. Multicast Solicitation Scenerio #2 Should a host use all-routers multicast when sending a solicitation to a router. This implies that the host will keep the state necessary in its implementation that if it cannot find a media address for the node it can determine if the destination node on the LAN is a router or host. The benefit here is that the hosts are not bothered by an all-router solicitation......... This means hosts completely ignore all Router-Advertisement and when they need to find a router, they start with a Router-Solicitation. That is that far away from the draft that Bill Simpson wrote that I understand the two of you can't agree. If this is what you want, we need a draft document that defined your definition of Neighbor Discovery to compare it with Bills documents for there is hardly anything in common. ........ and the routers are not bothered by an all-hosts solicitation. ......... In Bill's documents routers are also not bothered by all-host-solicitation since the whole concept doesn't exist there. ...... The complexity in the host to accomplish this needs further discussion from host implementors regarding complexity, performance costs, and robustness. This will also work when the router also has to support application layer software such as telnet, snmp, or DHCPng. Am I right that you see the task of listing to the Router-Advertisement, as Bill suggested them, is a too heavy burden for the host? I'm trying to find the point of discussion here: Can every host listen to Router-Advertisement yes or no. Bill's draft documents require that is possible. If I understand you correct that is what you try to avoid. When looking at my desk I see Macintoshes and even the oldest 8 Mhz 68000 models have no problem with listing to the AppleTalk multicasts all the time. >My comment: >(1) Network management is especially useful when there are >problems, one problem might be a router not sending correct >router advertisements. Another problem might be that some >router advertisements are lost and the router entry is >timed out. I believe that to communicate with a router the all-router solicitation should be used as stated above for media address resolution. That's only possible if the node realizes he talks to a router: (1) When he realizes that, he must have heared the Router-Advertisement and he has learned the Media Address from that. (2) When he doesn't realize the other node is a router (let's say: I type telnet bla-bla on my Powerbook, without knowing its a router), then I can't do a Router- Solicitation. So for the case of robustness a router should react on General- Solicitations too. Jim, The draft documents that are published in the internet-drafts directories, don't talk about all-host-solicitations or all-router-solicitations. To correctly compare what you suggest with what Bill wrote in these documents we need a complete draft spec. Jim, I think with this I also answered your mail on Media Address Resolution and routers. Again sorry I didn't see your answers before I send all the mail of yesterday, realize I'm sitting in Europe and I have to dial in to the corporate network to collect my mail. ------------------------------------------------------------------------------ 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 Nov 3 04:14:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15657; Thu, 3 Nov 94 04:14:25 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15651; Thu, 3 Nov 94 04:14:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29041; Thu, 3 Nov 94 04:09:58 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA20941; Thu, 3 Nov 94 04:09:43 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04395; Thu, 3 Nov 94 06:12:12 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA23868; Thu, 3 Nov 94 06:09:11 CST Date: Thu, 3 Nov 94 06:09:11 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411031209.AA23868@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: routers in solicited-node? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) routers in solicited-node? >>>> Bill Simpson replying to Fred Rabouw > One opinion: for network management, a router is a > normal host, so it should act as a normal > host. That means it should listen to the > solicited-node multicast. > The other opinion: routers should ignore the (layer 2) > solicited-node multicast. Since a > router sends router-advertisements, > its Media Address is known already. > This is not "opinion", it is part of the design. It's part of a DRAFT document, on which I agree in many cases. But which should still be open for changes, even a published RFC can be commented and changed in a later version. If Jim and Alex have arguments for another proposed standard we should discuss that. I carefully used the word "opinion" to avoid either expressing either any authority or my preferences or whatever when I first stated the view points that are discussed. A "feature" that you missed is that Solicitation packets which are destined for a host will not be sent to a router. Routers are already busy. I know that solicitated-packets are send to a limited set of nodes by the hashed solicited-node multicast. I did never suggest that a router should listen to all the solicited-node multicasts and react on them. I only suggested that when a node for whatever reason does not know the router media address and sends a packet to that router using its IPv6 address and the hashed-solicited-node-IEEE-multicast the router should simply react on that. But only to solicited-node multicast for his own addresses, not for any address of any other node. Another problem is that if a router gets the datagram, it will discover that it is not destined for itself, and a broken implementation would forward a duplicate to the host, wasting bandwidth. Again, that is not what I had in mind. Solicited-node-multicast for other nodes should be ignored by the router. Of course, a broken multicast implementation might intercept multicast packets for groups it had not joined, resulting in the same problem. Both problems are completely solved by the simple IP requirement that datagrams may be duplicated. Agree on both. > My comment: > (1) Network management is especially useful when there are > problems, one problem might be a router not sending correct > router advertisements. Then the entire subnet would be down, and no communication would be possible (on that interface). If the management station was on that link, it wouldn't even have an autoconfigured address yet. If it was on another link, then it should use that other link to communicate with the router. Not necessarily, when the subnet has multiple routers and one routers due to whatever software bug doesn't send understandable Router-Advertisements, the subnet is normally functioning, but I just want to be able to reach to that router. > Another problem might be that some > router advertisements are lost and the router entry is > timed out. In which case the router is presumed dead. LifeTime is for black-hole detection. We can't assume that a black-hole isn't really black, just sort of gray. > In order to reach to that router it should react > as a normal host on the solicited-node multicast. > No. Only when routing is turned off for that interface. When the router is timed out we should not use it for forwarding any more, I fully agree on that with you, but my network manager might want to know why the router is timed out and might want to try ping or telnet. I can think of many bugs that can cause the router to stop routing but still allow ping or telnet. > In order to reach to that router it should react > as a normal host on the solicited-node multicast. > No. Only when routing is turned off for that interface. And this presumes that a router which had a broken router Neighbor Discovery implementation would have a correctly functioning host Neighbor Discovery implementation. Bad assumption. Same argument as above. > (2) Page 21 of draft-simpson-ipv6-discov-process states "It > is desirable to store more than one default router in the > list". That leaves the freedom of not storing all > discovered routers. If such an endstation wants to telnet > or ping to a router, he doesn't realize its a router and > will use simple solicited-node multicast. > But, if the node doesn't have enough storage for the routers, where is it going to store the next hop? It's probably the same table. This is actually a leftover from the "send all packets to the router, which will re-direct". In that case, the default router would have told you the other router's address. Bill, take a subnet with fifty routers and I coming in with my simple MacPowerbook: It will get all Router-Advertisements of all fifty routers, but to reach to the world my IP software only stores the ten routers with the highest preference. Then I want to trouble shoot the network and want to telnet to the lowest preference router. It is on the same subnet, so my Mac doesn't even consider to send it to a router, It only sees a telnet request to a node on the same LAN, so it will send a solicited-node-multicast to the specific node. I expect that (and only that) node to respond, no other router should be involved, no "routers" reacting on solicited-node-multicasts. ------------------------------------------------------------------------------ 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 Nov 3 06:04:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15796; Thu, 3 Nov 94 06:04:54 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15790; Thu, 3 Nov 94 06:04:47 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03183; Thu, 3 Nov 94 06:00:29 PST Received: from gatekeeper.icl.co.uk by Sun.COM (sun-barr.Sun.COM) id AA00867; Thu, 3 Nov 94 06:00:04 PST Received: by gatekeeper.icl.co.uk (4.1/UNIPALM-Vevision: 1.3 gatekeeper.icl.co.uk) id AA01720; Thu, 3 Nov 94 14:02:54 GMT Received: from unknown(145.227.14.59) by gatekeeper via smap (V1.3mjr) id sma001718; Thu Nov 3 14:02:27 1994 Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA18004; Thu, 3 Nov 94 14:00:54 GMT Message-Id: <9411031401.AA21213@getafix.oasis.icl.co.uk> Date: Thu, 3 Nov 94 14:01:10 GMT From: p.v.mcmahon.rea0803@oasis.icl.co.uk Subject: RE: (IPng) BSD Socket API sent to X/Open List fyi To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > p.s. Dan M. - We should talk off line as I just about have what I > believe the security API should be for IPv6 completed and proposed > wording. Might not want competing specs for security API to go to > X/Open, plus mine will go to POSIX too. It would also be nice if it was > part of BSD API present spec too. > IPv6 Security API Extensions for the above IPv6 BSD API are currently > being developed by Dan McDonald (NRL) and should appear online fairly > soon now. What IETF WG is agreeing the security API before it gets input to X/Open ? [Apologies in advance if I have missed the WG Action which said where it was being developed]. Piers McMahon, X/Open Security Working Group ------------------------------------------------------------------------------ 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 Nov 3 08:43:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15984; Thu, 3 Nov 94 08:43:02 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15978; Thu, 3 Nov 94 08:42:55 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14501; Thu, 3 Nov 94 08:38:36 PST Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA27185; Thu, 3 Nov 94 08:38:22 PST Message-Id: <9411031638.AA27185@Sun.COM> Date: Thu, 3 Nov 94 11:33:53 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Performance Aggregate Gains in IPv6 (the Big Picture Test) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Jim, > Are you saying align on 128bit boundaries and use an integer > multiple of 16 octets? Yes, although, as was pointed out, I did not make that clear in my original message. However, if, as was suggested, folks do not think that IPv6 will last until 128-bit chips arrive, or that off-by-a-factor-of-two misalignments do not incur a significant performance penalty, or that only the fixed header really matters and that can be offset to make the addresses aligned, then the point looses significance. Jon, > the thought of trying to buffer the first cell or two before making a > decision is worrying me....and i bet people will want such boxes... ATM seems a bit of a stretch from my IPV6 question, but ... Yes that is a concern for the ATM folks, or the maker of such boxes, to deal with. Closer to IPv6, I suspect that the architectural issue for IPv6 has to do with the "filter tests", at least if you mean something having to do with IPv6 access control/QOS. Given that support for privacy is required and organizations might use it, then trying to filter on privatized header fields, i.e., random bits, won't work. [If it we up to me :-), I'd make sure that ONLY the fixed header was needed for such filtering, and consequently make it an architectural requirement that the necessary information be in the fixed header. Are source & destination addresses and flow id really sufficient? What "usage rules" would we need to legislate to make them sufficient? If the rules cannot be found, then what additional info would be needed into the fixed header (additional info might allow 128-bit alignment). I would not like to repeat the IPv4 situation where useful IP layer services, e.g., options, were effectively prohibited because they "cost" to much to switch or process. To repeat two examples that I've mentioned for IPv6: "firewalls", and "I need QOS, but cannot use the IPv6 privacy header because then the RSVP/whatever established filters cannot identify my packets so I am forced to roll my own application level security, that IETF may not have standardized so is non-interoperable ...".] 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 Thu Nov 3 10:56:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16208; Thu, 3 Nov 94 10:56:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16202; Thu, 3 Nov 94 10:56:10 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04496; Thu, 3 Nov 94 10:51:51 PST Received: from newsun.Novell.COM by Sun.COM (sun-barr.Sun.COM) id AA27174; Thu, 3 Nov 94 10:51:30 PST Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA00290; Thu, 3 Nov 94 10:24:14 PST Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA21934; Thu, 3 Nov 94 10:24:11 PST From: Tae_Kyong_Song@Novell.COM (Tae Kyong Song) Message-Id: <9411031824.AA21934@na.SJF.Novell.COM> Subject: Re: (IPng) replacement for gethostbyname() To: ipng@sunroof.Eng.Sun.COM Date: Thu, 3 Nov 1994 10:24:11 -0800 (PST) Cc: tae@na.SJF.Novell.COM (Tae Kyong Song) In-Reply-To: <199411022110.NAA25462@vangogh.CS.Berkeley.EDU> from "Keith Sklower" at Nov 2, 94 01:10:13 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1207 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > This document proposes a uniform programmatic interface to the > Internet name resolution system, in which differences between IPv4, > IPv6, and CLNP are irrelevant to the applications programmer. This > work was originally motivated by the desire to minimize the impact on > standard BSD utilities to support TUBA, but work equally well for > IPv6. > Keith, In TCP/IPX, we use existing gethostbyname for the time being. I realize that h_addrtype field is often not looked at by existing applications. However, we still need a function that can be used for any address type to support multilingual applications (eg, telnet server running both on TCP/IP and TCP/IPX) and resolve a name string to the {type, address}. So, we couldn't make use APIs suggested in the socket API draft for IPv6 by Bob Gilligan, which requires {name, type} as input. And I'd rather see the new function being a superset of gethostbyaddr, without requiring the addr type as an input. Anyway, just a note to let you know that there is a socket implementation for TCP/IPX that Novell will be shipping, and that it would be nice if we can make use of the new function for multilingual applications. Tae. ------------------------------------------------------------------------------ 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 Nov 3 14:17:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16410; Thu, 3 Nov 94 14:17:23 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16404; Thu, 3 Nov 94 14:17:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01603; Thu, 3 Nov 94 14:12:56 PST Received: from newsun.Novell.COM by Sun.COM (sun-barr.Sun.COM) id AA04716; Thu, 3 Nov 94 14:08:17 PST Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA01432; Thu, 3 Nov 94 14:07:44 PST Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA24839; Thu, 3 Nov 94 14:07:42 PST From: Tae_Kyong_Song@Novell.COM (Tae Kyong Song) Message-Id: <9411032207.AA24839@na.SJF.Novell.COM> Subject: Re: (IPng) replacement for gethostbyname() To: ipng@sunroof.Eng.Sun.COM Date: Thu, 3 Nov 1994 14:07:41 -0800 (PST) In-Reply-To: <9411031824.AA21934@na.SJF.Novell.COM> from "Tae Kyong Song" at Nov 3, 94 10:24:11 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 108 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Oops, apologies for clogging ipng group. I thought I pressed "r", but it went out to the rest instead. Tae. ------------------------------------------------------------------------------ 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 Nov 3 15:17:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00205; Thu, 3 Nov 94 15:17:00 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00198; Thu, 3 Nov 94 15:16:52 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12215; Thu, 3 Nov 94 15:12:33 PST Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA17600; Thu, 3 Nov 94 15:11:23 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 4 Nov 1994 09:02:44 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 4 Nov 1994 09:06:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 4 Nov 1994 10:05:49 +1000 Date: Fri, 4 Nov 1994 10:05:49 +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 941104 08:11:21 072] X400-Content-Type: P2-1984 (2) Content-Identifier: 941104 08:11:21 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941104 08:11:21*/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) IPV6 SYSTEM DISCOVERY: IPV6 MULTICAST TO IEEE Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM re this multicast/ discovery issue. been reading with interest. My view on discovery is simple. Let the specification permit any node to talk to any other, ie define the information and the protocol mechanism, but put parameters in that permit the network designer to choose the operational dynamics. However, just read an article where IBM are putting ATM into the desktop. Does this mean that each IBM workstation is on a single "link". It also needs a cluster/ subnet address and it cannot use link level multicast for discovery and it has to have signalling and QOS management for each VC between each node? Perhaps a multicast ATM is the choice here, but random cell loss over a congested network would make this fun. HMMMMM.. Perhaps some input from IBM on this one might help the multicast / discovery model? Also.. I am still not quite comfortable with IP6 addressing. And IMHO the comments like "we should not be applying mystic properties" to addresses, and geographic schemes are doomed (whoops there goes my telephone again!) concern me. The issue has been raised that the discovery model REQUIRES multicast addresses to be administered. The SDRP and router discovery model will need cluster addresses to be administered properly (globally). eg. SDRP doc quotes Domain Ids = "clusters" yet indicates Domain Ids are beyond the scope of the document. Domains to me permit a subdivision of the address space so that router updates can be limited within domains and/or between domains. ie. Organisational properties of a network which have a serious impact on traffic flows and network dynamics. I am sure this has already been said. It is of little value to look at saving cpu cycles processing 64 byte aligned headers if the network at large has 500,000 routers all updating each other because they have dynamically assigned non aligned (to regions, countries, organisations, etc) free wheeling and /or multiple addresses. How are alternate routes managed in this model in a large scale meshed network? I feel that this basic address assignment and terminology issue must be resolved, as one can debate all the virtues and faults of the discovery model on various network cases. BUT it like it or not it will not scale. (imagine a host receiving updates for all the dynamically assigned addresses for country, let alone an internet.) I believe the same issue will apply to the management of flow ids, the management of authentication mechanisms, the management of mobiles and "care of addresses", etc. Addresses must indicate routing hierachy and be subdivided and administered into regions/orgs, domains, subnets, nodes. Trying to apply ideals of borderless, dynamically assigned addresses to all, just operationally breaks all the functional requirements of discovery, mobiles, accounting, flow and QOS, security, route management, etc and network administration (when dealing with the larger scale networks). Bottom lines. can the deficiencies in IP4 (eg security, mobility, autoconfiguration) be cured in IP6 without dealing with this addressing issue? Can this issue be "addressed" at the SJ meeting. eg scaling IP6. Have I not read something? Is this the right list for this? Or am I up a gum tree? 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 Nov 3 17:38:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00359; Thu, 3 Nov 94 17:38:25 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00353; Thu, 3 Nov 94 17:38:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07103; Thu, 3 Nov 94 17:33:55 PST Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA01276; Thu, 3 Nov 94 11:13:12 PST Received: by rodan.UU.NET id QQxolo21461; Thu, 3 Nov 1994 14:12:08 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) IPv6 System Discovery: solicited-node To: ipng@sunroof.Eng.Sun.COM Date: Thu, 3 Nov 1994 14:12:07 -0500 (EST) In-Reply-To: <11929.783845051@munnari.OZ.AU> from "Robert Elz" at Nov 3, 94 05:44:11 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 738 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] > I believe that more than 50 nodes on a LAN will be common. > >I think this is going to depend on the type of LAN, and the >costs of interconnecting with routers. Personally on an >ethernet I think 32 is too many (bridges or not). (Its too >many for FDDI too, but that's just because FDDI interfaces >still cost too much to afford that many...) [...] IPv6 is going to be around for a *long* time, or at least we hope it will. LAN technologies will come and go over that time. If I had to make a bet, it would be that at least one of them will be "just fine" with 50+ hosts on it, and inexpensiave enough for it too. Let's keep IPv6's expected lifespan in mind before we read _too much_ from the existing uses of IPv4. ------------------------------------------------------------------------------ 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 Nov 3 21:14:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00509; Thu, 3 Nov 94 21:14:10 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00503; Thu, 3 Nov 94 21:13:59 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA00264; Thu, 3 Nov 94 21:09:40 PST Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA21262; Thu, 3 Nov 94 21:09:26 PST Received: by rodan.UU.NET id QQxonc29018; Fri, 4 Nov 1994 00:09:25 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) RE: RE: (IPNG) IPV6 SYSTEM DISCOVERY: IPV6 MULTICAST TO IEEE To: ipng@sunroof.Eng.Sun.COM Date: Fri, 4 Nov 1994 00:09:25 -0500 (EST) In-Reply-To: <"941104 08:11:21*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> from "ALAN.LLOYD@DCTHQ.datacraft.telememo.au" at Nov 4, 94 10:05:49 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1410 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >Also.. I am still not quite comfortable with IP6 addressing. >And IMHO the comments like "we should not be applying mystic properties" to >addresses, and geographic schemes are doomed (whoops there goes my telephone >again!) concern me. [...] Correct me if I am wrong, but in the telephone system the "geographic scheme" maps dirrectly to the provider. As far as I know there are no +1 703 204 XXXX phones not provided by Bell Atlantic, and the Bell Atlantic-GTE border doesn't stradle an exchange. I beleve this is even the case in areas where there is competation for local dialtone service. (they do have provisions for temporallary forwarding a number) I suppose this isn't the case for 800 numbers, but there are only 1,000,000 of them. Also POTS service is connection baised, so they can afford to have somewhat more expensiave "routing" to set-up the call then IP can, so the design space for POTS is diffrent from the design space for IPv6. (as for my personal biases, I don't know if a geographic scheme can work, and I don't know if having one will buy anything useful. I don't know if a provider-baised scheme can work (but I susspect it can), but I do know it provides useful info: if you have a choice of equally good servers, the best one to pick tends to be the one getting network service from the same provider, and I know it will make alot of routing problems simpler.) ------------------------------------------------------------------------------ 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 Nov 3 22:40:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00610; Thu, 3 Nov 94 22:40:29 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00604; Thu, 3 Nov 94 22:40:23 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05065; Thu, 3 Nov 94 22:36:04 PST Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA00483; Thu, 3 Nov 94 22:35:47 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 4 Nov 1994 16:30:13 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 4 Nov 1994 16:34:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 4 Nov 1994 17:32:31 +1000 Date: Fri, 4 Nov 1994 17:32:31 +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 941104 17:00:31 087] X400-Content-Type: P2-1984 (2) Content-Identifier: 941104 17:00:31 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941104 17:00:31*/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) ANSWER TO ALANS COMMENTS ON IP6 ADDRESSING AND POTS. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM the POTS response to my addressing concerns - the author's name was not tranfered. but thanks. I understand that in the US the deregulation has "modified" the good old geographic systems and "providers" are the new age. But I also think there are major advantages in geographic schemes as used in PACRIM, Europe, etc. What I was trying to understand was that given the IP6 address space is "logical" providers, subscribers, subnets, etc, I was trying to come to grips with how this space is assigned in terms of organisations / geography so that the way the addresses are administered do not end up with 100s of thousands of providers all over the world where the provider number cannot be associated to route optimisation and connection management. Saying that POTS is a connection oriented environment and one can afford complexity in connection setup, etc is true. But with IP6 I see that with mobiles, flow ids, security domains, discovery and route management functions, one is in fact setting the network contexts for protocol processing and user to user data transfer. Ie a "connection" (a tranfer environment), eventhough a datagram is used to transfer the data. ie the switch/ router still retains knowledge of this connection environment(for a finite time), it is more informed than just knowing the route the datagram should take. This "connection" could span the Internet and one or more IP6 providers. Perhaps I am looking for a document that describes how the IP6 address space is operationally assigned and how the field lengths used (provider, etc) are determined and where these are regionally managed. Thoughts on this are welcome. 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 Nov 4 03:16:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00702; Fri, 4 Nov 94 03:16:52 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00696; Fri, 4 Nov 94 03:16:43 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12921; Fri, 4 Nov 94 03:12:24 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA28235; Fri, 4 Nov 94 03:12:10 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA14837; Fri, 4 Nov 94 05:14:42 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA09045; Fri, 4 Nov 94 05:11:50 CST Date: Fri, 4 Nov 94 05:11:50 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411041111.AA09045@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: routers in solicited nodes? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From Fred Rabouw replying to Alan Conta, who was replying to Bill Simpson [Bill:] Actually, Conta hadn't noticed that the lifetime is not the same rate as the advertisements. By default, the LifeTime is three (3) times as long as the maximum advertisement interval. (Processing p 10) [Alan:] For the sake of accuracy, actually I did. But the specs say (Processing p 12 in the draft I look which is from October 1994) that "Must be [AdvertismentLifetime] no less than MaxAdvertismentInterval" which implies that AdvertismentLifetime = MaxAdvertismentInterval is a valid value, which one can set. Recomendation, change to: "Must be greater than MaxAdvertismentInterval + MinAdvertismentInterval" [Fred:] I agree with Alan that this change makes sense, on the other hand, I do quit a lot of trouble shooting (when I don't read this IPng E-mail :-] ) and any network manager that changes any timer parameter from default must either have a (very) good reason to do so, or I will ask him to change it back to the default [Bill:] Only hosts join solicited-node. [Alan:] 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. [Bill:] You always examine the router list first. This is already extensively described in "Next Hop Decision", paragraphs (c) and (d). Since you match the router, and already have a media address entry for the router (obtained from the router advert), there is never any reason to solicit the router for host functions. [Fred:] Bill, I know that a host will normally have the router in its cache table, since it learns the Media Address from the Router-Advertisements, but for the sake of robustness, what does it cost to allow a router to answer a General- Solicitation for the resolution of HIS OWN "IPv6 to Media Address", (never for the resolution of other nodes (!)). It does not make life of the router harder, since during normal operation it will never have to happen and if there are problems to access the router it gives the network manager a second change to control his network. Fred ------------------------------------------------------------------------------ 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 Nov 4 03:17:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00714; Fri, 4 Nov 94 03:17:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00708; Fri, 4 Nov 94 03:17:36 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12943; Fri, 4 Nov 94 03:13:18 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA28320; Fri, 4 Nov 94 03:13:03 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA14841; Fri, 4 Nov 94 05:15:34 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA09048; Fri, 4 Nov 94 05:12:36 CST Date: Fri, 4 Nov 94 05:12:36 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411041112.AA09048@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 System Discovery: IPv6 multcast to IEEE Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From Fred Rabouw in reply to Allan Loyd's message: Subject; (IPng) RE: RE: (IPNG) IPV6 SYSTEM DISCOVERY: IPV6 MULTICAST TO IEEE > However, just read an article where IBM are putting ATM into the desktop. > Does this mean that each IBM workstation is on a single "link". It also > needs a cluster/ subnet address and it cannot use link level multicast for > discovery and it has to have signalling and QOS management for each VC > between each node? Perhaps a multicast ATM is the choice here, but random > cell loss over a congested network would make this fun. > HMMMMM.. > Perhaps some input from IBM on this one might help the multicast / discovery > model? An ATM switch is not a router (although unit might combine the functionality in a single chassis. All these ATM endnodes connected to an ATM network (one or more switches) can appear as a single subnet to IP. In fact the ATM Forum is moving that way with the ATM LAN-emulation standard. That does NOT mean ATM-multicasts everywhere, but it means that IP-multicasts will be mapped to ATM-multicasts. The issue of IP over ATM is well understood although there are (of course :-[ ) different opinions on how to standarize it. I think IBM's opinion is just as good as any others opinion on the subject. > It is of little value to look at saving cpu cycles processing 64 byte aligned > headers if the network at large has 500,000 routers all updating each other > because they have dynamically assigned non aligned (to regions, countries, > organisations, etc) free wheeling and /or multiple addresses. > How are alternate routes managed in this model in a large scale meshed > network? The concept of cluster pre-fixes makes it possible to summarize the details within an administrative domain and only advertize a limited number of addresses to the outside world. For details we will have to wait for the IPv6 version of IDRP and/or other protocols for routing between administrative domains. > I feel that this basic address assignment and terminology issue must be > resolved, as one can debate all the virtues and faults of the discovery model > on various network cases. BUT it like it or not it will not scale. (imagine a > host receiving updates for all the dynamically assigned addresses for > country, let alone an internet.) In the present drafts on Neighbor Discovery as can be found in the appropriate plaxes on the Internet, hosts do NOT get updates od addresses outside their own subnet, so NO your host will not get any updates of the rest of the country (unless you bridge the country together instead of route it together). > Addresses must indicate routing hierachy and be subdivided and administered > into regions/orgs, domains, subnets, nodes. Trying to apply ideals of > borderless, dynamically assigned addresses to all, just operationally breaks > all the functional requirements of discovery, mobiles, accounting, flow and > QOS, security, route management, etc and network administration (when dealing > with the larger scale networks). Addresses in IPv6 do address routing hierarchy even with multiple levels of hierarchy. That is exactly the reason why many believe it will scale well. Addresses are certainly not assigned "borderless", your host in Australia will get its cluster prefix from your Internet and it will differ from the cluster prefix I will get for my host in the Netherlands. And inside this cluster prefixes will be more levels of hierarchy hidden for the enduser but expressing the hierarchy between Internet access providers. > Can this issue be "addressed" at the SJ meeting. eg scaling IP6. > Have I not read something? > Is this the right list for this? Or am I up a gum tree? Good question whether this is the right list, how can I know. I'm only filling it ------------------------------------------------------------------------------ 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 Nov 4 08:03:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00843; Fri, 4 Nov 94 08:03:52 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00837; Fri, 4 Nov 94 08:03:45 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24779; Fri, 4 Nov 94 07:59:27 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26258; Fri, 4 Nov 94 07:59:10 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA00664; Fri, 4 Nov 94 07:54:02 -0800 Received: by xirtlu.zk3.dec.com; id AA01362; Fri, 4 Nov 1994 10:53:16 -0500 Message-Id: <9411041553.AA01362@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) permitted solicitations In-Reply-To: Your message of "Thu, 03 Nov 94 20:54:36 +1100." <11955.783856476@munnari.OZ.AU> Date: Fri, 04 Nov 94 10:53:10 -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 >The only way that this can be avoided is to explain quite >precisely exactly why following the rules is going to give >the best result - not for the "net as a whole" nor for some >other node, but for my particular implementation. Obviously >that implies that the rules have to actually posess that >property. This is very true. I will build prototypes using the specs. I will go to bake offs and itneroperability events. From those events vendors will learn what works and what does not. Products will have what works. But if we do what Kre says we have a better chance of getting these standards implemented according to plan. Also I think what Kre is asking for is rationale in 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 Fri Nov 4 08:18:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00873; Fri, 4 Nov 94 08:18:42 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00867; Fri, 4 Nov 94 08:18:35 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26374; Fri, 4 Nov 94 08:14:16 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29246; Fri, 4 Nov 94 08:13:38 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA01938; Fri, 4 Nov 94 08:05:13 -0800 Received: by xirtlu.zk3.dec.com; id AA02545; Fri, 4 Nov 1994 11:04:31 -0500 Message-Id: <9411041604.AA02545@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? In-Reply-To: Your message of "Thu, 03 Nov 94 12:10:28 +0100." <199411031110.AA15234@mitsou.inria.fr> Date: Fri, 04 Nov 94 11:04:25 -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 Christian, >1) mandate router discovery (done). I think this is a done deal. >2) mandate default hash (being done, if I understand correctly). > mandate that no host use that trick if a router has been discovered. I absloutely do not agree and this is a bad engineering approach in IPv6. The input has been presented I see no need for any more debate we need a decision so we can get back to work coding. Right now I am not putting this in our prototype. Its a bottleneck to building IPv6 lets make a decision. Steve ????? 3) define ICMP "solicit" (being done, if I understand correctly). NO its not done. We can do this until the above is resolved. Unless your talking purely about the format of solicitation? >Isn't it the case that we are pretty near from converging? No not at all. Why did you think so or did you just discount Alex's and my mail to Fred? So far the only people responding are you, Alex, Bill, Fred, Dan, Robert, and I. This not consensus Christian and we still await the implementor meeting minutes too, which is more input. Not even close. Steve ??? /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 Fri Nov 4 10:22:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00987; Fri, 4 Nov 94 10:22:09 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA00981; Fri, 4 Nov 94 10:22:01 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12895; Fri, 4 Nov 94 10:17:41 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA22061; Fri, 4 Nov 94 10:17:12 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA10040; Fri, 4 Nov 94 10:01:36 -0800 Received: by xirtlu.zk3.dec.com; id AA11833; Fri, 4 Nov 1994 13:01:34 -0500 Message-Id: <9411041801.AA11833@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Implementor Meeting Minutes PLEASE !!! Date: Fri, 04 Nov 94 13:01:28 -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 and AD's, I hate to be a pit bull dog on this one but I have too. I sent mail over 5 days ago that we NEED these minutes. A response was sent by Steve. Yet no minutes still. The meeting was Oct 10-12. About 35 real coders (implementors) came to the meeting. Their companies spent travel costs to send them to this meeting maybe becasue it was important to them to have such a discussion with other implementers. Its now Nov 4th. The results of that meeting were very good and the ideas and discussion need to be shared IMHO with the IPng Working Group. I think we need these now and I find it unacceptable that the minutes are still not sent. Can someone please send them to us. In the future if you can't turn around minutes for meetings in two weeks please don't offer to be responsible in the working group is my suggestion to anyone. 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 Fri Nov 4 11:22:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01042; Fri, 4 Nov 94 11:22:38 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01036; Fri, 4 Nov 94 11:22:31 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22201; Fri, 4 Nov 94 11:18:12 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05971; Fri, 4 Nov 94 08:49:29 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA03273; Fri, 4 Nov 94 08:38:58 -0800 Received: by xirtlu.zk3.dec.com; id AA05439; Fri, 4 Nov 1994 11:38:55 -0500 Message-Id: <9411041638.AA05439@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) IPv6 System Discovery "Where we are at IMHO" Date: Fri, 04 Nov 94 11:38: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 Fred, I want to state where I think this discussion is presently and what I think should be done next. Then I want to respond to some valid generic concerns you raised regarding specifying any system discovery. Then I will tell you why the working group has not seen a draft mostly likely from Alex and I and a few others who do agree with us. 1. Where are we at? You have done a great job of bringing to the working group all the issues of debate and technical disagreement. We need to thank you for that and your input too as an expert. But the technical positions I think are very clear and all have also proposed their rationale to some degree why they believe their idea on system discovery are correct. I see no further point of technical debate and would like to see Steve Deering get into this loop and provide some guidance to the working group on this subject for which he is also an expert. I am not spending any more cycles on this and I think the differentiations in technical philosophy are clear and why. Its time for a decision. So we can move forward. The system disovery code is the lowest layer (for syntax to discuss I am not saying you have to use layers for IPv6). Until this lower layer is defined our prototypes are guessing if they are implementable. I am not even clear what the routing table will look like at the ipv6_layer_mod? 2. Generic concerns of implementing discovery? You made me think about this per your comments about Powerbook and PC's and Robert Elz's comment on embedded systems. In any IPv6 specification we need to consider nodes with minimal resources. I believe this is a valid concern. But that can be handled with wording in the specs in most cases. For example, if my Scenario #2 were bought into then it could be stated that nodes with minimal resources are permitted to never send router solicitations, and can completely depend on advertisement. This would eliminate having to implement the host complexity I have proposed (also the only time my feature would be used would be if there were no advertisements forth coming or a time-out, otherwise I would depend on advertisements too). So the bottom line is that we must gurantee nodes that are resource poor can implement IPv6. 3. Competing Drafts? Alex and I could have built an adjunct draft to Bill's proposal. But competing drafts are counter-productive in a standards forum. We also were asked to not do this by Steve Deering and Scott Bradner, and try to work our technical problems with System Discovery with Bill's draft. We have done this and why you have not seen a completely new draft from Alex and I and as I said a few other folks. Your ability to gather clear and concise input based on your staircase of abstracting the issues in a clear manner to the working group I think has afforded the group to see the lines of demarcation in technical approach between all of us. I think at this point we need Steve to get in the loop. I have other IPv6 work to do too. 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 Fri Nov 4 11:28:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01054; Fri, 4 Nov 94 11:28:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01048; Fri, 4 Nov 94 11:28:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23263; Fri, 4 Nov 94 11:24:09 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA02792; Fri, 4 Nov 94 11:21:28 PST Received: by nero.dcrc.com (4.1/1.34) id AA10531; Fri, 4 Nov 94 14:20:10 EST Date: Fri, 4 Nov 94 14:20:10 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411041920.AA10531@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9411041801.AA11833@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: (IPng) Implementor Meeting Minutes PLEASE !!! Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I wholeheartedly agree with Jim's comments. It seems to me that the timetable for IPng is in grave danger, if not completely unrealistic. The biggest issue for me is that I don't even know what parts of which specs will apply to me, as a coder of router software. As I suggested in a previous note, I would like to get a clarification as to the definition of host in so far as it pertains to what parts of, e.g., Discovery I will have to implement. I have received only minimal response on this issue. I aplogize if this note is not constructive, but I don't want to beat my head against a wall that isn't going to give by Dec. 3. -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 Nov 4 22:48:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01829; Fri, 4 Nov 94 22:48:01 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01823; Fri, 4 Nov 94 22:47:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13901; Fri, 4 Nov 94 22:43:29 PST Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA08727; Fri, 4 Nov 94 22:43:15 PST Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA12434; Fri, 4 Nov 1994 22:43:15 -0800 Date: Fri, 4 Nov 1994 22:43:15 -0800 From: Tony Li Message-Id: <199411050643.WAA12434@lager.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: bmanning@ISI.EDU's message of Tue, 1 Nov 1994 07:09:32 -0800 (PST) <199411011509.AA11885@zed.isi.edu> Subject: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM SDRP is warmed over IDRP Really? That's quite some oven. 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 Sun Nov 6 07:04:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02234; Sun, 6 Nov 94 07:04:51 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02228; Sun, 6 Nov 94 07:04:42 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01132; Sun, 6 Nov 94 07:00:23 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA02324; Sun, 6 Nov 94 06:59:50 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 6 Nov 94 23:52:15 +0900 From: Masataka Ohta Message-Id: <9411061452.AA03766@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) ATM..MASATAKA'S COMMENTS To: ipng@sunroof.Eng.Sun.COM Date: Sun, 6 Nov 94 23:52:13 JST In-Reply-To: <"941102 10:11:48*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS>; from "ALAN.LLOYD@DCTHQ.datacraft.telememo.au" at Nov 2, 94 2:25 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > masataka. > your assumption that carriers will use IP6 addressing not E.164. > > Have you tested this on any carrier? Currently, IPv4 addressing structure is used by all the IP providors. > E.164 (and E.163) is used for the Worlds Telephone Network, the ISDN network, > the Fastpac (Australian dqdb MAN 802.6) network, the B-ISDN network, etc. > It strikes me that as data and voice and video combine (over B-ISDN and ATM) > that the signalling scheme used will be that as OWNED by the ITU and carriers. It is well known that IP is connectionless and connection-oriented nature of signalling at the IP layer destroys everything. > (even some of the comments on addressing eg. remapping, dynamic assignment, > its only used for routing,etc, etc, seem to miss this minor point about > global networking. Just imagine receiving a "worlds telephone directory" > every minute because the addressing was dynamic!) That's the reason why only the hierarchy of IPv6 should be used. Mapping between IPv6 and ITU hierarchy is unrealistic. > So mapping IP4 and IP6 addresses to E.164 and to switched environments is one > issue that: can be left to implementors or; > has to be dealt with in ARP, resource reservation, discovery, circuit > management, etc within the IPng framework. Just imagine receiving a "worlds telephone directory" every minute because the addressing was dynamic! 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 Nov 6 11:10:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02294; Sun, 6 Nov 94 11:10:25 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02288; Sun, 6 Nov 94 11:10:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04408; Sun, 6 Nov 94 11:05:58 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA09476; Sun, 6 Nov 94 11:05:39 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19950; Mon, 7 Nov 1994 06:04:10 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Comments on Date: Mon, 07 Nov 1994 06:04:07 +1100 Message-Id: <12226.784148647@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm sure there was once a good reason for it, but I'm not exactly sure why all the "next header" fields need to be taken from the same space as the IPv4 Protocol field. They're all IANA allocated, the only difference would seem to be which file the IANA records them in. Sure, the Next Header field file would need to be seeded with data that includes the current IPv4 transport protocols (ICMP, UDP, TCP, ..) but this would be a nice opportunity to clean the cruft out of that assignment list and start with something new. Oh well, never mind. For the "hop by hop options" header, it's stated that ... Its presence is indicated by the special value zero in the Next Header field" what's so special? Isn't this just yet another Next Header value? That zero happens to have been assigned might be nice for making the test for its presence faster, but zero is not really all that special is it? (This is just a wordsmithing comment). It's stated Each type of header should appear only once in a packet I'd prefer it to say "The appearance of a header more than once in a packet is for further study", sometime there may be some good use found for duplicating some kind of header (most likely routing headers I'd expect right now, but who can tell). It's also stated "IPv6 nodes are not required to verify that the order of headers ..." I'd prefer "IPv6 nodes are required not to verify that the order of headers ..." Again, placing the headers in some other order may turn out to have some very useful characteristics, it would be a pity if some enthusiastic, and popular, implementation prevented it from working by needlessly checking that everything is in the order that it is now considered to be the one correct way. There are 4 values defined for the two bit field that is the most significant two bits of the option type in Options (4.2). I don't recall whether the mbone IPv6 conference pre- or post- dated this draft, but during that I pointed out that the "11" value is useless, the sender knows if the packet is multicast, and can use either the "01" or "10" value as appropriate, the node sending the ICMP doesn't need to be making that test. I do note that the "10" case seems to explicitly permit (given that the "11" case was thought necessary at all) an ICMP to be sent when the destination address is a multicast - that needs to be highlighted I believe, as normally ICMP's aren't supposed to ever be sent in response to a multicast datagram. Given that the "11" case is deleted, I'd like to suggest altering the other cases to be two one bit fields instead of one two bit field, single bits are much easier and faster to test. One bit to mean "skip the option and continue" vs "discard the packet", the other bit to mean "send an ICMP" vs "don't send ICMP". This also has the rather fortuitous side effect that a "path receipt" type of effect can fall out of the woodwork by the artifice of a host sending a "known unknown" option type (say 0x1f) in the hop by hop options, with the top two bits set as "ignore option and continue" and "send ICMP". (The "authenticate" bit could be set either way). The data field of the "known unknown" option could contain an identifier or something (whatever the sending host desired) that it could use to assist in collecting the ICMP responses and from them generate a list of the nodes through which the packet passed. The ordering can be ascertained by the value of the hop count field in the returned (encapsulated inside ICMP) IPv6 header. I would very much prefer if all of the extension headers could have a common format, starting with the "next header" field in the first byte, and the "length" in the next byte. Length con continue to be expressed as ("total extension length" - 8) / 8 as it is in the option headers (that is in units of 8 octets not including the first 8). A common format makes processing of the things considerably easier. Of the headers currently defined, the two options headers, and authentication already have the required format. The fragmentation header can trivially be turned into this format by simply defining that second byte (currently "reserved") as "zero" instead, as the fragmentation header is exactly 8 octets long (its already defined to be sent as zero so this is no real change). That leaves just the routing header, which could be "fixed" by swapping the "num addrs" and "routing type" fields (for routing type == 0), and converting the "num addrs" into "length". Routing type 0 can easily calculate the old "num addrs" value from "length" by dividing by two ("num addrs" is a counter of 16 byte blocks currently, rather than 8 as in the length fields). Future routing types might need a more complex calculation (maybe subtract something, then divide by 2) or an additional explicit field somewhere, that sacrifice I believe to be worth the effort. This does limit the number of hops to 127 (rather than 255), so the packet couldn't be source routed through its entire maximum hop count (of 255). I don't think that is much of a problem, a packet with a source route of 127 hops is already seriously large (minumum size 2080 bytes assuming nothing after the routing header). There's an editor's comment asking if perhaps the minimum MTU should perhaps be required to be 1500 rather than 576. I'd go along with that. But if not 1500 (a number that can be justified) I see very little reason to pick 576 of all numbers. I'd have expected a number that allowed (probably) 512 bytes of user data, standard TCP header (20), standard IPv6 header (40), plus any likely extension headers (here I'd assume the authentication header). Ignoring Auth for now, the size needed is 572, not 576, with Auth, its something bigger, how much will depend on typical sizes of the authentication data. If you have to pick a number out of the air, and its not to be as big as 1500, then I'd probably select 600, its a nice round number, and allows 16 bytes for authentication data (and 8 for auth header) while still fitting 512 bytes of user data (and 4 bytes of slop, that occur because the TCP header is not a multiple of 8). Or if you want to stick to multiples of 16, then 592 or 608. Why 576? I suspect that the TClass along with "the ability to redefine the semantics" will end up making the flow label a disaster. It seems more likely to be successful if the defined TClass values were defined only if the Flow ID is zero, leaving the case where a flow has been set up to the setup procedure. I'd provide a simple (and perhaps even default) procedure to accomplish the "use the standard TClass" semantic, but I would do it that way rather than merely allowing a redefinition of the field (that isn't apparent externally). The problem I'm imagining is that if a flow has been set up, and the TClass has been redefined, then when the packet passes through some router that isn't part of the flow setup, which is certainly possible, it may incorrectly interpret the TClass with the standard meanings, not knowing any better, and then proceed to make a mess of the flow by treating it in a way other than that intended (perhaps seeing a nice low bandwidth, but important, audio stream as if its equivalent to netnews, and delaying every packet by months). Simply defining the TClass as only being meaningful if the Flow ID is zero, or if a meaning has been establlished in flow setup should avoid this, and will result in all packets with a flow id (non zero) passing throgh routers that aren't active setup participants treating the packets as "uncharacterized traffic". 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 Sun Nov 6 13:22:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02380; Sun, 6 Nov 94 13:22:16 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02374; Sun, 6 Nov 94 13:22:08 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09221; Sun, 6 Nov 94 13:17:50 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA16227; Sun, 6 Nov 94 13:17:27 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23205; Mon, 7 Nov 1994 08:12:31 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Comments on Date: Mon, 07 Nov 1994 08:12:29 +1100 Message-Id: <12237.784156349@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM First, a matter of style ... This document is a submission to the IPng Working Group of the Internet Engineering Task Force (IETF). Comments SHOULD be submitted to the ipng@sunroof.eng.sun.com mailing list. Lets kill this MAY/SHOULD/MUST please, and write the words like any other word is written - these have all the appearance of a global substitute of every [Ss][Hh][Oo][Uu][Ll][Dd] into SHOULD etc - when IPv6 is finally at the stage of needing a real requirements doc, in the sense of hosts requirements, then we can write something with those special SHOULD type words in it. This doc, though labelled "requirements" is really "opinions", and those magic words are not really appropriate. Apart from the usage above, which seems to tell me I'm not strictly conformant with something if I don't send comments to the list, (so of course, I am doing exactly that, no-one is going to label me a non-conformist) this doc has a several other weird cases as examples... Before a node can send datagrams beyond its directly attached link(s), it MUST discover the location of at least one operational router on the link(s). This is a simple fact, without a router a node can't send beyond the immediate links, it doesn't need to be stated as a mandatory requirement. If a node chooses a poor router for a particular destination, it SHOULD receive a redirect from that router. This one is even worse, a node is not strictly conformant if some other node doesn't send it a redirect... I make a point of this, as using SHOULD MAY MUST in capitals is becoming something of a fad in IETF docs, its very annoying, and in the end, if overdone, will only serve to reduce the effect and meaning of those things when used in the (very few) places where they make some sense. 2.4. Learn Routing-Prefix When prefix routing is in use, it is necessary to determine the prefix(es) for a link. This is something of a debatable point. There is a theory that hosts should not ever learn this information, and instead should simply trust the routers to do the right thing. I'm not sure on which side of the cart I sit on this one, I am sure that a bland statement without rationale is not going to coinvince me at all. 3.1. Multicast support All IPv6 nodes are required to support multicast techniques. That's good. There are numerous advantages to using multicast for the new messages. In particular, when compared to broadcast, reduced overhead for processing messages which are not ultimately intended for the node. That's good too - at least some kind of explanation. This is the primary technique for distinguishing the new messages. I don't think much of that though, if we're going to rely to a large degree on the form of the various addreses I don't think we're going to survive very well. I'd have thought that simply being in IPv6 rather than IPv4 packets was a pretty major distinguishing characteristic - quite apart from new ICMP codes, etc. 3.2. Reduced net traffic Currently, separate packets are sent for media address resolution, router discovery, and the Hello protocols for the various routing algorithms. This is a feature, not a bug. It enabled each of those to be developed, and migrate, independantly of the others. Attempting to provide something that does everything tends to lead to providing something that isn't quite perfect, so those that need the little more do their own, similar but different thing, and then you have two competing mechanisms whose differences are subtle, and a major potential mess. 3.3. Low storage overhead There MUST be sufficient storage in a host for information about at least one router. That is required only if the node happens to currently be communicating outside the current (directly attached) link, and then all that's needed to be kept is the media address of the router, nothing else. 3.4. Auto-configuration The connection procedures for a configuring a new node SHOULD be reduced to the minimal set of "plug it in, turn on the power, and run". That should be an option, no more - it's not always appropriate. - Each node self-assigns an identifier, usually within the number space assigned to one or more links to which it is attached. No, this should be done the way that addrconf is doing it. Nodes that self-anything are beyond control if they self-whatever in a way that local management doesn't like. Addrconf has a good solution to this, lets leave it to solve that particular problem. 5) It is important to allow users to choose a node name which is memorable and comfortable to them. The name SHOULD be automatically registered, and changes to the associated identifers SHOULD be maintained automatically. Again, this is sometimes what is wanted, not always. 3.7. Media independence There are many instances where neighbor discovery is accomplished differently over different media, such as point-to-point versus broadcast versus Public Data Networks. This is a feature. Discovery mechanisms SHOULD be above the internetwork-layer, where it enjoys greater independence. If you do this, that is really do this, not just make a half hearted attempt or pretence, then you're sacrificing the simplicity of media address resolution on devices like point to point links, and ethernets, to be able to cope with things like discovering X.121 addresses for X.25 calls, & E.163 addresses for ISDN calls (or whatever magic identifier is right). If you really have a simple, effecient, and media (and media address) independant address resolution protocol, then by all means lets do it in a hurry. I have yet to see one. Given that, I much prefer to keep these things media dependant, so only what is necessary is done for each medium. 3.8. Optimal route determination The design encompasses ... This is supposed to be a requirements doc, so far it has been, here it starts to push for one particular solution. If it's to remain a requirements doc, it shouldn't be doing that. If the preceding sections are just to be a lead in to a design of a particular solution, the title should be changed. 3.9. Simplicity The design MUST reduce the number of packet types which are be supported in a pure IPv6 node, This reminds me of V6 unix days, where everyone was racing about extending unix, with one of the major requirements being that as few as possible new system calls be added (largely an artifact of the particular way the sys call was implemented on the pdp-11). Fine, as far as it went, but the usual technique to do that was to add a zillion options, or sub-commands, to one sys call, often even one that already existed, and then claim "no new sys calls". Rubbish. Almost every new piece of functionality was a new system call in reality, but made more complex by being mangled into the requirements of something else that barely suited, but already happened to exist. The same is true here, a new ICMP type or code is a new packet type, regardless of it being carried inside an ICMP packet. Further, creating new packet types is not a sin, we're not going to run out of pdp-11 "trap" instruction codes, we don't have to attempt to hide them. 4.1. ARP The most common next-hop resolution protocol, the Address Resolution Protocol (ARP), is done at the link-layer rather than the internetwork-layer. That's a feature, its a link layer operation. Its requirements vary drastically based on the kind of link layer being used, from nothing at all (SLIP, etc), to absurd (X.25). ARP is deemed inadequate because it is a broadcast rather than a multicast technique, I agree with that, it can be fixed. adds latency, big deal. is frequently media dependent, feature. is not easily extensible for self-identification or mobility support, and does not directly support black-hole detection. It also doesn't beat eggs or whip cream... You didn't mention that it has no explicit lifetime support, which is its biggest drawback - that can also be fixed without totally re-inventing the wheel. Worse, many current ARP implementations drop the original datagram while waiting for resolution. This can happen at each successive hop, causing tremendous delay and retransmission. This is, as has been stated often recently, a simple implementation bug. If implementation bugs are enough to damn protocols, then I will be sure to implement your discovery stuff with enough serious bugs that its hope of redemption will be rather less than that of ARP. 5.2. Advertisements Periodic advertisements from a few commonly requested nodes result in less traffic than repeated solicitations and advertisements from many nodes. This is an unjustified assumption. Which technique results in less traffic will depend on large numbers of factors. 5.4. Extensions One of the common extensions is the media address. Each message contains enough information to return a reply directly to the sender, without additional location traffic. This is essentially equivalent to address gleaning, with all of its pitfalls - there are security problems, and potential routing problems as well. While it might be obvious now that certain packets are supposed to be confined to a link, and not routed beyond it, such that use of the enclosed media address is sufficient for the packet to be returned correctly, it won't take long before someone with $'s says to their vendor "I don't have the right kind of server for this on this cable, can't you just forward it over to where I do have the server please?" and sure enough, there's soon a "helper address" that takes local link packets and sends them where they were never intended to go. At this point, unless there's either some kind of very weird bridging happening, or some fiddling around inside the packet (hard with authenticated packets) the media address no longer works for sending return packets, and yet another kludge is born. 6. Host Discovery When a host or router needs the location of a target host on the same link, it sends a media multicast of the original unicast data packet, Fortunately, I think this idea has been beaten to death over the past week or two, so I will just provide some memories for the wake... Apart form the possible packet burst from a number of routers that decide to do the wrong thing, also consider just two routers, lets call them X and Y to protect the innocent, who each receive this multicast datagram from A intended for B. Now each of those decides to help A by forwarding the packet, but neither happens to know the media address of B, so each sends the packet via a multicast - each of course receiving the multicast from the other... 7. Router Discovery The number of routers are usually fewer than the number of hosts. The periodic Router Advertisements result in fewer messages than would occur if every node sent repeated Solicitations to discover the appropriate routers. Another unsupported assertion that will sometimes be true, and sometimes won't. 9. Self-configuration An IPv6 local-use unicast address MAY be combined with a cluster- prefix learned from Router Advertisements to form a routable IPv6 Address. If there was a place for capitals anywhere, it would be MUST NOT here - a node that determines its own address both defeats my addressing plan, which almost certainly won't be using media addresses in the low 48 bits of IPv6 addresses (way too wasteful), and allows nodes to connect to my network, and operate there, without having obtained my consent in advance. I may be willing to grant a blanket "anything can plug in and work" permission, but I'm just as likely to demand that everyone wanting to plug in to my cable must come to see me, cap in hand, and bribe under the table... Manufacturers absolutely must not defeat my little side graft by providing mechanisms by which nodes can get past my barriers (if I don't want them to). 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 Sun Nov 6 13:44:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02438; Sun, 6 Nov 94 13:44:33 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02432; Sun, 6 Nov 94 13:44:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10049; Sun, 6 Nov 94 13:40:07 PST Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA17104; Sun, 6 Nov 94 13:39:49 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 7 Nov 1994 07:34:41 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 7 Nov 1994 07:39:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 7 Nov 1994 08:37:37 +1000 Date: Mon, 7 Nov 1994 08:37:37 +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 941107 08:21:40 000] X400-Content-Type: P2-1984 (2) Content-Identifier: 941107 08:21:40 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941107 08:21:40*/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) ATM..MASATAKA'S COMMENTS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM masataka, thanks for the response. some comments. yes IP providers use IP addresses, BUT the telephones and ISDN systems use E.164, E.163. Connection Oriented "destroys everything"!. whoops there goes my telephone again, and my X.25 and my ISDN and my ATM. I have mentioned that one you put a "environment" around datagrams that deals with flow ids, authentication, discovery, security, one creates a "connection oriented" environment because one is providing context to the datagram, not just routing it. I will leave this one open to one's view. Anyway addressing hierarchy, as I keep asking. IP6 only has an address hierarchy because it starts at the left byte and works down to the right and has terms like provider/subscriber. It will only have a real hierarchy once its regional assignment procedures and allocations are known. And mapping IP addresses on to carrier plans is still an issue. Because the IP(4) model was built up on leased lines or dedicated trunks. Once applications become more switched bandwidth oriented - ie 100 mb sec for 2 minutes. They - the applications and the customers will not need or want to pay for ooodles of bandwidth so some standard "relationship between IP6 and ISDN and ATM signalling has to be found. 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 Sun Nov 6 19:34:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02596; Sun, 6 Nov 94 19:34:03 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02590; Sun, 6 Nov 94 19:33:55 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20741; Sun, 6 Nov 94 19:29:37 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA04539; Sun, 6 Nov 94 19:29:11 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 7 Nov 94 12:21:41 +0900 From: Masataka Ohta Message-Id: <9411070321.AA05963@necom830.cc.titech.ac.jp> Subject: Re: (IPng) RE: RE: (IPNG) RE: RE: (IPNG) ATM..MASATAKA'S COMMENTS To: ipng@sunroof.Eng.Sun.COM Date: Mon, 7 Nov 94 12:21:39 JST In-Reply-To: <"941107 08:21:40*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS>; from "ALAN.LLOYD@DCTHQ.datacraft.telememo.au" at Nov 7, 94 8:37 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > some comments. > yes IP providers use IP addresses, BUT the telephones and ISDN systems use > E.164, E.163. Use them as if it were unstructured MAC. > Connection Oriented "destroys everything"!. Connection Oriented requrement AT THE IP LAYER "destroys everything". ^^^^^^^^^^^^^^^ > whoops there goes my telephone > again, and my X.25 and my ISDN and my ATM. No problem. > I have mentioned that one you put > a "environment" around datagrams that deals with flow ids, authentication, > discovery, security, one creates a "connection oriented" environment because > one is providing context to the datagram, not just routing it. I will leave > this one open to one's view. Connection oriented support at the IP layer IN ADDITION TO connecionless support is OK. > And mapping IP addresses on to carrier plans is still an issue. Yes, I think the current plan is suitable for monopolized providers and is broken for multi-provider environment. 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 Nov 6 22:08:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02628; Sun, 6 Nov 94 22:08:22 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02622; Sun, 6 Nov 94 22:08:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24079; Sun, 6 Nov 94 22:03:57 PST Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA12072; Sun, 6 Nov 94 22:03:37 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 7 Nov 1994 15:58:11 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Mon, 7 Nov 1994 08:42:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Mon, 7 Nov 1994 09:40:07 +1000 Date: Mon, 7 Nov 1994 09:40:07 +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 941107 07:41:02 002] X400-Content-Type: P2-1984 (2) Content-Identifier: 941107 07:41:02 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941107 07:41:02*/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) IPV6 SYSTEM DISCOVERY: IPV6 MULTCAST TO IEEE Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM alex, your response. not sure if you answered much but you implied something re geographic assignment of clusters. I know IP is not ATM. but if one connects A subnet of IP devices over ATM "links" it breaks the rule? - "one subnet per link". Also link level multicasts over ATM over a wide area congested network could loose the odd cell or two, so IP ARPing / discovery may creak a bit. Clusters. I know my host wont get squillions of routing updates from the planet thats because of subneting and domains. They will get some though from the routers that bound the subnet/cluster which interconnect them to the planet. But as you implied, the domains must be administered by country or region to avoid all "regions" or clusters updating all clusters all over the planet. But as soon as I say IP address space should be assigned "country" or "region" people say NO. Ideals vs Reality or "this is where the rubber meets the road". I Read the neighbour discovery doc. A few comments but it still leaves inter cluster issues wide open to the address administration / domain assignment areas. The bigger issues, hence my comments. Specific comments on Neighbour Discovery The preference bit in the doc has has me wondering - Flow Ids and Preference? what takes precedence. Do I send my packet to the highest preference that knows nothing of my flow Ids or do I send it to lower preference that i think knows my flow ids? Also the Hop Cache entry for flow Ids seems wrong as flow Ids are not tied to an address, they are tied to a flow (ie different applications from that address may use different flows- (I dont like this flow stuff)) Also the Cluster prefix size, I am not sure where this comes from. It can be configured into the router for its own subnet(s) addresses. But how does the it get these from the rest of the bigger network. SDRP says cluster or unicast addresses are sent, no prefix size. A previous comment again. What is this System Heard thing for? 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 Nov 7 04:57:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02823; Mon, 7 Nov 94 04:57:42 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02817; Mon, 7 Nov 94 04:57:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03062; Mon, 7 Nov 94 04:53:11 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA13752; Mon, 7 Nov 94 04:52:43 PST Received: by nero.dcrc.com (4.1/1.34) id AA14040; Mon, 7 Nov 94 07:52:12 EST Date: Mon, 7 Nov 94 07:52:12 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411071252.AA14040@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <"941107 07:41:02*/G=ALAN/S=LLOYD/O=DCTHQ/PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/"@MHS> (ALAN.LLOYD@DCTHQ.datacraft.telememo.au) Subject: Re: (IPng) RE: (IPNG) IPV6 SYSTEM DISCOVERY: IPV6 MULTCAST TO IEEE Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 7 Nov 1994 09:40:07 +1000 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au . . . Also the Hop Cache entry for flow Ids seems wrong as flow Ids are not tied to an address, they are tied to a flow (ie different applications from that address may use different flows- (I dont like this flow stuff)) The Hop Cache seems to me an over-specification of something that should be an implementation decision. The reason I say that it should be an implementation decision is that I don't think a spec should say what a particular implementation should have in its database wrt determining where to forward a packet. If the behaviour of the router is correct from a black box point of view, the internals are irrelevant. Further, this particular specification is putting too much into one record, thereby duplicating information and fattening up the database. Specifically, flows and forwarding information belong in separate databases. According to draft-hinden-ipng-ipv6-spec-* [Sec. 6], flow labels are associated with with source addresses, and there may be multiple flows between a single source/destination address. If there were >= 2 flows between a given pair of nodes, all the next-hop/MTU/RTT stuff would be duplicated. At best, have two records: Next Hop Cache: (1) Lifetime (2) Next-hop interface (3) Next-hop media address (4) Destination IPv6 Address (5) Destination Cluster-prefix size Flow Cache: (1) Flow Label (2) Source IPv6 (3) Path MTU (why does this need to be cached at each intermediate node?) (4) Path RTT (same question (5) Pointer to a Hop Cache Record (6) Flow specific stuff Flow Cache records can exist in a many-to-one relationship with hop cache records, therefore should not be stored in the same database. . . . Regards Alan@Oz -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 Mon Nov 7 06:13:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02857; Mon, 7 Nov 94 06:13:56 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02851; Mon, 7 Nov 94 06:13:45 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05065; Mon, 7 Nov 94 06:09:27 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA20364; Mon, 7 Nov 94 06:08:59 PST Received: by nero.dcrc.com (4.1/1.34) id AA14065; Mon, 7 Nov 94 08:14:51 EST Date: Mon, 7 Nov 94 08:14:51 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411071314.AA14065@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9411071252.AA14040@nero.dcrc.com> (mad@nero.dcrc.com) Subject: Re: (IPng) RE: (IPNG) IPV6 SYSTEM DISCOVERY: IPV6 MULTCAST TO IEEE Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 7 Nov 94 07:52:12 EST From: mad@nero.dcrc.com (Mike Davis) If there were >= 2 flows between a given pair of nodes, all the next-hop/MTU/RTT stuff would be duplicated. At best, have two records: Flow Cache: (1) Flow Label (2) Source IPv6 (3) Path MTU (why does this need to be cached at each intermediate node?) (4) Path RTT (same question (5) Pointer to a Hop Cache Record (6) Flow specific stuff Caught my own contradiction here, after sending unfortunately. Path MTU and RTT obviously depend on both endpoints, though I don't know why they need to be known to intermediate systems. The main point still holds, though. -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 Mon Nov 7 06:15:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02869; Mon, 7 Nov 94 06:15:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02863; Mon, 7 Nov 94 06:15:38 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05176; Mon, 7 Nov 94 06:11:19 PST Received: from BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA20605; Mon, 7 Nov 94 06:10:57 PST Message-Id: <9411071410.AA20605@Sun.COM> From: John Day Subject: Re: (IPng) RE: RE: (IPNG) ATM..MASATAKA'S COMMENTS To: mohta@necom830.cc.titech.ac.jp Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9411061452.AA03766@necom830.cc.titech.ac.jp> Date: Mon, 7 Nov 94 09:07:55 EST Mail-System-Version: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Just imagine receiving a "worlds telephone directory" every minute >because the addressing was dynamic! > > Wow, this sounds like the ITU types that were against longer network addresses because they wouldn't fit on a business card. Take care 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 Mon Nov 7 15:54:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03402; Mon, 7 Nov 94 15:54:31 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03396; Mon, 7 Nov 94 15:54:20 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB09663; Mon, 7 Nov 94 15:50:01 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA08929; Mon, 7 Nov 94 15:49:43 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-21.dialip.mich.net [141.211.7.94]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA05017 for ; Mon, 7 Nov 1994 18:49:40 -0500 Date: Mon, 7 Nov 94 23:16:09 GMT From: "William Allen Simpson" Message-Id: <3405.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Rationale Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Well, I used to have a lot more rationale, and folks complained it was too much. I will put it back in. But the place I will put it is in the "requirements" draft. That way, those who just want to follow the step-by-step and formats can see the results easier. 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 Nov 7 15:55:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03414; Mon, 7 Nov 94 15:55:55 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03408; Mon, 7 Nov 94 15:55:44 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09931; Mon, 7 Nov 94 15:51:25 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA09117; Mon, 7 Nov 94 15:50:29 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-21.dialip.mich.net [141.211.7.94]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA05020 for ; Mon, 7 Nov 1994 18:49:42 -0500 Date: Mon, 7 Nov 94 23:23:34 GMT From: "William Allen Simpson" Message-Id: <3406.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Robert Elz > Another problem is that if a router gets the datagram, it will discover > that it is not destined for itself, and a broken implementation would > forward a duplicate to the host, wasting bandwidth. > > Of course, a broken multicast implementation might intercept multicast > packets for groups it had not joined, resulting in the same problem. > > Both problems are completely solved by the simple IP requirement that > datagrams may be duplicated. > > "Solved" is the wrong word there - you mean we can ignore > the problem because of this attribute (not requirement). > > However, if someone has a Brian Carpenter type net, with 8000 > nodes connected, and a few hundred of them happen to be routers > that decide they should forward the packet, I doubt anyone would > be happy to be told "ignore the packet burst, its just IP > behaving normally" ... > This problem occurs with _ALL_ broadcast or multicast, not just Neighbor Discovery. I am apparently of the minority view that if a hundred routers are broken, it will be discovered quickly, and then the manufacturer(s) will quickly make the fix (or suffer the consequences). > > In order to reach to that router it should react > > as a normal host on the solicited-node multicast. > > > No. Only when routing is turned off for that interface. > > ... [The host] has been receiving router > advertisments, knows its default router, and has also remembered > a backup. > ... > I have built IP implementations where the host has space for > exactly 1 remote IP address/MAC address combination at a time. > ... > Don't imagine everything is a workstation with megabytes to > waste on storing network overhead data - there are plenty of > applications using embedded processors (and no external RAM > at all) where every available bit is precious. They aren't > going away. > Yes, this is _the_ definitive problem. Therefore, I will make this change, and add the rationale. Note that this means routers will be bothered A LOT MORE on busy links. Tradeoffs, tradeoffs. All routers MUST join the solicited-nodes multicast for each address bound to each interface. 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 Nov 7 17:03:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03553; Mon, 7 Nov 94 17:03:01 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03547; Mon, 7 Nov 94 17:02:54 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21873; Mon, 7 Nov 94 16:58:34 PST Received: from databus.databus.com by Sun.COM (sun-barr.Sun.COM) id AA21724; Mon, 7 Nov 94 16:58:11 PST Date: Mon, 7 Nov 94 19:57 EST Message-Id: <9411071958.AA20781@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? Content-Length: 1212 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Mon, 7 Nov 94 23:23:34 GMT > From: "William Allen Simpson" > > I am apparently of the minority view that if a hundred routers are > broken, it will be discovered quickly, and then the manufacturer(s) > will quickly make the fix (or suffer the consequences). Count me as a member of Bill's silent minority. This is not some very obscure condition which will only come up years after systems are fielded, but a *first packet* condition which will happen in the first second of testing. But the interface between the link layer and network layer may need changing on quite a wide variety of systems, which is not good news for those systems with plug-in interfaces and drivers written by the link-layer interface vendor. As I recall asking before, could somebody who is expert on the interfaces between IP and various link layers comment on whether the link layers report upward that a packet has been received with a multicast link layer address? I have a distinct impression that Irix 5, for example, which uses a rather BSD style of internal interface, does not - but I would be delighted to be shown to be wrong. How about DLPI? 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 Nov 7 17:46:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03907; Mon, 7 Nov 94 17:46:39 PST Received: from jurassic.Eng.Sun.COM (jurassic-52) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03901; Mon, 7 Nov 94 17:46:32 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id RAA13769; Mon, 7 Nov 1994 17:41:51 -0800 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA17045; Mon, 7 Nov 1994 17:43:00 +0800 Date: Mon, 7 Nov 1994 17:43:00 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9411080143.AA17045@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: re: (IPng) routers in solicited-node? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > As I recall asking before, could somebody who is expert on the interfaces > between IP and various link layers comment on whether the link layers > report upward that a packet has been received with a multicast link > layer address? I have a distinct impression that Irix 5, for example, > which uses a rather BSD style of internal interface, does not - but > I would be delighted to be shown to be wrong. How about DLPI? Version 2 DLPI includes a "multicast indication" flag in the data structure that rides up with the received packet. This tells IP whether the packet was received via a link layer multicast. Our IPv4 implementation makes use of this. ------------------------------------------------------------------------------ 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 Nov 7 20:10:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04000; Mon, 7 Nov 94 20:10:10 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03994; Mon, 7 Nov 94 20:10:03 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12364; Mon, 7 Nov 94 20:05:44 PST Received: from comet.connix.com by Sun.COM (sun-barr.Sun.COM) id AA21645; Mon, 7 Nov 94 20:05:19 PST Received: from connix.com (localhost [127.0.0.1]) by comet.connix.com (8.6.5/8.6.5) with ESMTP id XAA17567 for ; Mon, 7 Nov 1994 23:05:17 -0500 Message-Id: <199411080405.XAA17567@comet.connix.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? In-Reply-To: Your message of "Mon, 07 Nov 1994 17:43:00 +0800." <9411080143.AA17045@kandinsky.Eng.Sun.COM> Date: Mon, 07 Nov 1994 23:05:15 -0500 From: Gary Wright Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > As I recall asking before, could somebody who is expert on the interfaces > between IP and various link layers comment on whether the link layers > report upward that a packet has been received with a multicast link > layer address? I have a distinct impression that Irix 5, for example, > which uses a rather BSD style of internal interface, does not - but > I would be delighted to be shown to be wrong. How about DLPI? BSD systems since at least the Net/2 release have an M_BCAST and an M_MCAST flag in the mbuf packet header so that the link layer can report whether the frame was received as a broadcast or as a multicast. ------------------------------------------------------------------------------ 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 Nov 7 22:07:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04056; Mon, 7 Nov 94 22:07:21 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04050; Mon, 7 Nov 94 22:07:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17469; Mon, 7 Nov 94 22:02:55 PST Received: from databus.databus.com by Sun.COM (sun-barr.Sun.COM) id AA02629; Mon, 7 Nov 94 22:02:26 PST Date: Tue, 8 Nov 94 01:02 EST Message-Id: <9411080102.AA21517@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? Content-Length: 657 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Mon, 07 Nov 1994 23:05:15 -0500 > From: Gary Wright > > BSD systems since at least the Net/2 release have an M_BCAST and > an M_MCAST flag in the mbuf packet header so that the link layer > can report whether the frame was received as a broadcast or as a > multicast. Thanks. In looking at the bsd-sources on ftp.uu.net, it seems that the M_MCAST bit is set but never checked. Irix 5 does of course support multicast, so I assume they've fixed up the code. As long as the link-layer sets the flag, clearly the IPv6 code can be sure to check it, so I feel better, anyway. Same for DLPI. 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 Tue Nov 8 00:51:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04113; Tue, 8 Nov 94 00:51:09 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04107; Tue, 8 Nov 94 00:51:01 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22802; Tue, 8 Nov 94 00:46:43 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA17322; Tue, 8 Nov 94 00:46:25 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) routers in solicited-node? To: ipng@sunroof.Eng.Sun.COM Date: Tue, 8 Nov 1994 08:47:48 +0100 (GMT) In-Reply-To: <9411080143.AA17045@kandinsky.Eng.Sun.COM> from "Bob Gilligan" at Nov 7, 94 05:43:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 468 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > report upward that a packet has been received with a multicast link > layer address? I have a distinct impression that Irix 5, for example, > which uses a rather BSD style of internal interface, does not - but > I would be delighted to be shown to be wrong. How about DLPI? Linux also has an awareness of link layer multicast, and as the person who added it, its a trivial job. It's also easy to add to things like BSD. What I'm not so sure about is NDIS. 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 Tue Nov 8 06:00:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04230; Tue, 8 Nov 94 06:00:49 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04224; Tue, 8 Nov 94 06:00:36 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29475; Tue, 8 Nov 94 05:56:16 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11662; Tue, 8 Nov 94 05:55:57 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-00.dialip.mich.net [141.211.7.73]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id IAA03268 for ; Tue, 8 Nov 1994 08:55:54 -0500 Date: Tue, 8 Nov 94 13:20:13 GMT From: "William Allen Simpson" Message-Id: <3408.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Tradeoff -- eliminate link-only multicast Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Because of the complete inability of this group to reach consensus on the use of link-only multicast, I have privately consulted with Steve Deering and others. Steve suggests that we return to the SIP (one P) solicitation format. This had a matching IPv6 Multicast Source and mapped link-layer multicast source, with the unicast target in a separate field. The tradeoff is that this requires much more CPU in hosts. The IP layer will _always_ send the packet up to ICMP. ICMP will examine the packet to decide if the datagram is destined for it. This eliminates the problem in possibly broken routers which don't correctly handle a link-layer multicast indication. Of course, it doesn't solve the problem for other broadcast/multicast packets. These will still have duplicate packets and storms. 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 Nov 8 06:50:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04270; Tue, 8 Nov 94 06:50:36 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04258; Tue, 8 Nov 94 06:50:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01133; Tue, 8 Nov 94 06:45:55 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA17913; Tue, 8 Nov 94 06:45:36 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-04.dialip.mich.net [141.211.7.77]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA06906 for ; Tue, 8 Nov 1994 09:45:32 -0500 Date: Tue, 8 Nov 94 14:02:51 GMT From: "William Allen Simpson" Message-Id: <3410.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Tradeoff -- unicast advertisement Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM During private consultation with Steve Deering in regard to the router multicast problems, he suggested that the General Advertisement be changed from multicast to unicast. This avoids waking mobiles, and also eliminates a potential re-broadcast storm by broken routers. The tradeoff is that a server with 1,000 clients will generate 2,000 messages every 5 minutes, instead of just one request/reply pair. This scaling problem is easily solved by hiding such servers behind a router. Router Advertisements will continue to be multicast. Unfortunately, it would also break the System-Heard between mobiles, requiring all mobiles to communicate through a router. 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 Nov 8 06:50:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04271; Tue, 8 Nov 94 06:50:37 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04259; Tue, 8 Nov 94 06:50:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01134; Tue, 8 Nov 94 06:45:56 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA17909; Tue, 8 Nov 94 06:45:32 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-04.dialip.mich.net [141.211.7.77]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA06900 for ; Tue, 8 Nov 1994 09:45:30 -0500 Date: Tue, 8 Nov 94 13:49:27 GMT From: "William Allen Simpson" Message-Id: <3409.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: Tradeoff -- eliminate link-only multicast Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As a consequence of the elimination of link-only multicast of unicast packets, we will not be able to send data packets in this fashion, either. Therefore, we will keep the seriously broken ARP feature of holding packets for the ARP response. Extensive rules for which packets to keep will be included (since RFC-1122 is clearly not working, and has no rationale). 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 Nov 8 07:51:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04339; Tue, 8 Nov 94 07:51:26 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04333; Tue, 8 Nov 94 07:51:19 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03850; Tue, 8 Nov 94 07:47:00 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA26407; Tue, 8 Nov 94 07:46:37 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 9 Nov 94 00:38:57 +0859 From: Masataka Ohta Message-Id: <9411081539.AA11931@necom830.cc.titech.ac.jp> Subject: Re: (IPng) Tradeoff -- unicast advertisement To: ipng@sunroof.Eng.Sun.COM Date: Wed, 9 Nov 94 0:38:55 JST In-Reply-To: <3410.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Nov 8, 94 2:02 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > During private consultation with Steve Deering in regard to the router > multicast problems, he suggested that the General Advertisement be > changed from multicast to unicast. Unicast to which server? > The tradeoff is that a server with 1,000 clients will generate 2,000 > messages every 5 minutes, instead of just one request/reply pair. Are you suggesting that we should have only a single server, the single point of failure? 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 Nov 8 08:00:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04369; Tue, 8 Nov 94 08:00:04 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04358; Tue, 8 Nov 94 07:59:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04393; Tue, 8 Nov 94 07:55:31 PST Received: from comet.connix.com by Sun.COM (sun-barr.Sun.COM) id AA27789; Tue, 8 Nov 94 07:55:10 PST Received: from connix.com (localhost [127.0.0.1]) by comet.connix.com (8.6.5/8.6.5) with ESMTP id KAA25312 for ; Tue, 8 Nov 1994 10:55:07 -0500 Message-Id: <199411081555.KAA25312@comet.connix.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? In-Reply-To: Your message of "Tue, 08 Nov 1994 01:02:00 EST." <9411080102.AA21517@databus.databus.com> Date: Tue, 08 Nov 1994 10:55:06 -0500 From: Gary Wright Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Barney Wolff writes: > Thanks. In looking at the bsd-sources on ftp.uu.net, it seems that > the M_MCAST bit is set but never checked. Irix 5 does of course > support multicast, so I assume they've fixed up the code. In the 4.4BSD-lite sources, ICMP examines M_MCAST to avoid sending ICMP errors generated from a multicast packet. ------------------------------------------------------------------------------ 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 Nov 8 08:29:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04399; Tue, 8 Nov 94 08:29:15 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04393; Tue, 8 Nov 94 08:29:04 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07211; Tue, 8 Nov 94 08:24:45 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA03885; Tue, 8 Nov 94 08:23:39 PST Subject: (IPng) Which m-cast groups to join? To: IPng Mailing list Date: Tue, 8 Nov 1994 11:23:32 -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: 551 Message-Id: <9411081623.aa21138@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM When I initialize an interface in my current code, I have that interface participate in two multicast groups: All-nodes All-hosts Now let's say I turn on ip_forwarding, or its IPv6 equivalent. If my machine is now a router, do I join A: OR B: == == == All-nodes All-nodes All-routers All-hosts All-routers This has been brought up in diluted form before. I'd like to crystallize this question: Does a router receive and process all-hosts multicast datagrams? Thanks everyone, and I hope this doesn't start a flame war. 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 Nov 8 10:32:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04492; Tue, 8 Nov 94 10:32:49 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04486; Tue, 8 Nov 94 10:32:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25644; Tue, 8 Nov 94 10:28:19 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA01627; Tue, 8 Nov 94 10:28:00 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-09.dialip.mich.net [35.1.48.210]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA26211 for ; Tue, 8 Nov 1994 13:27:50 -0500 Date: Tue, 8 Nov 94 17:21:11 GMT From: "William Allen Simpson" Message-Id: <3411.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) embedded IEEE Addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It was very nice of KRE to read the Design Requirements draft, although 2 years ago when we were actually designing would have been a better time. Rather than deal with the entirety of his comments, I find that the final comment sums up his objections nicely: > From: Robert Elz > 9. Self-configuration > > An IPv6 local-use unicast address MAY be combined with a cluster- > prefix learned from Router Advertisements to form a routable IPv6 > Address. > > If there was a place for capitals anywhere, it would be MUST NOT > here - a node that determines its own address both defeats my > addressing plan, which almost certainly won't be using media > addresses in the low 48 bits of IPv6 addresses (way too wasteful), > and allows nodes to connect to my network, and operate there, > without having obtained my consent in advance. I may be willing > to grant a blanket "anything can plug in and work" permission, > but I'm just as likely to demand that everyone wanting to plug > in to my cable must come to see me, cap in hand, and bribe > under the table... Manufacturers absolutely must not defeat > my little side graft by providing mechanisms by which nodes can > get past my barriers (if I don't want them to). > This is really a topic for the IESG at this point. I will note that historically, SIP(P) did this with a routing header. However, the IPNG Directorate, in its infinite wisdom, decided that they wanted to be able to combine IEEE Addresses in the lower part of the IPv6 Addresses, just like IPX. It is my understanding (from Deering) that this was a principle criterion for selecting 128-bit addresses. If KRE would kindly express his unhappiness directly to the IESG, perhaps they would take his recommendation into account. Alternatively, I would be happy to sponsor a duel to the death between KRE and Greg Minshall. If this is resolved to an alternative, I assure everyone that the technique will be changed in this 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 Tue Nov 8 11:42:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04534; Tue, 8 Nov 94 11:42:33 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04528; Tue, 8 Nov 94 11:42:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06684; Tue, 8 Nov 94 11:38:06 PST Received: from mulga.cs.mu.OZ.AU by Sun.COM (sun-barr.Sun.COM) id AA13014; Tue, 8 Nov 94 11:33:12 PST Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08982 Wed, 9 Nov 1994 06:29:35 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) embedded IEEE Addresses In-Reply-To: Your message of "Tue, 08 Nov 1994 17:21:11 GMT." <3411.bill.simpson@um.cc.umich.edu> Date: Wed, 09 Nov 1994 06:28:17 +1100 Message-Id: <12495.784322897@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 8 Nov 94 17:21:11 GMT From: "William Allen Simpson" Message-ID: <3411.bill.simpson@um.cc.umich.edu> Rather than deal with the entirety of his comments, I find that the final comment sums up his objections nicely: I have dealt with your comments on that particular comment or mine in a separate message. However, if you believe that that comment (which related to host address configuration) can in any way "sum up" the rest of my comments on the draft, which were partially on documentation style (and I agree, not really worth a lot of debate), and mostly on how address resolution should be done, then I'd suggest that you go back and read again. This time don't skip to the last paragraph and assume its a summary of the message. Most of my message was objecting to any attempt to replace ARP with some "higher than IP" mechanism - and I don't much care what that mechanism would be. Address resolution belongs in the link level, it is media dependant, attempting to hide that changes none of the facts - some kind of ICMP message doesn't somehow automatically solve X.121 resolution. How hosts come by their own addresses has nothing to do with this. 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 Tue Nov 8 14:57:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04812; Tue, 8 Nov 94 14:57:23 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04760; Tue, 8 Nov 94 14:12:12 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01167; Tue, 8 Nov 94 14:07:52 PST Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA06246; Tue, 8 Nov 94 14:07:01 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02606; Tue, 8 Nov 1994 21:28:09 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15851; Tue, 8 Nov 1994 21:28:07 +0100 Message-Id: <9411082028.AA15851@dxcoms.cern.ch> Subject: Re: (IPng) NOSI To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 8 Nov 1994 21:28:07 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <3355.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Oct 27, 94 06:03: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 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM While I was off the network for few days, Steve Parker of Sun kindly set up a majordomo list for the NOSI discussion. Not everybody wants this discussion off the main list, but it may help some people's overload. *** If you want to be on this list, you will need to subscribe. The nosi list is an open, automatically maintained mailing list. Complete list management instructions are attached. To subscribe send a message which contains in the message body: subscribe nosi to the address majordomo@sunroof.eng.sun.com This will subscribe the address from which you sent the request to the mailing list. Brian Carpenter ===================================================================== LIST MANAGEMENT INSTRUCTIONS ===================================================================== SUBSCRIBING =========== To subscribe to the nosi list, send the following in the body (not the subject line) of an email message to "Majordomo@sunroof.eng.sun.com": subscribe nosi This will subscribe the account from which you send the message to the nosi list. If you wish to subscribe another address instead (such as a local redistribution list), you can use a command of the form: subscribe nosi other-address@your_site.your_net If you expect to be sending contributions to the list from multiple addresses, please notify nosi-owner@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.) UNSUBSCRIBING ============= To un-subscribe from nosi, send the following in the body (not the subject line) of an email message to "Majordomo@sunroof.eng.sun.com": unsubscribe nosi This will unsubscribe the account from which you send the message. If you are subscribed with some other address, you'll have to send a command of the following form instead: unsubscribe nosi other-address@your_site.your_net If you don't know what address you are subscribed with, you can send the following command to see who else is on the list (assuming that information isn't designated "private" by the owner of the list):o who nosi If you want to search non-private lists at this server, you can do that by sending a command like: which string This will return a list of all entries on all lists that contain "string". HELP ==== To find out more about the automated server and the commands it understands, send the following command to "Majordomo@sunroof.eng.sun.com": help If you feel you need to reach a human, send email to nosi-approval@sunroof.eng.sun.com POSTING ======= To post a message to the list, send it to nosi@sunroof.eng.sun.com. DO NOT SEND ADMINISTRATIVE QUERIES ABOUT THE LIST TO nosi ========================================================= 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 nosi-approval@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 Nov 8 21:52:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05356; Tue, 8 Nov 94 21:52:20 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05350; Tue, 8 Nov 94 21:52:09 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27828; Tue, 8 Nov 94 21:47:50 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA27209; Tue, 8 Nov 94 21:47:31 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm037-17.dialip.mich.net [141.211.7.90]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id AAA14346 for ; Wed, 9 Nov 1994 00:47:29 -0500 Date: Wed, 9 Nov 94 04:16:34 GMT From: "William Allen Simpson" Message-Id: <3415.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Tradeoff -- eliminate link-only multicast Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarding private email with permission: > In-Reply-To: Your message of "Tue, 08 Nov 1994 13:20:13 GMT." > <3408.bill.simpson@um.cc.umich.edu> > Date: Tue, 08 Nov 1994 09:24:06 -0500 > From: "Perry E. Metzger" > > Frankly, if we are abandoning ARP, the link-only multicast is > better. My problem was with the fact that completely new code would be > needed everywhere -- as long as you need it at all, I prefer to do it > the way you suggested originally. Every completely new mechanism is > going to have unexpected problems, which is why I prefered not to > leave ARP behind, but as long as we are leaving it behind... > > .pm > ------------------------------------------------------------------------------ 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 Nov 8 23:15:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05446; Tue, 8 Nov 94 23:15:11 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05440; Tue, 8 Nov 94 23:15:03 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01283; Tue, 8 Nov 94 23:10:45 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA10548; Tue, 8 Nov 94 11:19:09 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29272; Wed, 9 Nov 1994 06:15:28 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) embedded IEEE Addresses In-Reply-To: Your message of "Tue, 08 Nov 1994 17:21:11 GMT." <3411.bill.simpson@um.cc.umich.edu> Date: Wed, 09 Nov 1994 06:15:24 +1100 Message-Id: <12490.784322124@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Tue, 8 Nov 94 17:21:11 GMT From: "William Allen Simpson" Message-ID: <3411.bill.simpson@um.cc.umich.edu> However, the IPNG Directorate, in its infinite wisdom, decided that they wanted to be able to combine IEEE Addresses in the lower part of the IPv6 Addresses, just like IPX. It is my understanding (from Deering) that this was a principle criterion for selecting 128-bit addresses. I think you misunderstand. I have no objection to the ability to use IEEE addresses as part of IPv6 addresses, nor do I have a problem with IPv6 addresses being large enough to allow that. I certainly appreciate that a lot of people will want to run things exactly that way. What I do object to is implementing a design where that is the only way that addresses can be assigned. If the end user hosts set about constructing their own addresses this way, then that is what you are doing. The only alternative would be manual configuration on every host, which no-one wants. The addr conf group, with Dave Katz' (not quite) draft is quite adequately solving this problem in a way that will both work, and meet all objectives that I have heard. I wish you'd simply remove references to address assignment from your discovery docs and leave addrconf to define the way that IPv6 does this. Whatever the IPng directorate thought about all of this, one thing they certainly did was charter addrconf to do precisely this work. Finally, last I heard, Greg Minshall and I had no disagreements on this topic. 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 Wed Nov 9 08:49:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05834; Wed, 9 Nov 94 08:49:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05828; Wed, 9 Nov 94 08:49:06 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16572; Wed, 9 Nov 94 08:44:47 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA10117; Wed, 9 Nov 94 08:43:13 PST Subject: (IPng) Anyone notice this? To: Dan McDonald Date: Wed, 9 Nov 1994 09:37:28 -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: 858 Message-Id: <9411091437.aa22236@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From RFC 1700, "Assigned Numbers" RFC 1700 Assigned Numbers October 1994 ADDRESS FAMILY NUMBERS Several protocols deal with multiple address families. The 16-bit assignments are listed here. Number Description Reference ------ ---------------------------------------------------- --------- 0 Reserved 1 IP (IP version 4) 2 IP6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 8 E.164 (SMDS, Frame Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 65535 Reserved And I thought 24 was IPv6's address family. 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 Wed Nov 9 11:19:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05961; Wed, 9 Nov 94 11:19:23 PST Received: from jurassic.Eng.Sun.COM (jurassic-51) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05955; Wed, 9 Nov 94 11:19:09 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA15326; Wed, 9 Nov 1994 11:12:54 -0800 Date: Wed, 9 Nov 1994 11:12:54 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411091912.LAA15326@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng Implementors Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Attached are the minutes from the October IPng Implementors Meeting Bob _____________________________cut here____________________________________ Robert M. Hinden Sun Microsystems, Inc. November 1994 IPng Implementors Meeting Minutes Cambridge, MA, USA 10-12 October 1994 INTRODUCTION This document is the minutes of the IPng Implementors Meeting held at Digital Equipments Corporation's Cambridge Research Laboratory on October 10-12, 1994. The meeting was hosted by Jim Bound of Digital Equipment Corporation. These meeting minutes were created based on notes taken by Frank Solensky, Ross Callon, and Robert Hinden. The implementors meeting discussed a variety of topics. The result of the meeting, as documented in these minutes, is a recommendation for changes and clarifications in the current IPng specifications made to the IPng working group. ATTENDEES Rob Austein / Epilogue Technology Scott Bradner / Harvard Jim Bound / Digital Dave Bridgam / Epilogue Technology Tony Buno / Penril Duan Butler / Network Systems Ross Callon / Bay Networks Ping Chen / Apple Alex Conta / Digital Mike Davis / Penril Steve Deering / Xerox Parc Bob Gilligan / Sun Microsystems Heather Gray / Digital Dimitry Haskin / Bay Networks Marc Hasson / Mentat Bob Hinden / Sun Microsystems Richard Fox / Netcom Dave Katz / Cisco hinden [Page 1] IPng Implementors Meeting Minutes November 1994 Joachim Martillo / Penril Dan McDonald / NRL Julie Myers / Network Systems Erik Nordmark / Sun Microsystems Charlie Perkins / IBM Yakov Rekhter / IBM Bill Simpson / Consultant Frank Solensky / FTP Brad Stone / HP Sue Thomson / Bellcore Bernie Volz / Process Software Warren Wagner / Process Software Justin Walker / Apple hinden [Page 2] IPng Implementors Meeting Minutes November 1994 MONDAY The meeting started with a call for agenda items from the meeting attendees. The following agenda resulted: Addressing Model Cluster Addresses Neighbor Interactions ICMP Issues Auto-Addressing Transition and Testing Prototype Testing and the "6-bone" Domain Name System (DNS) Turning Off IPv4 Text Representation of Addresses Security Mobility MTU Size APIs for IPv6 Packets Greater Than 64K MIBs and Effects on SNMP Header Compression Latency Elimination for "ARP" (or ARP replacement) Next Meetings Addressing Model ---------------- The issue of assigning an IPv6 address per node vs. per interface was discussed. Deering explained a problem that arises with the address- per-node model with respect to originating multicast packets: when using a multicast routing algorithm that delivers multicasts via a per- source tree (such as DVMRP, MOSPF, or PIM Dense), a host must send a copy of a multicast packet on all those interfaces identified by the source address in the packet; on the other hand, when using a multicast routing algorithm that delivers multicast via a single tree or a per- group tree (such as CBT or PIM Sparse), a host must send only one copy of a multicast packet. Thus, correct host behavior depends on the particular multicast routing algorithm in use, which is very undesirable. The address-per-interface model does not have this problem (a host always sends just one copy of a multicast packet). Thus, the group decided to recommend staying with the IPv4 model of per-interface addresses. Multiple addresses can be assigned to an interface. A single link which has been assigned multiple IPv6 subnet numbers would implicitly allow their connected hosts to transmit packets with the subnet prefix of the hinden [Page 3] IPng Implementors Meeting Minutes November 1994 source address to be set to any one of the subnet numbers assigned to the link on which the packet is sent. The addressing architecture document should add that this recommendation does not prevent the following configurations from being supported: o A single address may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as a single aggregate and hides the the details of this aggregation from the Internet layer. This is useful for load-sharing over multiple physical interfaces. Only one (virtual) interface should be visible to IP. o Routers may have unnumbered interfaces (i.e., interfaces with no assigned IPv6 addresses) for point-to-point links, to reduce the number of interfaces that must be assigned unique addresses. Cluster Addresses ----------------- While there is some general agreement that cluster addresses, that is, addresses with unspecified (zero-valued) low-order address parts, might be useful in the support of mobile hosts, policy routing, and, possibly, other functions, there is still uncertainty on how they would be assigned and used. Another question that needs further consideration is how a cluster address might be used as the destination when the source is within the same cluster as opposed to outside. Further, it was noted that cluster destination addresses would become an exception to the rule of limiting the assignment of a specific IPv6 address to a globally unique interface. The group recommends that cluster addresses should be considered "reserved" until a specific proposal for using cluster addresses is developed. Neighbor Interactions --------------------- ARP over ICMP vs UDP: The periodic advertisement messages issued by Router Discovery provides a host the means of resolving the link-level address of a neighboring router, but there still needs to be a way for routers to resolve hosts' link-level addresses, and for hosts to resolve neighboring hosts' addresses when no router is available. hinden [Page 4] IPng Implementors Meeting Minutes November 1994 At the July IETF meeting it was suggested that the problems associated with updating or generalizing ARP for IPv6 outweighed the potential benefits. Some of the reasons cited were: o Many installed implementations ignore fields that would have to change. o ARP packet format doesn't allow for extension (e.g., authentication). o No lifetime field in ARP packets to bound how long information may be retained After an extended discussion trading off the alternatives of updating ARP or providing the ARP functionality over UDP or ICMP, the meeting attendees were approximately equally divided between the three options but no strong opposition to any of them readily apparent. The group's recommendation was that work would continue with Bill Simpson's draft describing ARP functionality over ICMP with Jim Bound and Alex Conta providing off-line feedback on his concerns with the document in its present form. In summary the group agreed that we should retain the current ARP model, but implement it with extensions to ICMP. Host knowledge of prefixes: An IPv6 host will learn the subnet prefixes to be used on its packets from the routing advertisement messages it receives through Router Discovery, then using "longest match" against its address cache. Routers must be able to send these prefixes. Scope of discovery: The group recommended removing the description of service location extensions from the discovery document since much of the same functionality would be provided by DHCP. "System heard" messages, beneficial to mobile and radio IP, are still under consideration: some feel that this should remain a link-layer feature and implemented only where it would be used while others that want the widest possible support for it would prefer to see this within IPv6. hinden [Page 5] IPng Implementors Meeting Minutes November 1994 TUESDAY ICMP Issues ----------- A rather wide variety of ICMP-related issues came up on second day. The major points were: o ICMPv6 would indicate "packet too big" as a separate error message, rather than being included as one of the causes of a "destination unreachable" error. By using a separate ICMP message type, it would eliminate the need for special-case handling of the "packet too big" subtype of Destination Unreachable messages, such as allowing only such messages to be sent in response to multicasts. o The ICMPv6 specification should add that the 16-bit error pointer can in theory point beyond the end of the packet when the error point is beyond what can fit in the 576-byte limit of an ICMP error message. o The use of a wider selection of error codes was discussed as an alternative to using a pointer to an error byte but the general consensus seemed to be with the latter: there wasn't a strong feeling that we'd be able to come up with a sufficiently comprehensive list of error conditions. o ICMP "redirects" are to be left as described in the current IPv6 ICMP specification. Question was raised about fragmentating Multicast datagrams? This would require a "Pkt too big message" to be sent to source. Steve Deering said he thinks MTU discovery should be done on multicast links. Others want to have routers do fragmentation for multicast traffic. Group agreed to allow pkt to big in response to multicast. Routers should not fragment multicast datagrams. Issues was raised about how much payload to send in response to ICMP error messages. Fill up to 576 or all of packet? The group decided to keep the 576 limit. Pointer could point off end, The specification needs to make this very clear. Auto-Addressing --------------- Dave Katz provided an overview to a document he plans to make available in the next week. When the IPv6 host first comes up, it sends out an ICMP request message to a multicast address to learn its address. The hinden [Page 6] IPng Implementors Meeting Minutes November 1994 locally-administered server (possibly a router) could then apply the degree of administrative torque over the IPv6 address assignments that is appropriate for the site; for example, determining if the local host will be allowed to renew its address assignment or if address lifetimes are advisory or mandatory. It could provide a simple mapping of hardware addresses to network address (e.g., like IPX) or use DHCP in a more complex environment -- the main point is that the server hides this level of detail from its hosts/clients. The original proposal used 16-bit timers for address lease times; the group recommended 32-bit timers based on DNS experience. There should also be a reserved value (all 1's) to indicate an assignment time of "infinity". The scope of the multicast request should be limited to an intra-link hop. There are still some issues that need to be dealt within the areas of handling more than one ARP response from the address server, determinism (especially where DNS configurations will also occur) and address lease times (e.g., when an address change occurs, must existing TCP connections be broken?). This may also suggest the addition of a "create" operation for DNS but would open a number of security issues that would have to be dealt with before it could be deployed. Transition and Testing ----------------------- Bob Gilligan lead a discussion on the Simple Internet Transition (SIT) document which included translating routers and IPv4/IPv6 encapsulation and tunneling. Forms of IPv6 Address IPv4-compatible IPv6 address 0:0:0:0:0:FFFF: IPv4-mapped IPv6 address 0:0:0:0:0:0: IPv6-only address Note: there are no plan to map IPv4 multicast into IPv6) Bill Simpson commented that he doesn't like/want translation. Scott Bradner suggested that people will do it and we need to tell them how to do it in a manner that will interoperate. Ross Callon presented the problem with having two address prefixes which are used in translation. When translating from IP to IPv6, the router is supposed to know which address prefix (0:0:0:0:0:0 or 0:0:0:0:0:FFFF) to use, based on the type of end system. However, in practice it is likely to be impractical for the router to know which prefix to use. hinden [Page 7] IPng Implementors Meeting Minutes November 1994 This implies that in some cases the router may use the wrong prefix (particularly use all zeros where the other would be appropriate). He proposed that a single prefix be used in translation. This would require additional code in all hosts. An alternative would be to have IPv6-only routers at administrative boundaries be able to, where necessary, change the prefix used within the IPv6 packet (even when the packet is not being translated). This would require additional complexity in the translating routers. IPv6 Deployment without Routers: This part of the discussion focused on the question of how two dual hosts (capable of exchanging both IPv4 and IPv6 packets) would communicate when the router(s) between them were only capable of forwarding IPv4 packets: some felt encapsulation would encourage a faster transition to IPv6 throughout the net, others felt this was a disadvantage if it became necessary to make changes later on. Bill said he thought that hosts should not perform encapsulation. IPv6 hosts should not be able to communicate with other off-subnet IPv6 hosts until the routing infrastructure between them was upgraded to IPv6. For now the group agreed that the document will be left as-is with further discussion to take place on the mailing list. There was some agreement that the some of the disagreement on the transition mechanisms were based on what the default values of switches which are used to control the mechanisms. The group agreed that it is very important to explicitly documenting the "sending rules" (i.e., what format of packet to send in what circumstances) in the transition mechanisms spec. IPv4 Route Leaking: One of the transition documents needs to describe how routes to networks within a IPv4-dominant area will be announced to routers on the border of or within an IPv6-dominant area. This needs to include plans for an IPv6-only domain that leaks IPv4 routing information as well as the IPv6-only domain that doesn't. Dimitry Haskins of Wellfleet volunteered to write this up. Prototype Testing and the "6-bone" ---------------------------------- Interoperability testing between prototype implementations will start off much in the same way that the "mbone" work started by encapsulating hinden [Page 8] IPng Implementors Meeting Minutes November 1994 IPv6 packets within IPv4 packets and sending them off to known locations that will decapsulate. The resulting topology between these machines will be called the "6-bone" (aka "G-bone" in reference to S.Deering occasionally misreading his handwriting). Bob Hinden offered to coordinate these efforts. Some testing of direct connectivity between prototypes is also planned to occur sometime in March, 1995; around the time of (or as part of) Sun's NFS Connectathon. Domain Name System (DNS) ------------------------ S.Thomson had sent out a draft proposal on DNS revisions shortly before the implementor's meeting. Those who had seen it indicated that it looked good and close to what's needed; it should also include tie-ins to the DNS security and DNS-PEM working group efforts. In order to avoid creating a dependency on DNS server support for AAAA records, early implementations should be able to fall back on using some form of local file support (i.e. /etc/hosts) to provide the name-to- address mapping. Turning Off IPv4 ---------------- No specific date was suggested for turning off IPv4 routing: S.Bradner, the IPng Area Director, suggested that the question of when or if it occur would fall under the domain of the TACIT Working Group. Text Representation of Addresses -------------------------------- The group reviewed the current formats for typing IPv6 address and agreed to keep the current techniques. hinden [Page 9] IPng Implementors Meeting Minutes November 1994 WEDNESDAY Security -------- Scott Bradner talked about security requirements in the IPng Recommendation. Implementation of security is mandatory. Thus an implementation must be capable of doing both authentication and privacy (encryption). It is not mandatory to actually use it, it is only mandatory to implement it. In fact, the authentication header support can be shipped. However, the encryption cannot be. Just stripping the code is not enough. You cannot, for example, just strip the function. The issue behind this is that currently export of most confidentiality mechanisms (e.g. encryption) from many countries (e.g. all of NATO, Australia, Japan, New Zealand, some other countries) requires the exporter to obtain an export license ahead of time. The difficulty in obtaining such licenses varies on a country-by-country basis. Use of confidentiality mechanisms is reportedly licensed in some countries (e.g. France, Russia). The US government has been known to grant such licenses in the past. Export of "authentication without confidentiality" does not appear to be export-controlled or usage- controlled in any country. Scott Bradner suggest sending comments in response to last call if unhappy with security "mandatory" requirements. Ran Atkinson was unable to attend due to illness.. Bob Hinden read out a message sent by Ran. The relevant contents from his message are as follows: "1) Because of the pressure to put out IPv6 specs in December, I plan to take the packet header agreed to at the Toronto IPv6 Implementors Meeting and revise the "IPv6 Encapsulating Security Payload" spec. I will then put that spec out as a revised I-D. I also plan to add more text to the "How to use DES-CBC with IPv6 ESP" appendix to make it more explicit (e.g. regarding DES initialization vectors). 2) Comments on the other drafts are solicited, preferably via email to me with a specific proposed change and a brief explanation of why the change is proposed. Comments to the IPv6 list are also welcome of course. 3) [Controversial] I'd suggest that the _implementation_ of security be mandatory inside the kernel, but that use of the security be largely left up to individual applications (e.g. an app might request some kind of security via a socket option). hinden [Page 10] IPng Implementors Meeting Minutes November 1994 However, I'd suggest that we make (at least) authentication of ICMP redirects, TCP SYNs, and other security-critical control messages mandatory WHENEVER a security association exists for the source/destination pair. If no security association exists, then there won't be any shared keys and so it will not be possible to add security to any packets even though it is supported by the networking implementation. [NB: We will need to reach agreement on which packets are considered "security critical". I consider Bellovin's paper in ACM CCR (cited in my I-Ds) to be required reading before that agreement can be reached.] At least until the Key Mgmt WG specifies an Internet Key Mgmt Protocol (IKMP), creating such security associations is a manual process (i.e. the admin types the security association data in on the console). Hence users who don't wish to use security at all simply never bother to create any such associations. Users who do create those associations will get basic security protections. Users who do create those associations AND either have applications which request/use security or have an operating system which has been configured to secure applications without specific requests will get the security they desire. Once we have a real IKMP, then systems which implement IKMP will automatically get basic security whenever they communicate with other hosts implementing IKMP and get full security whenever they communicate with other hosts implementation IKMP provided that they have apps that request security. I believe that this is a good balance between making security available, using security to protect the network infrastructure, and not making users pay the performance cost per packet when they do not wish to use it. Note that I am proposing requiring that kernels always implement security, just that it won't be used for any packets unless or until security associations exist. This costs only a single (IF Relevant-Security-Association exists) check per packet when no security association exists. This should be discussed on the list in more detail, but the above is my current view. The IPv6 Security Architecture document contains some proposed requirements already and will be revised to add clarity later this month. I urge that everyone read that and comment about it on the ipng mailing list." There is an existing socket interface API document, which does not say anything about security. We would like to add security knobs to this hinden [Page 11] IPng Implementors Meeting Minutes November 1994 API. There is already a GSS API for security. however, this may be overkill for IPv6 (the spec is 200+ pages). What we want is simple hooks for requesting authentication and/or privacy. Mobility -------- There are two proposals (Charlie Perkins and Bill Simpson). Charlie presented what he believes are the advantages of his proposal: He is proposing and end to end options type, to send a "binding", which is roughly: {} The corresponding hosts (hosts which are talking to mobile hosts) can maintain the bindings between the mobile host's address and the "care of address", which is where the mobile host is currently. The goal of this is to make use of the home agent a rarity. In the case that the mobile host is the one initializing communications, it may be possible to avoid use of the home agent at all. Given the ability with IPv6 to auto-pick-up-an-address, the mobile host could obtain a temporary address wherever it moves, and be its own "foreign agent". Packets could be transmitted using either encapsulation or source routing. A stripped down encapsulation may also be used. Suggest that the mobile host send the "here I am" packet to the cluster address corresponding to its original address. Bill Simpson began to make a strong argument over patents / intellectual property. Charlie has a patent (owned by IBM) which is already granted, but Charlie says that his patent does not relate to this stuff. Charlie has informed the chairs of the working group of the patent, the working group informed the area director, who informed the IESG, and believes that IBM will make the patent freely available. Bob Hinden and Ross Callon pointed out cases where companies really need to obtain patents. Thus we should not be "blaming" anyone for getting a patent. Scott Bradner points out the policies for Internet Standards require that the patent holder make the patented technology available in a reasonable and non-discriminatory manner. Thus we need to get a signed letter from IBM making this statement. Bill believes that IP mobility has circumvented the patent, by using a hinden [Page 12] IPng Implementors Meeting Minutes November 1994 tunnel to a foreign agent. This also eliminates encapsulation on the last hop, which is important given that last hops to mobile hosts are sometimes low bandwidth. Bill also thinks that the patent is not valid. This issue is best resolved in this individual case by getting a letter from IBM giving up rights to this patent. In the general case, patent issues are going to continue to be nasty. Bill's approach is similar to the IPv4 method. He does not use an end to end option. He uses a remote redirect instead (to avoid the extra hop via the home agent). The Mobile IP group has spent a lot of time considering many different proposals. It is highly desirable to avoid this same deadlock with IPv6. However, it appears that the mobile IP group is finally reaching conclusion. Scott Bradner asked that the issue be tabled in this meeting due to the conflict over the patent so no resolution was reached. MTU Size -------- Two issues were discussed. 1) The Required MTU that links have to carry, and 2) The minimum overall packet size that host has to be able to reassemble. The group agreed that the minimum reassembly buffer size should be raised to 1500 bytes so as to avoid a number of problems associated with DNS and shorter packets. The minimum MTU remains at 576 bytes. APIs for IPv6 ------------- Alex Conta raised a few issues which could be taken up on the mailing list. We have added a mechanism to allow applications to retrieve and/or send source routes and flow labels. Question was raised about being able to switch flow IDs during a TCP connection? For example, an application may decide that it needs a different quality of service in the middle of a conversation. Thus, we might have a "change flow label" command across an API. The kernel needs to pick flow IDs, in order to assure coordination of flow IDs across multiple applications within a single host. Making APIs for IPv6 identical to the API for ATM was suggested, but did not elicit wide support. hinden [Page 13] IPng Implementors Meeting Minutes November 1994 Effects on routing Protocols: The IESG Routing Area Director should make sure that extension of IP routing protocol for IPv6 are being worked on. Header Sequence Rules: The IPng speciation in effect essentially says "should", and this is the right thing, it should specifically say "SHOULD". What should an implementation do if fields are out of order? The specification does not say anything about this at this time. Reversing Source Routes: What are the host rules? What about when a router generates an ICMP response. Bill Simpson said he doesn't like reversing source routes, that this is not the right approach for mobility, nor for authenticated packets. However, if source routes are used for policy reasons, they should be reversed. One option would be to have two types of source routes, one of which is reversible and one of which is not. With ICMP, there is a concern that the reply might not get back if the source route was required to get the packet through (e.g., to send a packet via a path which for policy reasons will agree to forward the packet). The rough consensus of the group was to include a bit in the source route which provides a hint from the source host thought indicating that the source route should be reversed on resulting ICMP packets. The justification is that the entity which picks the source route knows why it is picking the source route, and therefore should have a better idea whether it needs to be reversed or not. Packets Greater Than 64K ------------------------ One option here is to have a non-linear length field, so that a 16 bit field can be used to indicate packet lengths with one byte granularity for packets up to length 32K, and then (if the high order bit is "1") use a larger granularity for the upper half of the field values. Another option is to have the value "zero" have a special meaning. Thus a length of zero means that there is an end to end option which has the real length. The group decided to stay with the "zero" case approach. There is an issue raised by Bill Simpson regarding the effect that long packets has on error checking, both in terms of the strength (hamming distance) of CRCs, and in the probability that the packet actually get through without an error. Steve Deering pointed out that the people who want this feature will use them over reliable (i.e., retransmitting) hinden [Page 14] IPng Implementors Meeting Minutes November 1994 lower layers which causes these issues to be inapplicable. MIBs and Effects on SNMP ------------------------ We need MIBs and volunteers to do MIBs. Much of this work is updating existing IPv4 MIBs. There is an issue regarding human-comprehensible ways to represent IPv6 addresses. SMI needs to be updated to be able to represent IPv6 addresses. The Network Management AD should be poked about this. Frank Solensky volunteered to do an update of RFC1213. Header Compression ------------------ Bill Simpson has written an Internet Draft. This compresses as much as he could manage. Jon Crowcroft has an alternative which is a delta on Bill's draft, which Bill and/or Jon will forward to the IPng mailing list. Latency Elimination for "ARP" (or ARP replacement) -------------------------------------------------- A proposal was also made by Alex Conta that would cause the first packet sent to an peer with no MAC-layer address resolution in the ARP cache to be sent to a multicast address and encapsulate an option or payload field that, at the same time, presents the ARP request to other hosts and avoiding the additional delay it would take between sending out a separate ARP request and waiting for the reply. Using a TTL set to 1 when the address prefix was unknown was also considered as an alternative; this would have required some definition or configuration of ICMP Time Exceeded suppression. Another option is to multicast the packet instead of first sending an address resolution request. We need to multicast an ARP request anyway, why not piggyback the data packet? We don't want to multicast subsequent packets. The questions was raised asking if the solicitation should be sent to an "all nodes multicast", or to some special multicast which is a hash of the address (so that not all nodes need to listen to it). Another issue raised was that the additional bytes in the packet could create fragmentation problems. hinden [Page 15] IPng Implementors Meeting Minutes November 1994 After much discussion, it was suggested that we do not need a complex protocol to solve this, given that it is not a particularly serious sub-optimality in the current Internet. The group agreed to stick with the current mechanism. Next Meetings ------------- There will be two IPng implementors meetings at the December IETF. The first will be on Sunday December 4, 1994 at 1PM. The second will be December 9 at 9AM. hinden [Page 16] ------------------------------------------------------------------------------ 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 Nov 9 12:28:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06045; Wed, 9 Nov 94 12:28:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06035; Wed, 9 Nov 94 12:28:32 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25595; Wed, 9 Nov 94 12:24:13 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AB18356; Wed, 9 Nov 94 12:23:45 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA29272; Wed, 9 Nov 94 10:38:26 -0800 Received: by xirtlu.zk3.dec.com; id AA10303; Wed, 9 Nov 1994 13:38:21 -0500 Message-Id: <9411091838.AA10303@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: Your message of "Tue, 08 Nov 94 11:23:32 EST." <9411081623.aa21138@sundance.itd.nrl.navy.mil> Date: Wed, 09 Nov 94 13:38:14 -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 >Now let's say I turn on ip_forwarding, or its IPv6 equivalent. If my >machine is now a router, do I join > A: OR B: > == == == > All-nodes All-nodes > All-routers All-hosts All-routers This is one of the IPv6 discovery decisons we all await. Makes it hard to write code don't it. /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 Nov 9 14:04:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06129; Wed, 9 Nov 94 14:04:49 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06123; Wed, 9 Nov 94 14:04:42 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11617; Wed, 9 Nov 94 14:00:23 PST Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA03561; Wed, 9 Nov 94 13:59:16 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 9 Nov 94 17:10:11 +0900 From: Masataka Ohta Message-Id: <9411090810.AA14392@necom830.cc.titech.ac.jp> Subject: Re: (IPng) embedded IEEE Addresses To: ipng@sunroof.Eng.Sun.COM Date: Wed, 9 Nov 94 17:10:10 JST In-Reply-To: <3411.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Nov 8, 94 5:21 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > However, the IPNG Directorate, in its infinite wisdom, decided that they > wanted to be able to combine IEEE Addresses in the lower part of the > IPv6 Addresses, just like IPX. It is my understanding (from Deering) > that this was a principle criterion for selecting 128-bit addresses. Are there any document which states reasoning on 128bitness with some technical evaluation? 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 Nov 9 14:18:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06172; Wed, 9 Nov 94 14:18:00 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06166; Wed, 9 Nov 94 14:17:53 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13677; Wed, 9 Nov 94 14:13:33 PST Received: from decvax.dec.com ([16.140.0.3]) by Sun.COM (sun-barr.Sun.COM) id AA05703; Wed, 9 Nov 94 14:09:46 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16075; Wed, 9 Nov 1994 16:40:21 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA01635; Wed, 9 Nov 1994 16:40:16 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA23618; Wed, 9 Nov 1994 16:16:45 -0500 Message-Id: <9411092116.AA23618@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, bsimpson@morninstar.com Subject: Re: (IPng) Tradeoff--s In-Reply-To: Your message of "Tue, 08 Nov 94 14:02:51 GMT." <3410.bill.simpson@um.cc.umich.edu> Date: Wed, 09 Nov 94 16:16:44 -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" After consulting with... tradeoffs...... Thanks Bill. The debate that lasted almost one month after the implementors meeting has a positive aspect in discussing several new ideas as well as going once more deeply in some of the principles that are IP's foundation. We can go back now and focus on the other issues that are ahead of us. 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 Nov 9 15:14:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06297; Wed, 9 Nov 94 15:14:36 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06291; Wed, 9 Nov 94 15:14:28 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23194; Wed, 9 Nov 94 15:10:09 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA16404; Wed, 9 Nov 94 15:08:39 PST Received: from abelia.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA17766; Wed, 9 Nov 1994 17:16:34 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA06867; Wed, 9 Nov 1994 17:16:29 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA23682; Wed, 9 Nov 1994 16:52:57 -0500 Message-Id: <9411092152.AA23682@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, Christian.Huitema@sophia.inria.fr Subject: Re: (IPng) routers in solicited-node? In-Reply-To: Your message of "Thu, 03 Nov 94 12:10:28 +0100." <199411031110.AA15234@mitsou.inria.fr> Date: Wed, 09 Nov 94 16:52:56 -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: Christian Huitema Yup. I believe that this is the big problem with making ARP and initial transmission simultaneous. As long as the address is not "resolved" (i.e. not cached), there are a few solutions which work: 1) Send packet to the "preferred router" (obtained through router discovery), get a redirect if you missed the target. ........ 2) Send packet to some mcast address, e.g. "all hosts", ........ 3) Queue the packet, sends "solicitation" to the "all hosts", ........ Christian Huitema -------------------------- Two other ideas were discussed at various times, and lengths, during and/or after the implementors meeting in October 1994. 4) Send the data and media address solicitation in one packet (the latter in a hop by hop, one hop lived, extension header) to some mcast address. Provide appropriate mechanisms for dealing with issues related to MTU, ICMP, etc... Pro: - stateless in the hosts (no need to queue and resubmit) in the large majority of cases - reduces number of address resolution packets from 2 to 1. Con: - it requires header insertion if it is done in the last hop router. - known mcasting data cons.... 5) Send the data and media address solicitation in one packet (the latter in an IPv6 encapsulating header) Pro: - stateless in the hosts (no need to queue and resubmit) - reduces number of address resolution packets from 2 to 1. - "architecturally correct", relative to 4. Con: - known mcasting data cons, etc...... 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 Wed Nov 9 15:26:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06328; Wed, 9 Nov 94 15:26:06 PST Received: from jurassic.Eng.Sun.COM (jurassic-51) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06322; Wed, 9 Nov 94 15:25:58 PST Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA28985; Wed, 9 Nov 1994 15:21:22 -0800 Received: by bobo.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA18776; Wed, 9 Nov 1994 15:21:13 -0800 Date: Wed, 9 Nov 1994 15:21:13 -0800 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199411092321.PAA18776@bobo.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) routers in solicited-node? Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 4) Send the data and media address solicitation in one packet (the latter in > a hop by hop, one hop lived, extension header) to some mcast address. > Provide appropriate mechanisms for dealing with issues related to MTU, ICMP, > etc... > > Pro: - stateless in the hosts (no need to queue and resubmit) in the large > majority of cases I assume you use "stateless" to mean that the host doesn't have to queue packets. Presumably the host has to keep track of the outstanding unanswered solitations to prevent a host from flooding multicast packets. E.g. if an application like 'ttcp -t -u -s some_host' (TTCP blasting out UDP packets) is running you clearly do not want to multicast every data packet in the case when some_host is not answering the solicitations. Thus, IMHO "stateless" is a misnomer in this case. Erik ------------------------------------------------------------------------------ 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 Nov 9 15:30:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06358; Wed, 9 Nov 94 15:30:56 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06352; Wed, 9 Nov 94 15:30:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25928; Wed, 9 Nov 94 15:26:30 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19495; Wed, 9 Nov 94 15:24:59 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA26812; Wed, 9 Nov 94 10:10:39 -0800 Received: by xirtlu.zk3.dec.com; id AA09462; Wed, 9 Nov 1994 13:10:31 -0500 Message-Id: <9411091810.AA09462@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Implementor Meeting Minutes PLEASE !!! In-Reply-To: Your message of "Fri, 04 Nov 94 14:20:10 EST." <9411041920.AA10531@nero.dcrc.com> Date: Wed, 09 Nov 94 13:10:25 -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 >specs will apply to me, as a coder of router software. As I suggested >in a previous note, I would like to get a clarification as to the >definition of host in so far as it pertains to what parts of, e.g., >Discovery I will have to implement. I have received only minimal >response on this issue. I would like to see one too. >I aplogize if this note is not constructive, but I don't want to beat >my head against a wall that isn't going to give by Dec. 3. Dec 3rd will not happen. Will March 3rd? I just don't know. /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 Nov 9 18:02:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06586; Wed, 9 Nov 94 18:02:30 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06580; Wed, 9 Nov 94 18:02:19 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22613; Wed, 9 Nov 94 17:57:50 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA07378; Wed, 9 Nov 94 11:14:58 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-04.dialip.mich.net [35.1.48.85]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA24614 for ; Wed, 9 Nov 1994 11:32:58 -0500 Date: Wed, 9 Nov 94 14:58:11 GMT From: "William Allen Simpson" Message-Id: <3420.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) embedded IEEE Addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > What I do object to is implementing a design where that is the > only way that addresses can be assigned. ... > Finally, last I heard, Greg Minshall and I had no disagreements > on this topic. > Ignoring the remainder of your quite frankly insulting remarks, I will point out that Greg is the primary proponent of embedding IEEE addresses as the method for "serverless" auto-configuration. If, in fact, you have no disagreement with this, then there was no substance at all in your original comments. (I did _not_ simply skip to the end.) Next time, when you review a document, I would appreciate substantive suggestions of improved text. 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 Nov 9 18:23:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06614; Wed, 9 Nov 94 18:23:33 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA06608; Wed, 9 Nov 94 18:23:25 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26516; Wed, 9 Nov 94 18:19:05 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA04143; Wed, 9 Nov 94 08:04:02 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14522(5)>; Wed, 9 Nov 1994 08:03:44 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Wed, 9 Nov 1994 08:03:40 -0800 To: Dan McDonald Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: danmcd's message of Tue, 08 Nov 94 08:23:32 -0800. <9411081623.aa21138@sundance.itd.nrl.navy.mil> Date: Wed, 9 Nov 1994 08:03:37 PST From: Steve Deering Message-Id: <94Nov9.080340pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan, > Does a router receive and process all-hosts multicast datagrams? No. In IPv6, "host" means "not router". When IPv6 forwarding is turned on in a node, the node must leave the all-hosts group and join the all-routers group. Multicasts that are intended to be received by all hosts *and* routers on a link are sent to the all-nodes group. 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 Thu Nov 10 02:22:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07037; Thu, 10 Nov 94 02:22:34 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07031; Thu, 10 Nov 94 02:22:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24554; Thu, 10 Nov 94 02:18:08 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA13717; Thu, 10 Nov 94 02:17:41 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPng Implementors Meeting Minutes To: ipng@sunroof.Eng.Sun.COM Date: Thu, 10 Nov 1994 10:17:39 +0100 (GMT) In-Reply-To: <199411091912.LAA15326@jurassic.Eng.Sun.COM> from "Bob Hinden" at Nov 9, 94 11:12:54 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2747 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > IPng Implementors Meeting Minutes > In order to avoid creating a dependency on DNS server support for AAAA > records, early implementations should be able to fall back on using some > form of local file support (i.e. /etc/hosts) to provide the name-to- > address mapping. All implementations will need this in the real world anyway - DNS isn't reliable enough or secure enough for some applications (even with security a remote DNS could be subverted by physical access). > Scott Bradner suggest sending comments in response to last call if > unhappy with security "mandatory" requirements. Have a large 'UNHAPPY'. I firmly believe that understanding security should be mandatory, but containing specific implementations and shipping them around is not feasible in the current paranoid world. Some countries don't allow encryption, others require complex licenses. The practical upshot is specification or not many people (and certainly the mass of free implementations) , free Unixes etc will ship without it by unavoidable effects of US and other law. Before you make it mandatory consider the third world too - encryption in parts of that gets you long jail terms and 'IPv6 use it and get locked up' could have acceptance problems... I really wish we could pick something like IKMP and say 'use me' - but it just can't be done yet. > > Bob Hinden and Ross Callon pointed out cases where companies really need > to obtain patents. Thus we should not be "blaming" anyone for getting a > patent. Scott Bradner points out the policies for Internet Standards > require that the patent holder make the patented technology available in > a reasonable and non-discriminatory manner. Thus we need to get a > signed letter from IBM making this statement. For the free IP stack world if it involves a patent it either means a) It won't get implemented in free stacks - or b) Americans can suffer while the rest of the world gets on with things. So anything requiring a patent can be considered in specification terms as OPTIONAL, whatever the spec says it really is classed as. > > Bill believes that IP mobility has circumvented the patent, by using a Excellent.. > The IPng speciation in effect essentially says "should", and this is the > right thing, it should specifically say "SHOULD". What should an > implementation do if fields are out of order? The specification does > not say anything about this at this time. How about sending a suitable protocol violation error back and ignoring the frame. Nobody has written much IPv6 stuff yet so being nasty now will stop anyone getting it wrong undetected later.. Thanks for people getting the minutes on the list for the benefit of 'the rest of us'. 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 Nov 10 06:25:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07266; Thu, 10 Nov 94 06:25:26 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07260; Thu, 10 Nov 94 06:25:18 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29911; Thu, 10 Nov 94 06:20:59 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04236; Thu, 10 Nov 94 06:20:33 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09689; Fri, 11 Nov 1994 01:20:22 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) embedded IEEE Addresses In-Reply-To: Your message of "Wed, 09 Nov 1994 14:58:11 GMT." <3420.bill.simpson@um.cc.umich.edu> Date: Fri, 11 Nov 1994 01:20:16 +1100 Message-Id: <12941.784477216@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 9 Nov 94 14:58:11 GMT From: "William Allen Simpson" Message-ID: <3420.bill.simpson@um.cc.umich.edu> point out that Greg is the primary proponent of embedding IEEE addresses as the method for "serverless" auto-configuration. Yes, I know. Addrconf is working on stateless autoconfiguration, not serverless, Greg was (is) participating in addrconf, and didn't seem opposed to the way it was approaching things. Stateless autconfig needs something like IEEE addresses to be able to construct IPv6 addresses. If, in fact, you have no disagreement with this, then there was no substance at all in your original comments. You still seem to be ignoring what I am saying. The point is that not all autoconfiguration needs to be done the same way. One thing is not appropriate for everyone. Now all hosts clearly have to act the same way, because autoconfig is clearly the first thing they do - if they needed to be configured to do autoconfig in different ways, it would be almost as easy to simply configure their addresses (as usually happens now). However, using an autoconfig server, stateless or not, autoconfig mechanisms can be made to vary, simply by configuring the server (one, or a small number, of them). That's the way addrconf is approaching things, and what's more it seems to be the right way. This allows (that I can see right now), three quite different kinds off autoconf servers... Algorithmic (stateless) ones, which simply take the "token" (IEEE address) supplied by the host, append that to the prefix (or more than one prefix) that applies to this net, and return it. This clearly needs space to embed IEEE addresses in IPv6 addresses, and is also quite clearly a sensible mode to allow. Its simple, robust, and effective. Second would be stateful, automatic, servers, which take the token, look it up in a database, if found, return the address associated with that token from the database. If no entry is there, then increment a counter (1, 2, 3, ...) append that counter to the prefix (of prefixes) for the net, insert the pair (token/address) in the database, and return the address to the client. This has the advantage that it uses lots less address space (16 bits for the counter would be enough for the very biggest nets one would think, a very big one could have 32 bits, will lots less than 48), its fairly simple, it hides knowledge of mac addresses from remote sites - no longer any easy way to count how many Suns, SGI's, DEC, IBM, ... I have at my site by simply iterating through my DNS data. It needs no manual configuration, so is barely more difficult to run than the first scheme. The third is manual configuration, which is basically the way we operate now with bootp et al. That requires an administrator to enter the token into a database, and asssociate an address (or perhaps a suffix to the net's prefix) in the database. This allows the net administrator to have control of what hosts are able to connect to his net and obtain an address, at the cost of significant extra work. The substance to my original comment was that for this to be practical, hosts must not attempt to construct their own addresses - if they do, then the network administrator doesn't have the option to choose which kind of configuration that they want for their network - the host will simply pick its address the way it desires, and its done. This is not on. But this does not mean that IEEE addresses in IPv6 addresses are unnecessary, they'll be useful for the the first kind of autoconfiguration, which is likely to be both the default style, andd thee most popular. Note, its my personal preference, which I don't believe that most of the rest fo the addrconf group shares (and perhaps none do), that hosts construct absolutely NO IPv6 addresses for themselves (with the sole exception of the case where there is no addrconf server available on the net - the isolated dentist's office scenario). I do not support using ICMP for addrconf purposes, I'd prefer to use specific link level packets for this (UDP if it has to be IPv6 based) - that is, PPP address negotiation over PPP links, perhaps something like RARP on ethernet, etc. Personally I'd prefer hosts to not be able to be plugged in and work without administrator OK, either a blanket ok ("use stateless autoconfig") or explicit OK (by configuring this particular node in a database) - not even work on the local cable, no "local use" addresses at all, again excepting only the case where there is no server at all. (I did _not_ simply skip to the end.) It seemed so, as this comment on autoconfig was basically unrelated to everything else I said, yet you chose to treat that as "summing up" my objections, which it certainly did not do. It was one, unrelated, point. The rest was commenting on the main subject of the draft - ie: the discovery function, or how to I find some other node's MAC address. Next time, when you review a document, I would appreciate substantive suggestions of improved text. The first thing is simply to delete all references to address assignment, which is the province of addrconf. In that means simply delete sections 3.4 and 9 - particularly 9. In general I send text changes when I believe the basic approach is right, and just needs refining, not otherwise. 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 Nov 10 07:11:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07416; Thu, 10 Nov 94 07:11:42 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07410; Thu, 10 Nov 94 07:11:31 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02777; Thu, 10 Nov 94 07:07:13 PST Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA12741; Thu, 10 Nov 94 07:04:25 PST Received: by rodan.UU.NET id QQxpkl01793; Thu, 10 Nov 1994 07:55:12 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) Which m-cast groups to join? To: ipng@sunroof.Eng.Sun.COM Date: Thu, 10 Nov 1994 07:55:11 -0500 (EST) In-Reply-To: <94Nov9.080340pst.12173@skylark.parc.xerox.com> from "Steve Deering" at Nov 9, 94 08:03:37 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 786 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] >No. In IPv6, "host" means "not router". When IPv6 forwarding is turned on >in a node, the node must leave the all-hosts group and join the all-routers >group. Multicasts that are intended to be received by all hosts *and* >routers on a link are sent to the all-nodes group. Ok, what kind of things do we only want non-routers to recieve? For example if I add a second ethernet to my file server and configure it to act as a router (in case my real router breaks), what multicasts do I want to no longer recieve? May I also suggest we change the name of the group to "non-router"? That should reduce mistakes (well the Auspex is just a NFS server, not a genneral purpose host... well just because I made my file server a router too doesn't mean it isn't still a host...). ------------------------------------------------------------------------------ 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 Nov 10 07:50:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07524; Thu, 10 Nov 94 07:50:01 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07518; Thu, 10 Nov 94 07:49:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04947; Thu, 10 Nov 94 07:45:31 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA19427; Thu, 10 Nov 94 07:45:10 PST To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Security & the Meeting Minutes Date: Thu, 10 Nov 94 15:44:18 GMT From: Ran Atkinson Message-Id: <9411101544.aa23719@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello, > In order to avoid creating a dependency on DNS server support for AAAA > records, early implementations should be able to fall back on using some > form of local file support (i.e. /etc/hosts) to provide the name-to- > address mapping. % All implementations will need this in the real world anyway - DNS isn't % reliable enough or secure enough for some applications (even with security % a remote DNS could be subverted by physical access). In the case where your DNS servers can be subverted via physical access, then other more serious security problems are also present and all use of the net you are connected to is probably inadvisable, IMHO. > Scott Bradner suggest sending comments in response to last call if > unhappy with security "mandatory" requirements. % Have a large 'UNHAPPY'. I firmly believe that understanding security % should be mandatory, but containing specific implementations and % shipping them around is not feasible in the current paranoid % world. Some countries don't allow encryption, others require complex % licenses. Point of clarification: The term "security" is content-free, particularly in the context of the IPv6 proposal. I'd like to urge that people talk about specific properties that are provided by the proposed mechanisms, to wit: authentication and integrity (i.e. as with Auth Header) confidentiality and integrity (i.e. as with ESP) In particular, it is true that many countries regulate the export of confidentiality mechanisms (such as encryption) and some countries (most notably France) apparently regulate use of confidentiality. It is most assuredly NOT true that any country we're aware of regulates the export or use of authentication-without-confidentiality as is provided by the IPv6 Authentication Header proposal. That mechanism appears to be both universally implementable and universally deployable without legal restrictions. Now for fairness, it is important to understand that actual use of either the keyed MD5 proposed for use with the Auth Header or DES-CBC on a packet will significantly impact the packet processing performance. Implementation inside a kernel should not adversely impact performance since in the case where those two mechanisms are implemented but not being used for some given packet the performance penalty is one "IF" test and increased overall kernel size (the latter being a property of any proposed "feature" not unique to these mechanisms). % The practical upshot is specification or not many people % (and certainly the mass of free implementations) , free Unixes etc % will ship without it by unavoidable effects of US and other % law. Before you make it mandatory consider the third world too - % encryption in parts of that gets you long jail terms and 'IPv6 use it % and get locked up' could have acceptance problems... I know of at least one no-cost implementation currently under development that will definitely include both security mechanisms. It is possible that the ESP portion of that implementation would not be available via anonymous ftp. I believe, based on past experience with similar situations (e.g. PGP, PEM, etc.), that patches adding ESP support with DES-CBC for the freely distributable UNIX-like implementations (e.g. FreeBSD, NetBSD, Linux) and similar commercial products (e.g. BSDI) will appear on the net for anonymous ftp from one or more sites. One hypothetical side effect of this is to increase pressure on vendors to implement ESP and for vendors in turn to increase pressure on governments to make such implementation less of a legal issue. I believe that it is likely that some vendors in some countries will make a "business decision" limiting support for ESP in some or all of their products. This is no different than the current situation with Internet protocols. For example, some mandatory requirements (e.g. the way the TCP Urgent pointer is implemented) of RFC-1122/1123 continue not to be implemented by some vendors because they don't think such implementation makes good business sense. Vendors who chose not to implement ESP can't legitimately claim to implement it but could legitimately claim to implement "IPv6 except for ESP". At the end of the day, the availability of any networking product is determined by the marketplace not by standards. IMHO, this fact does not mean that standards shouldn't exist or that we should water down the conformance requirements to be the lowest common denominator. % I really wish we could pick something like IKMP and say 'use me' - but % it just can't be done yet. I do not understand the above comment. Could you please explain what you mean in a bit more detail ? % For the free IP stack world if it involves a patent it either means % a) It won't get implemented in free stacks - or % b) Americans can suffer while the rest of the world gets on with things. Absolutely. This also means that the standards should make the very best effort to avoid patents whenever the relevant patents are not clearly available at NO COST to all comers. % So anything requiring a patent can be considered in specification terms % as OPTIONAL, whatever the spec says it really is classed as. No. It means that the patented specs are not as likely to be implemented or at least implemented in the manner specified. If one does not implement parts of specs that are marked as optional, one may still legitimately claim conformance to the spec. However, if one does not implement parts of specs that are marked as mandatory, then one may not legitimately claim conformance to the spec. As noted above, there are many existing cases where commercial vendors do not implement specs because they believe it is not a good business decision. > Bill believes that IP mobility has circumvented the patent, by using a % Excellent.. Yes. And we SHOULD use the circumvented approach unless the patent holder very very soon formally and in a legally-binding manner agrees to let anyone implement the patented approach at NO COST and very very soon provides adequate documentation of such to the IESG. % How about sending a suitable protocol violation error back and ignoring the % frame. Nobody has written much IPv6 stuff yet so being nasty now will stop % anyone getting it wrong undetected later.. Please be liberal in what one accepts and conservative in what one sends. Sending an explicit protocol violation error back seems unproductive and likely to lead to interoperability woes. Regards, Ran atkinson@itd.nrl.navy.mil PS: Revised and improved versions of the ESP, AH, and Security Architecture specs should appear online sometime next week. Thanks to a new reviewer within NRL, the new specs should be more readable than the present ones. ------------------------------------------------------------------------------ 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 Nov 10 08:08:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07605; Thu, 10 Nov 94 08:08:05 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07599; Thu, 10 Nov 94 08:07:54 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06493; Thu, 10 Nov 94 08:03:35 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22672; Thu, 10 Nov 94 08:03:14 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-14.dialip.mich.net [35.1.48.215]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA01256 for ; Thu, 10 Nov 1994 11:03:11 -0500 Date: Thu, 10 Nov 94 15:42:50 GMT From: "William Allen Simpson" Message-Id: <3425.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPng Implementors Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Bill Simpson began to make a strong argument over patents / intellectual > property. Charlie has a patent (owned by IBM) which is already granted, > but Charlie says that his patent does not relate to this stuff. Charlie > has informed the chairs of the working group of the patent, the working > group informed the area director, who informed the IESG, and believes > that IBM will make the patent freely available. > This is in error. Charlie stood up and explicitly stated that he believed his patent applies to: "all mobility designs using a Home Agent." 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 Nov 10 08:08:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07617; Thu, 10 Nov 94 08:08:41 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07611; Thu, 10 Nov 94 08:08:30 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06543; Thu, 10 Nov 94 08:04:11 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22647; Thu, 10 Nov 94 08:03:12 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-14.dialip.mich.net [35.1.48.215]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA01250 for ; Thu, 10 Nov 1994 11:03:08 -0500 Date: Thu, 10 Nov 94 15:32:45 GMT From: "William Allen Simpson" Message-Id: <3424.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPng Implementors Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: iialan@iifeak.swan.ac.uk (Alan Cox) > So anything requiring a patent can be considered in specification terms > as OPTIONAL, whatever the spec says it really is classed as. > > > > Bill believes that IP mobility has circumvented the patent, by using a > > Excellent.. > Please take note that I was fired by Kennan as Mobile-IP Editor for my refusal to incorporate the patents. Perkins is now Editor, and is busily putting his and other IBM patents in the draft. When Ran Atkinson objected, Charlie wrote: We're on track internally to get this patent issue resolved. In the meantime, what's wrong with hearing the discussion?????? I wouldn't depend on the Mobile-IP work to help us in IPv6. 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 Nov 10 08:40:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08345; Thu, 10 Nov 94 08:40:30 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08339; Thu, 10 Nov 94 08:40:23 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09298; Thu, 10 Nov 94 08:36:04 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA29414; Thu, 10 Nov 94 08:35:11 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Security & the Meeting Minutes To: ipng@sunroof.Eng.Sun.COM Date: Thu, 10 Nov 1994 16:35:13 +0100 (GMT) In-Reply-To: <9411101544.aa23719@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Nov 10, 94 03:44:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4120 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In the case where your DNS servers can be subverted via physical > access, then other more serious security problems are also present and > all use of the net you are connected to is probably inadvisable, IMHO. It may not be 'your' DNS. Situations where you accept incoming connections from blah.provider.com and provider.com is subverted are more of the issue. Trusting your own DNS, and using key authentication with it. > It is most assuredly NOT true that any country we're aware of > regulates the export or use of authentication-without-confidentiality > as is provided by the IPv6 Authentication Header proposal. That This is good. It's also good that it appears legal to use this over amateur radio where encryption is forbidden in most countries. > Now for fairness, it is important to understand that actual > use of either the keyed MD5 proposed for use with the Auth Header or > DES-CBC on a packet will significantly impact the packet processing Inevitably - thats a different issue of if you want it you got to pay the price (or plug in our new hardware board). > I know of at least one no-cost implementation currently under > development that will definitely include both security mechanisms. It > is possible that the ESP portion of that implementation would not be > available via anonymous ftp. MD5 is certainly not an issue again, but the encryption as opposed to authentication ones clearly would be. > I believe, based on past experience with similar situations (e.g. PGP, > PEM, etc.), that patches adding ESP support with DES-CBC for the > freely distributable UNIX-like implementations (e.g. FreeBSD, NetBSD, > Linux) and similar commercial products (e.g. BSDI) will appear on the > net for anonymous ftp from one or more sites. One hypothetical side > effect of this is to increase pressure on vendors to implement ESP and > for vendors in turn to increase pressure on governments to make such > implementation less of a legal issue. The problem is not the free internet world - its the free _NON_ internet world of CD vendors and disk distributors who work on low price high volume shipping. They can't afford to have a US and a non US disk cut. > I do not understand the above comment. Could you please explain what you > mean in a bit more detail ? Ok 'Oh for a single exportable goverment don't care encryption standard that could be speced provide all the needed functions of key management etc' 8) > % So anything requiring a patent can be considered in specification terms > % as OPTIONAL, whatever the spec says it really is classed as. > No. It means that the patented specs are not as likely to be > implemented or at least implemented in the manner specified. If one > does not implement parts of specs that are marked as optional, one may > still legitimately claim conformance to the spec. However, if one I was trying to point out that they would not get implemented for real world reasons, and thus couldn't be relied upon because not everyone implements them (sort of like relying on the official definition of urgent data at the moment). > Please be liberal in what one accepts and conservative in what one > sends. Sending an explicit protocol violation error back seems > unproductive and likely to lead to interoperability woes. In the final real world maybe, but at the very least they need to be logged loudly at this stage so that vendors can say - 'Your stack is broken'. Do the vagueries of misordered options cause any other issues too - for example if some people interpret them out of order (be liberal) and others don't there will be cases where option 'X' may have been processed by some people and not others. If it was say a routing option to keep a secure packet off an insecure network that might be embarassing. If the spec is emphatic about ordering and says MUST report a violation these issues dont come up and its hardly a 'be liberal' issue as the spec is pretty specific on the subject. If the final spec ends up not mentioning what to do then yes sending a violation is not conducive to good interoperability. 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 Nov 10 09:12:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08400; Thu, 10 Nov 94 09:12:56 PST Received: from jurassic.Eng.Sun.COM (jurassic-248) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08394; Thu, 10 Nov 94 09:12:45 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA04007; Thu, 10 Nov 1994 09:08:09 -0800 Date: Thu, 10 Nov 1994 09:08:09 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411101708.JAA04007@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Subject: Re: (IPng) IPng Implementors Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, Thanks for your note. > > Scott Bradner suggest sending comments in response to last call if > > unhappy with security "mandatory" requirements. > > Have a large 'UNHAPPY'. I firmly believe that understanding security should > be mandatory, but containing specific implementations and shipping them > around is not feasible in the current paranoid world. Some countries don't > allow encryption, others require complex licenses. The practical upshot is > specification or not many people (and certainly the mass of free implementations) > , free Unixes etc will ship without it by unavoidable effects of US and other > law. Before you make it mandatory consider the third world too - encryption in > parts of that gets you long jail terms and 'IPv6 use it and get locked up' > could have acceptance problems... I generally agree with you. Suggest you send these comments to the IESG as a response to the last call. I sent in a response along these lines. > For the free IP stack world if it involves a patent it either means > a) It won't get implemented in free stacks - or > b) Americans can suffer while the rest of the world gets on with things. > > So anything requiring a patent can be considered in specification terms > as OPTIONAL, whatever the spec says it really is classed as. It is a difficult problem. We (the IETF) tend to not want to use patented technology. The paradox is that given the number of organizations patenting "everything" and because there is no legal requirement that patent applications be made public until the patent is granted, there is a strong likelihood that even though we standardize a technology which we are not aware of any patent claims, we may discover after the fact that someone does hold a patent. It may turn out to be better to standardize a technology which there is a patent claim if we can get a release from the patent holder prior to making it a standard. > Thanks for people getting the minutes on the list for the benefit of > 'the rest of us'. You are welcome. Sorry they didn't come out sooner. 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 Nov 10 09:51:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09743; Thu, 10 Nov 94 09:51:25 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09737; Thu, 10 Nov 94 09:51:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18307; Thu, 10 Nov 94 09:46:59 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA14829; Thu, 10 Nov 94 09:46:32 PST Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA10310; Thu, 10 Nov 1994 12:46:25 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA29344; Thu, 10 Nov 1994 12:46:23 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA24201; Thu, 10 Nov 1994 12:22:51 -0500 Message-Id: <9411101722.AA24201@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) routers in solicited-node? In-Reply-To: Your message of "Wed, 09 Nov 94 15:21:13 PST." <199411092321.PAA18776@bobo.Eng.Sun.COM> Date: Thu, 10 Nov 94 12:22:51 -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: nordmark@jurassic-248.eng.sun.com (Erik Nordmark) > > Pro: - stateless in the hosts (no need to queue and resubmit) in the large > majority of cases I assume you use "stateless" to mean that the host doesn't have to queue packets. Yes. That's what the text says - see above. Presumably the host has to keep track of the outstanding unanswered solitations to prevent a host from flooding multicast packets. Yes. Similarly to the other multicast-based mechanisms. ... Thus, IMHO "stateless" is a misnomer in this case. Erik My message was intended as a brief enumeration - pretty much like Christian Huitema's which it followed - of the other ideas discussed, rather than a thorough presentation of details. 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 Thu Nov 10 10:56:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09861; Thu, 10 Nov 94 10:56:57 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09853; Thu, 10 Nov 94 10:56:45 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28433; Thu, 10 Nov 94 10:52:26 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA26560; Thu, 10 Nov 94 10:48:46 PST Received: by nero.dcrc.com (4.1/1.34) id AA12240; Thu, 10 Nov 94 13:47:24 EST Date: Thu, 10 Nov 94 13:47:24 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411101847.AA12240@nero.dcrc.com> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) looking for addrconf mailing list Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sorry to bother the whole list with this, but the file 1wg-summary.txt doesn't list the mailing list address for the addrconf list. Where is it? Thanks in advance -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 Thu Nov 10 11:31:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10018; Thu, 10 Nov 94 11:31:28 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10012; Thu, 10 Nov 94 11:31:20 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03871; Thu, 10 Nov 94 11:27:01 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA03135; Thu, 10 Nov 94 11:26:24 PST Received: from wasted.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA14709; Thu, 10 Nov 1994 14:26:14 -0500 Received: from brigit.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Sep94-0829AM) id AA11014; Thu, 10 Nov 1994 14:25:28 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA10310; Thu, 10 Nov 1994 14:01:52 -0500 Message-Id: <9411101901.AA10310@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: danmcd@sundance.itd.nrl.navy.mil, deering@parc.xerox.com, conta@zk3.dec.com Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: Your message of "Wed, 09 Nov 94 08:03:37 PST." <94Nov9.080340pst.12173@skylark.parc.xerox.com> Date: Thu, 10 Nov 94 14:01:52 -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: Steve Deering Subject: Re: (IPng) Which m-cast groups to join? Dan, > Does a router receive and process all-hosts multicast datagrams? No. In IPv6, "host" means "not router". When IPv6 forwarding is turned on in a node, the node must leave the all-hosts group and join the all-routers group. Multicasts that are intended to be received by all hosts *and* routers on a link are sent to the all-nodes group. Steve Steve, Perhaps qualify this a little more? "Turning forwarding on" may not mean to some "start router functions". It may rather mean only one of the steps into making a host a router, which is setting a flag that has the role of enabling/disabling forwarding of packets among the hosts' interfaces. Without the rest of the steps, a multihomed host does not necessarily become a router in the sense described above. The other important steps which are "Start listening for router solicitations" and "start advertising router information"(IPv6), are the ones that are perhaps closer linked to when to join "all-routers multicast", and leave "all-hosts". Or perhaps use the term "start router functions" that encompasses the steps enumerated above? 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 Nov 10 11:51:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10052; Thu, 10 Nov 94 11:51:42 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10046; Thu, 10 Nov 94 11:51:35 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07076; Thu, 10 Nov 94 11:47:16 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07007; Thu, 10 Nov 94 11:46:37 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA28563; Thu, 10 Nov 94 11:41:30 -0800 Received: by xirtlu.zk3.dec.com; id AA10700; Thu, 10 Nov 1994 14:41:20 -0500 Message-Id: <9411101941.AA10700@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Security & the Meeting Minutes In-Reply-To: Your message of "Thu, 10 Nov 94 15:44:18 GMT." <9411101544.aa23719@sundance.itd.nrl.navy.mil> Date: Thu, 10 Nov 94 14:41:14 -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 ------------ > In order to avoid creating a dependency on DNS server support for AAAA > records, early implementations should be able to fall back on using some > form of local file support (i.e. /etc/hosts) to provide the name-to- > address mapping. % All implementations will need this in the real world anyway - DNS isn't % reliable enough or secure enough for some applications (even with security % a remote DNS could be subverted by physical access). ----------- >In the case where your DNS servers can be subverted via physical >access, then other more serious security problems are also present and >all use of the net you are connected to is probably inadvisable, IMHO. True. But also there is a DNS security proposal on the table by Charlie Kaufman (Iris) and Donald Eastlake (Digital). Its in process now. > Now for fairness, it is important to understand that actual >use of either the keyed MD5 proposed for use with the Auth Header or >DES-CBC on a packet will significantly impact the packet processing >performance. Implementation inside a kernel should not adversely >impact performance since in the case where those two mechanisms are >implemented but not being used for some given packet the performance >penalty is one "IF" test and increased overall kernel size (the latter >being a property of any proposed "feature" not unique to these >mechanisms). I agree. But once you execute the there will be a large sucking sound and performance will drop by 50%. Its also more than one IF Test but thats OK. >Please be liberal in what one accepts and conservative in what one >sends. Sending an explicit protocol violation error back seems >unproductive and likely to lead to interoperability woes. Well now that the U.S. just kicked the democrats out of congress and the senate does this mean we should be even more conservative? Just kidding. /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 Nov 10 11:56:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10064; Thu, 10 Nov 94 11:56:55 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10058; Thu, 10 Nov 94 11:56:47 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07869; Thu, 10 Nov 94 11:52:28 PST Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07827; Thu, 10 Nov 94 11:51:03 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA29268; Thu, 10 Nov 94 11:48:36 -0800 Received: by xirtlu.zk3.dec.com; id AA10961; Thu, 10 Nov 1994 14:48:29 -0500 Message-Id: <9411101948.AA10961@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Implementor Minutes - Thanks Bob Hinden Date: Thu, 10 Nov 94 14:48:23 -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 Bob, Thanks for getting these out in such a clear and concise format. Good job. Sorry I was such a pain about it but you know me (pit bull dog jim). I am working on rooms for us Sunday Dec 3 1-6 p.m. and Fri Dec 9 9-Noon at the Fairmont Hotel for implementors meeting. Waiting to hear back from Megan. /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 Nov 10 14:38:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10281; Thu, 10 Nov 94 14:38:16 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10275; Thu, 10 Nov 94 14:38:09 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28488; Thu, 10 Nov 94 14:33:50 PST Received: from avalon.mpce.mq.edu.au by Sun.COM (sun-barr.Sun.COM) id AA07943; Thu, 10 Nov 94 14:32:48 PST Message-Id: <9411102232.AA07943@Sun.COM> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA10174; Fri, 11 Nov 94 09:32:30 edt From: Andrew Myles Subject: Re: (IPng) IPng Implementors Meeting Minutes To: ipng@sunroof.Eng.Sun.COM Date: Fri, 11 Nov 94 9:32:29 EDT In-Reply-To: <3424.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Nov 10, 94 3:32 pm Mailer: Elm [revision: 64.9] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM G'day Bill, > Please take note that I was fired by Kennan as Mobile-IP Editor for my > refusal to incorporate the patents. You were fired because you refused to serve the will of the Mobile-IP working group. > Perkins is now Editor, and is > busily putting his and other IBM patents in the draft. This is false. > When Ran Atkinson objected, Charlie wrote: > > We're on track internally to get this patent issue resolved. In the > meantime, what's wrong with hearing the discussion?????? Well, what is wrong with hearing the discussion? > I wouldn't depend on the Mobile-IP work to help us in IPv6. Mobile-IP is making great leaps forward at the moment without some of the gross insults and rudness that occurred in previous times. Andrew -- -------------------------------------------------------------------------------- Andrew Myles e-mail: andrewm@mpce.mq.edu.au Electronics Department www: http://www.mpce.mq.edu.au/~andrewm/ Macquarie University 2109 archive: ftp://avalon.mpce.mq.edu.au/dist Sydney, NSW voice: +61 2 8509071 (W), +61 2 8786060 (H) Australia fax: +61 2 8509128 -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Nov 10 19:03:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10961; Thu, 10 Nov 94 19:03:48 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10955; Thu, 10 Nov 94 19:03:42 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13899; Thu, 10 Nov 94 18:59:22 PST Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA27009; Thu, 10 Nov 94 18:58:47 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 11 Nov 1994 12:53:38 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Fri, 11 Nov 1994 12:58:00 +1000 X400-Received: by /PRMD=DATACRAFT/ADMD=TELEMEMO/C=AU/; Relayed; Fri, 11 Nov 1994 13:58:08 +1000 Date: Fri, 11 Nov 1994 13:58:08 +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 941111 13:48:45 061] X400-Content-Type: P2-1984 (2) Content-Identifier: 941111 13:48:45 From: ALAN.LLOYD@DCTHQ.datacraft.telememo.au Message-Id: <"941111 13:48:45*/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) IPNG IMPLEMENTORS MEETING MINUTES Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM re this mobility patent and the comment "all mobility designs using a home agent".. My mobile phone dispays HOME and ROAM -- Australias Mobilenet Patents I thought (we have just done one for our warp 10 X.500 on a relational datbase) required that one needs to demonstrate the product, ie show that the design and intellectual property can be implemented. If this is true, and as we do not have an IP6 Internet with mobiles yet, is the patent valid? . ie The patent (as far as I understand US laws) does not meet the requirements we had to use for our X.500 to get the patent valid for the US. Hmmm just a thought. 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 Nov 10 21:39:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11079; Thu, 10 Nov 94 21:39:47 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11073; Thu, 10 Nov 94 21:39:40 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27114; Thu, 10 Nov 94 21:35:20 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA13966; Thu, 10 Nov 94 21:34:52 PST Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14456(2)>; Thu, 10 Nov 1994 21:34:44 PST Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Thu, 10 Nov 1994 21:34:32 -0800 To: mo@uunet.uu.net (Mike O'Dell) Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) high-speed slicing and dicing of headers..... In-Reply-To: mo's message of Tue, 01 Nov 94 06:00:02 -0800. Date: Thu, 10 Nov 1994 21:34:28 PST From: Steve Deering Message-Id: <94Nov10.213432pst.34050@swallow.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [swimming upstream through river of email...] Mike, > Therefore, somewhere along the way, while the packet is winding its way > to the edge of the source enterprise, some router must ASSERT the entrerprise > policy and ENFORCE particular routing decisions, and the only way in > hand right now is to insert routing headers. No, that's not the only way. You can prepend headers instead. > This ability to enforce routing policy independently of whatever > workstations are emitting is a REQUIREMENT. We can explain all the > reasons why it's a bad idea and that we really don't want to have to > do it, but that's tough noogies. Rather like firewalls for routing. I agree that it is a requirement. We can meet that requirement with encapsulation. No need to compromise with "bad ideas". > The other obvious scenario is doing encryption of traffic leaving > some boundary. same issues follow and it's just as big a requirement. > the workstation user may have no idea his traffic is being encrypted > on the fly as it leaves the enterprise boundary, nor should he care. Right. This scenario is also best handled by encapsulation, IMHO. > Response to identified problems: > > I don't think this really breaks MTU discovery - if the packets > are always modified the same way when they travel the same path, > then MTU discover should still work. Please go back and read the first item in my list of problems with header insertion. Unless you replace the original packet's source address (as propsed in the ERP draft), it *does* break MTU discovery. I co-designed the MTU Discovery algorithm, so I know what I'm talking about. > most of your other concerns are valid at some level, but if we > adopt the notion that the such modification should be use > SPARINGLY and only as a last resort, then that's the best we can do. But we *can* do better. Easily. Cleanly. 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 Thu Nov 10 21:53:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11111; Thu, 10 Nov 94 21:53:47 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11105; Thu, 10 Nov 94 21:53:40 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27613; Thu, 10 Nov 94 21:49:22 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA15228; Thu, 10 Nov 94 21:49:01 PST Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14456(4)>; Thu, 10 Nov 1994 21:48:55 PST Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Thu, 10 Nov 1994 21:48:49 -0800 To: Charles Lynn Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) adding extension headers to a packet in flight In-Reply-To: clynn's message of Tue, 01 Nov 94 06:43:42 -0800. <9411011454.AA18431@Sun.COM> Date: Thu, 10 Nov 1994 21:48:35 PST From: Steve Deering Message-Id: <94Nov10.214849pst.34050@swallow.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Charlie, > Maybe I missed something. Could you explain how, with encapsulation, > the intermediate systems would perform authentication. Do the > intermediate systems simply keep parsing headers, logically through > each level of encapsulation, until they find "an appropriate" > authentication header? The authentication header currently defined for IPv6 is intended for end-to-end authentication only, not for authentication by routers along a delivery path. When forwarding a packet, routers are not required to look any deeper into the packet than the Hop-by-Hop Options header which, if present, immediately follows the base IPv6 header. Whenever someone figures out how to do efficient in-transit authentication and efficient key distribution to the necessary routers, it should be straightforward to specify a new hop-by-hop authentication option. Note that, if a packet goes through a tunnel anywhere along its delivery path, the tunnel entry point can authenticate itself to the tunnel exit point, using an authentication header as part of the encapsulation. This should prove useful for the common scenario of a tunnel between a laptop and its home-site firewall, or tunnels connecting various branch offices of an organization across the public Internet. 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 Thu Nov 10 23:10:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11177; Thu, 10 Nov 94 23:10:16 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11165; Thu, 10 Nov 94 23:09:56 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB00924; Thu, 10 Nov 94 23:05:37 PST Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA21686; Thu, 10 Nov 94 23:05:17 PST Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA22252; Thu, 10 Nov 1994 23:05:16 -0800 Date: Thu, 10 Nov 1994 23:05:16 -0800 From: Dave Katz Message-Id: <199411110705.XAA22252@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: Mike Davis's message of Thu, 10 Nov 94 13:47:24 EST <9411101847.AA12240@nero.dcrc.com> Subject: (IPng) looking for addrconf mailing list Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM addrconf-request@cisco.com Date: Thu, 10 Nov 94 13:47:24 EST From: mad@nero.dcrc.com (Mike Davis) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sorry to bother the whole list with this, but the file 1wg-summary.txt doesn't list the mailing list address for the addrconf list. Where is it? Thanks in advance -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 ------------------------------------------------------------------------------ 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 Nov 10 23:10:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11178; Thu, 10 Nov 94 23:10:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11166; Thu, 10 Nov 94 23:09:57 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AB00924; Thu, 10 Nov 94 23:05:37 PST Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA21686; Thu, 10 Nov 94 23:05:17 PST Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA22252; Thu, 10 Nov 1994 23:05:16 -0800 Date: Thu, 10 Nov 1994 23:05:16 -0800 From: Dave Katz Message-Id: <199411110705.XAA22252@feta.cisco.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof2.Eng.Sun.COM In-Reply-To: Mike Davis's message of Thu, 10 Nov 94 13:47:24 EST <9411101847.AA12240@nero.dcrc.com> Subject: (IPng) looking for addrconf mailing list Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM addrconf-request@cisco.com Date: Thu, 10 Nov 94 13:47:24 EST From: mad@nero.dcrc.com (Mike Davis) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sorry to bother the whole list with this, but the file 1wg-summary.txt doesn't list the mailing list address for the addrconf list. Where is it? Thanks in advance -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 ------------------------------------------------------------------------------ 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 Nov 10 23:17:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11213; Thu, 10 Nov 94 23:17:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11207; Thu, 10 Nov 94 23:17:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01291; Thu, 10 Nov 94 23:13:18 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22432; Thu, 10 Nov 94 23:12:52 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA17321; Fri, 11 Nov 1994 18:12:45 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA20851; Fri, 11 Nov 94 18:10:15 +1000 Message-Id: <9411110810.AA20851@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Fri, 11 Nov 94 18:12:43 AUS Date: Mon, 22 May 05 18:35:44 AUS From: Alan.Lloyd@datacraft.com.au Subject: (IPng) management of IP6 routers To: ipng@sunroof.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Re the management issues of IP6 routers. I see that because the IP6 routing function also deals with the following: Multicast Addresses Base IP6 address Prefix and size Hop Cache entries. User based Flow Label Information. TClass to lower level QOS mapping (depending on the links QOS defs) Announcement Timers and configuration. Mobile Users Configurations (and currency) ? dealing with mobiles is a "router function". Logs (for Alarms, protocol errors, protocol integrity and option failures; and traces) Authentication Configuration ? SIPP says "All SIPP nodes". Plus there will be other management information for configuration such as: Address mapping ( for tunnelling), etc. and for accounting - ie Resource Utilisation statistics. ie. there will be a lot of "user" referenced based information within a router and IP6 nodes for the higher level management systems. Generally all this management information will require some information models and structure. SNMP could be used to access this but it does have the limitation that one cannot "name" objects and therefore one cannot have (easily) managed object tree data structures. Having been involved with CMIP (dare I say this) for a decade or so, the advantage of naming object hierarchies (such as management information) are numerous. Would I be too bold to propose that SNMP is upgraded with the ability to have a "naming" attribute that can contain an object identifier (much like a basic Distinguished Name is in CMIP (X.700) and Directories (X.500)) that can be used to index a named hierarchy of managed "objects". By including this concept into SNMP, the harmonisation of SNMP and CMIP will occur and the ability to model management information in object hierarchies will be almost equivalent. Certainly designing the management information model(s) for IP6 nodes and routers with the extended functions would be easier. ie A naming Object Id could be nnnn, xxxx, yyyy, zzzz where: nnnn = system Id as registered (the nodes equipment number) xxxx = system entity / module eg IP6 processing. yyyy = sub system eg Flow Control processing. zzzz = Instanciated Data Set (User Reference to flow control object/attributes) This upgrade would permit SNMP to be backward compatible (ie no address attribute in the SNMP request still works on current) systems, but where addressing is applied for the new IP6 functions managed Objects, the name attribute is used. However, the data modelling aspect will be different. Thoughts please. Regards Alan@Oz. Please note my address has changed (from the X.400 mapped one), but I still can be reached on the old one. I am still available via X.400. Alan.lloyd@datacraft.com.au ------------------------------------------------------------------------------ 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 Nov 11 01:49:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11363; Fri, 11 Nov 94 01:49:13 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11357; Fri, 11 Nov 94 01:49:06 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06435; Fri, 11 Nov 94 01:44:47 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA06161; Fri, 11 Nov 94 01:44:25 PST Received: from anubis (anubis.network.com) by nsco.network.com (4.1/1.34) id AA07334; Fri, 11 Nov 94 03:58:37 CST Received: from eros.network.com by anubis (4.1/SMI-4.1) id AA05861; Fri, 11 Nov 94 03:44:05 CST Date: Fri, 11 Nov 94 03:44:05 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411110944.AA05861@anubis> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Neighbor Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From Fred Rabouw (fredr@anubis.network.com) replying to Masataka Ohta who was replying to Bill Simpson [Bill] > During private consultation with Steve Deering in > regard to the router multicast problems, he suggested > that the General Advertisement be changed from > multicast to unicast. [Masataka] Unicast to which server? [My comment] A General-Advertisement is the answer of any node to a General- Sollicitation (see draft-simpson-ipv6-discov-process-00, page 6). The General-Sollicitation is send (same document page 5) when the media address of a partner is needed but not known. So (1) General- Advertisements are not limited to servers and (2) General- Advertisements are answers on General-Sollicitations. The destination unicast address of a General-Advertisement will have to be the source address of the General-Sollicitation on which it is an answer. [Bill] > The tradeoff is that a server with 1,000 clients will > generate 2,000 messages every 5 minutes, instead of just > one request/reply pair. [Masataka] Are you suggesting that we should have only a single server, the single point of failure? [My comment] I can't read this as "there is one server", Bill only tries to say: every server with 1000 clients will get a General-Sollicitation from each of its 1000 clients every 5 minutes, resulting in etc. In his original specifications the first General-Sollicitation from a just one client would update all other clients. To Bill: These 1000 time-outs only happens because the server does not advertise its media address. In your neighbor discovery specifications you also define a Server-Advertisement, but at the moment nothing is done with it. You might add something like: Each server MUST have a (configurable) switch whether it will send Server-Advertisements. If Server-Advertisements are send, it will be done with an interval of SERVER-ADVERTISEMENT-INTERVAL seconds (default: ... ) In that situations a network manager can take care of this timing out plus many sollicitations. Another option is: A node MIGHT have a (configurable) switch controlling whether General-Advertisements are send to the unicast address or to the all-hosts multicast address. I agree, configurations, configurations, but the requirements for very small and very big subnets are different and (CPU/disk/memory) resources in hosts are different. What is optimal for one network might be counter productive in other networks. Another way out of it would be to introduce an "internal" subnet and create a virtual router inside the server between the server task and the physical interface, don't tell me it sounds like Novell IPX, they are bad on wide area networks, but they have the design of local servers OK. Fred ------------------------------------------------------------------------------ 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 Nov 11 01:49:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11375; Fri, 11 Nov 94 01:49:35 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11367; Fri, 11 Nov 94 01:49:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06456; Fri, 11 Nov 94 01:45:08 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA06186; Fri, 11 Nov 94 01:44:45 PST Received: from anubis (anubis.network.com) by nsco.network.com (4.1/1.34) id AA07337; Fri, 11 Nov 94 03:58:53 CST Received: from eros.network.com by anubis (4.1/SMI-4.1) id AA05864; Fri, 11 Nov 94 03:44:21 CST Date: Fri, 11 Nov 94 03:44:21 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411110944.AA05864@anubis> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Neighbor Discovery Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From Fred Rabouw (fredr@anubis.network.com) in reply to John Osborne (stripes@uunet.uu.net), who was replying to Steve Deering [Steve] > No. In IPv6, "host" means "not router". When IPv6 > forwarding is turned on in a node, the node must leave > the all-hosts group and join the all-routers group. > Multicasts that are intended to be received by all hosts > *and* routers on a link are sent to the all-nodes group. [My comment:] I prefer these specifications as the are several times explained by Steve Deering and Bill Simpson, a router should only be in the all- node and all-router multicast, not in the all-host multicast .... [John] Ok, what kind of things do we only want non-routers to recieve? For example if I add a second ethernet to my file server and configure it to act as a router (in case my real router breaks), what multicasts do I want to no longer recieve? [My comment:] ...... but OK, than I must have some idea's on how to solve your issue. There might be several ways out of this router-also-a-host dilemma: The first situation to consider is the role as host that the router has: If the router is purely a router, its "host" function is only there for network management. In that case the management station shouldn't need to reach to routers with an "all-host" multicast and the router MUST NOT be in the all-host group. The second situation is a piece of hardware being both a server and a router. In such a situation this hardware will run two independent code images, one for the server function and one for the router function. One can think of several ways out of it: (a) The IP driver must be intelligent enough to hide the all-host multicasts for the router code and to hide the all-router multicasts for the server code. Such would mean we need to start a discussion to find all potnetial problems and might highly complicate the specifications for IPv6 (b) The server must be hidden behind the router on a virtual LAN. Your router would have three interfaces instead of two, two physical Ethernets plus a virtual internal network. The server will not be connected to one of the Ethernets, but to the virtual LAN. (Do I hear someone murmul "IPX internal networks"? ? ? Never heard of !) In that situation the server enters the all-host multicast and the router the all-router multicast and there is no confusion. When we take a few days to think it over, we might find more and/or better solutions, but I think we can solve it without having the router in the all-host multicast. An extra point of consideration: May be someone should find out of all the drafts when exactly "all-host" multicasts are planned to be used, to see how big this issue is anyway. Fred Rabouw ------------------------------------------------------------------------------ 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 Nov 11 05:58:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11477; Fri, 11 Nov 94 05:58:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11471; Fri, 11 Nov 94 05:58:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA15473; Fri, 11 Nov 94 05:54:10 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA25428; Fri, 11 Nov 94 05:53:45 PST Received: by nero.dcrc.com (4.1/1.34) id AA19351; Fri, 11 Nov 94 08:53:41 EST Date: Fri, 11 Nov 94 08:53:41 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411111353.AA19351@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <94Nov10.214849pst.34050@swallow.parc.xerox.com> (message from Steve Deering on Thu, 10 Nov 1994 21:48:35 PST) Subject: Re: (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 Date: Thu, 10 Nov 1994 21:48:35 PST From: Steve Deering Charlie, > Maybe I missed something. Could you explain how, with encapsulation, > the intermediate systems would perform authentication. Do the > intermediate systems simply keep parsing headers, logically through > each level of encapsulation, until they find "an appropriate" > authentication header? The authentication header currently defined for IPv6 is intended for end-to-end authentication only, not for authentication by routers along a delivery path. When forwarding a packet, routers are not required to look any deeper into the packet than the Hop-by-Hop Options header which, if present, immediately follows the base IPv6 header. . . . If this is true, then the Routing Header is of limited value. If no router has to look at it, then a packet can get from source to destination without regard to the Routing Header's contents, and the destination certainly won't care about it. What incorrect assumption am I making here? Steve -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 Nov 11 06:42:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11520; Fri, 11 Nov 94 06:42:13 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11514; Fri, 11 Nov 94 06:42:06 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17285; Fri, 11 Nov 94 06:37:48 PST Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA29583; Fri, 11 Nov 94 06:37:26 PST Message-Id: <9411111437.AA29583@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5751; Fri, 11 Nov 94 09:37:33 EST Date: Fri, 11 Nov 94 09:35:06 EST From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Cc: mo@uunet.uu.net Subject: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Thu, 10 Nov 1994 21:34:28 PST Steve, >>Therefore, somewhere along the way, while the packet is winding its way >>to the edge of the source enterprise, some router must ASSERT the >>enterprise policy and ENFORCE particular routing decisions, and the only >>way in hand right now is to insert routing headers. > >No, that's not the only way. You can prepend headers instead. That is correct. In THEORY an explicit route can be realized either via encapsulation or via a special header. However, in PRACTICE the implications of these two alternatives are quite different. For example, if the the enterprise policy asserted by a router results in a route that has N elements (A, B, C, D), then the encapsulation approach would either result in N-times encapsulation (so that a packet will carry at some point along the route N headers), or a coordination with all the elements in the route that would allow these elements to insert correct encapsulation (e.g. the router has to have an agreement with A that A encapsulates the packet with (A, B) as src/dst addresses, the router has to have an agreement with B that B encapsulates the packet with (B, C) as src/dst addresses, etc...) In contrast, using routing header doesn't require to have N-times encapsulation, and certainly doesn't require any coordination with any of the elements along the route. So, while in THEORY encapsulation and routing header may look the SAME, in PRACTICE they are NOT. >>This ability to enforce routing policy independent of whatever >>workstations are emitting is a REQUIREMENT. We can explain all the >>reasons why it's a bad idea and that we really don't want to have >>to do it, but that's tough noogies. > >I agree that it is a requirement. We can meet that requirement with >encapsulation. No need to compromise with "bad idea". We can meet this requirement with an explicit routing (ala ERP). No need to compromise with "bad idea". Yakov. ------------------------------------------------------------------------------ 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 Nov 11 06:45:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11536; Fri, 11 Nov 94 06:45:45 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11530; Fri, 11 Nov 94 06:45:38 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17448; Fri, 11 Nov 94 06:41:19 PST Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA29855; Fri, 11 Nov 94 06:40:56 PST Received: by pluto.dss.com (4.1/SMI-4.0) id AA01157; Fri, 11 Nov 94 09:40:05 EST From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9411111440.AA01157@pluto.dss.com> Subject: Re: (IPng) IPv6 Neighbor Discovery To: ipng@sunroof.Eng.Sun.COM Date: Fri, 11 Nov 1994 09:40:03 -0500 (EST) Cc: martillo@pluto.dss.com (Joachim Martillo), mario@pluto.dss.com (Mario Savvides), Telford001@aol.com In-Reply-To: <9411110944.AA05864@anubis> from "Fred Rabouw (Gouda office)" at Nov 11, 94 03:44:21 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 5015 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >From Fred Rabouw (fredr@anubis.network.com) in reply to > John Osborne (stripes@uunet.uu.net), who was replying to Steve > Deering > > [Steve] > No. In IPv6, "host" means "not router". When IPv6 > > forwarding is turned on in a node, the node must leave > > the all-hosts group and join the all-routers group. > > Multicasts that are intended to be received by all hosts > > *and* routers on a link are sent to the all-nodes group. > [My comment:] > I prefer these specifications as the are several times explained by > Steve Deering and Bill Simpson, a router should only be in the all- > node and all-router multicast, not in the all-host multicast .... > [John] Ok, what kind of things do we only want non-routers to > recieve? For example if I add a second ethernet to my file > server and configure it to act as a router (in case my real > router breaks), what multicasts do I want to no longer > recieve? > [My comment:] > ...... but OK, than I must have some idea's on how to solve your > issue. There might be several ways out of this router-also-a-host > dilemma: > The first situation to consider is the role as host that the router > has: If the router is purely a router, its "host" function is > only there for network management. In that case the > management station shouldn't need to reach to routers > with an "all-host" multicast and the router MUST NOT be > in the all-host group. It depends on what you mean by network management. I often consider putting an SNMP network manager in the Constellation series bridge routers. It already has built into it a forms menu interface which would be perfect for managing Constellation series bridge routers and it would not be too hard to add functionality to manage Cisco or Bay networks routers. For minimal cost, customers would get a high-performance bridge router + switch and an SNMP manager, but obviously in this case the router MUST be in the all-host group even though the whole purpose of the router functionality were network management. > The second situation is a piece of hardware being both a server and a > router. In such a situation this hardware will run two independent > code images, one for the server function and one for the router > function. One can think of several ways out of it: The piece of hardware could also be both a client and a router too. I can think of lots of reasons to intimately link telnet, rlogin, ftp, X, NFS client functionality intimately with the router functionality. > (a) The IP driver must be intelligent enough to hide the all-host > multicasts for the router code and to hide the all-router > multicasts for the server code. Such would mean we need to > start a discussion to find all potnetial problems and might > highly complicate the specifications for IPv6 This exercise would represent design and not protocol specification. > (b) The server must be hidden behind the router on a virtual LAN. > Your router would have three interfaces instead of two, two > physical Ethernets plus a virtual internal network. The server > will not be connected to one of the Ethernets, but to the > virtual LAN. (Do I hear someone murmul "IPX internal networks"? > ? ? Never heard of !) In that situation the server enters the > all-host multicast and the router the all-router multicast and > there is no confusion. Certainly, one can make such a design, but it is wrong to incorporate such design detail into a protocol specification. For some server and client functionality, such an architecture might make sense, but if there were a reason to use RPCs rather than local procedure calls for some router function (e.g. route table maintenance or link state database maintenance) hiding the server or client functionality behind a virtual LAN might not work well. > When we take a few days to think it over, we might find more and/or > better solutions, but I think we can solve it without having the > router in the all-host multicast. Such an issue is an issue of design, there is no right or wrong in choosing one way or another, and it should be left to design engineers when they are acting as design engineers not when they might be specifying protocols which is a very different type of engineering. > An extra point of consideration: May be someone should find out of > all the drafts when exactly "all-host" multicasts are planned to be > used, to see how big this issue is anyway. > Fred Rabouw 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 Nov 11 08:05:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11612; Fri, 11 Nov 94 08:05:41 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11606; Fri, 11 Nov 94 08:05:33 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22025; Fri, 11 Nov 94 08:01:14 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA09404; Fri, 11 Nov 94 08:00:52 PST Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14488(3)>; Fri, 11 Nov 1994 08:00:44 PST Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Fri, 11 Nov 1994 08:00:39 -0800 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Which m-cast groups to join? Date: Fri, 11 Nov 1994 08:00:32 PST From: Steve Deering Message-Id: <94Nov11.080039pst.34050@swallow.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [Sorry if you get this as a duplicate. I posted the original more than 14 hours ago and it still hasn't shown up on the list (at least from here), even though other messages I posted since then showed up within 15 minutes.] Based on responses to my recent message on this subject, here seems to be be confusion and/or disagreement about IPv6 "host" / "router" / "node" terminology, so let me try to clear it up or figure out if it needs to be changed. In the IPv4 world, the word "host" is ambiguous -- it is used to mean any of the following, *different* things: (1) Any box that runs IP. (This meaning is evident in the frequently heard comment: "remember that routers are hosts too.") (2) A box that runs IP but is not a router. (This meaning is evident in statements such as: "hosts shouldn't snoop on routing protocols", or in use of the term "multihomed hosts" for things that do not include routers.) (3) A box that runs IP and whose "primary" purpose or most common role is to run application software (e.g., if its faceplate says "Sun", or "Apple" it's a host, whereas if its faceplate says "Proteon" or "cisco", it's not a host). (There are also occasional arguments over whether a "host" is a box, i.e., a computer, or an entity or module or process running on a computer. And those arguments often segue into a discussion about whether or not a computer is one CPU or possibly many, and on it goes...) This ambiguity has led to lots of annoying interruptions in conversations ("When you say host, do you mean to include routers?"), unnecessary misunderstandings ("What do you mean, hosts shouldn't snoop routing protocols?! I insist on being able to use one of my Suns as a backup router for when my cisco fails!), and probably some misinterpretation of protocol specs. With SIP[P], I had *hoped* to eliminate that ambiguity, at least within the specs themselves and within the discussions of the people working on the specs. To that end, the SIP[P] (and now, IPv6) specs included the following definitions: node - a protocol module that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. The SIPP WG seemed to be comfortable with these definitions, but IPv6 is not SIPP, so I guess we have to open this up for debate in the IPng WG. *For the purposes of the IPv6-layer specs*, I believe we need clear and unambiguous terms for the three kinds of objects defined above. Most of the specs apply to all IPv6 implementations (i.e., all "nodes", in the SIPP terminology). For those specs specifically concerned with routing issues (in the general sense, which includes issues of address resolution, neighbor discovery, redirects, etc.), there is frequently a need to distinguish between forwarders ("routers") and non-forwarders ("hosts"). This distinction ought never be needed at any protocol layer above or below the Internet layer. Furthermore, the Internet-layer specifications ought to be faceplate-independent, so we don't need terms (*in this context*) to distinguish between boxes manufactured primarily to serve the role of routers vs. boxes built to be application support platforms. So, for the concepts: any IPv6 module forwarder non-forwarder --------------- --------- ------------- I have been using the terms: node router host A possible alternative, with some Internet historical validity, would be: system router host but I find the word "system" to be too vague and overloaded, relative to the word "node". Or there's the OSI terminology: system intermediate system end system which compounds the vagueness of "system" with verbosity. Another possibility would be: host router non-router which assigns the term "host" to any IPv6 box. Could we get used to saying "multihomed non-routers"? Or we could use: host router end host which lacks the cleanliness of one-word terms for each concept, but like host/router/non-router presumably would please those people who want to use the word "host" for any IPv6 box. ************************************************************************* I suggest that those people who feel that it is *essential* to change the IPv6 terminology from what is currently specified (node/router/host) present their arguments on the IPng list *over the next week only* (we have *much* more important things to argue about), and if there appears to be significant momentum behind an alternative set of terms, we'll make a choice at IETF in San Jose. OK? ************************************************************************* With that background, let me answer the responses to my earlier message: > From: stripes@uunet.uu.net (Josh Osborne): > > Ok, what kind of things do we only want non-routers to recieve? Router advertisements, probably. I say "probably", because we *may* decide that router advertisements should go to all nodes instead. If we end up deciding not to send any packets to the all-hosts (i.e., non-routers) address, that's OK -- we've got *lots* of multicast address space, so allocating one multicast address that turns out never to be used is no big deal. > May I also suggest we change the name of the group to "non-router"? > That should reduce mistakes (well the Auspex is just a NFS server, > not a genneral purpose host... well just because I made my file > server a router too doesn't mean it isn't still a host...). I think that that will just replace one possible confusion with another. ("This box isn't a router, it's a workstation! So what if it's forwarding packets?...") > From: jhalpern@newbridge.com (Joel Halpern) > > Since I have been unable to tell, after repeated discussions on the list > and reading the documents, can you tell me > Why are routers not hosts? Because "host" is defined to mean "not router", in our terminology. If we want to refer to something that may be either a host or a router, we use the term "node". > In my experience, every router has a full set of host protocol stacks > including FTP, Telnet, name daemon and lookup, etc. About the only > thing I don't usually find there is an SMTP entity. The distinction between host and router, in our context, has *nothing* to do with what higher-layer protocols are present. We have no need to be concerned about what higher-layer protocols are present. See, this is the kind of problem created by ambiguous definitions. > From: conta@zk3.dec.com: > > "Turning forwarding on" may not mean to some "start router functions". *The* distinction between a host and a router is that only the latter does forwarding (i.e., "has forwarding turned on"). [more precisely, "do forwarding" needs to be qualified by "of packets not explicitly addressed to itself", as in the full definition given above. Thus, a host may forward packets expicitly source-routed through it.] > It may rather mean only one of the steps into making a host a router, which > is setting a flag that has the role of enabling/disabling forwarding of > packets among the hosts' interfaces. Without the rest of the steps, a > multihomed host does not necessarily become a router in the sense described > above. The state of the "do forwarding" flag determines whether a box is a router or a host, *by definition*. It's a simple, unambiguous definition. If a router fails to do all the things a router is supposed to do (i.e., the "rest of the steps" you are referring to), it is a broken router, not a multihomed host. 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 Nov 11 08:18:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11631; Fri, 11 Nov 94 08:18:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11625; Fri, 11 Nov 94 08:18:33 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23154; Fri, 11 Nov 94 08:14:14 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA11699; Fri, 11 Nov 94 08:13:52 PST Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14506(2)>; Fri, 11 Nov 1994 08:13:39 PST Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Fri, 11 Nov 1994 08:13:27 -0800 To: Alan.Lloyd@datacraft.com.au Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) management of IP6 routers In-Reply-To: Alan.Lloyd's message of Thu, 05 May 94 11:35:44 -0800. <9411110810.AA20851@cms.datacraft.com.au> Date: Fri, 11 Nov 1994 08:13:17 PST From: Steve Deering Message-Id: <94Nov11.081327pst.34050@swallow.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, I'll leave this to a network-management expert to answer technically (do we have any of those on this list?), but most of the data structures that you listed are also present in an IPv4 implementation, so your arguments ought to apply equally to IPv4. I'd like to hear if people are really having problems with SNMP for managing IPv4, such that we need to consider changing that bit of Internet technology too as part of the IPv6 effort. 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 Nov 11 08:31:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11643; Fri, 11 Nov 94 08:31:37 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11637; Fri, 11 Nov 94 08:31:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24513; Fri, 11 Nov 94 08:27:07 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA14891; Fri, 11 Nov 94 08:26:31 PST Subject: Terminology (was: Re: (IPng) Which m-cast groups to join? To: IPng Mailing list Date: Fri, 11 Nov 1994 11:26:08 -0500 (EST) From: Dan McDonald Cc: 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: 455 Message-Id: <9411111626.aa25828@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thank you, Steve, for bringing a solid question to the forefront. What terms do we use for different types of IPv6 machines? I cast my vote^H^H^H^Hopinion (we reject voting :) towards the following: any IPv6 module forwarder non-forwarder --------------- --------- ------------- node router host I have no problem with this clear definition. 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 Fri Nov 11 08:39:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11655; Fri, 11 Nov 94 08:39:20 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11649; Fri, 11 Nov 94 08:39:13 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25385; Fri, 11 Nov 94 08:34:54 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA16728; Fri, 11 Nov 94 08:34:28 PST Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14527(4)>; Fri, 11 Nov 1994 08:29:19 PST Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Fri, 11 Nov 1994 08:29:14 -0800 To: mad@nero.dcrc.com (Mike Davis) Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) adding extension headers to a packet in flight In-Reply-To: mad's message of Fri, 11 Nov 94 05:53:41 -0800. <9411111353.AA19351@nero.dcrc.com> Date: Fri, 11 Nov 1994 08:28:59 PST From: Steve Deering Message-Id: <94Nov11.082914pst.34050@swallow.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Mike, > ...When forwarding a packet, routers are not required to > look any deeper into the packet than the Hop-by-Hop Options header which, > if present, immediately follows the base IPv6 header. . . . > > If this is true, then the Routing Header is of limited value. If no > router has to look at it, then a packet can get from source to > destination without regard to the Routing Header's contents, and the > destination certainly won't care about it. Sigh. That's what I get for trying to brief. Read "router" above as any router *not* explicitly listed in a routing header. When the routing header is in use, when a packet arrives at each explicitly-addressed router, the destination address is that router's own, which causes the router to start processing the enclosed headers, until it hits the routing header which tells it to install a new destination address and send the packet on to the next hop in the source route. 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 Nov 11 08:50:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11670; Fri, 11 Nov 94 08:50:14 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11664; Fri, 11 Nov 94 08:50:04 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26517; Fri, 11 Nov 94 08:45:45 PST Received: from ns.Novell.COM by Sun.COM (sun-barr.Sun.COM) id AA19593; Fri, 11 Nov 94 08:45:21 PST Received: from [130.57.64.151] by ns.Novell.COM (4.1/SMI-4.1) id AA18876; Fri, 11 Nov 94 09:32:52 MST Date: Fri, 11 Nov 94 09:32:50 MST Message-Id: <9411111632.AA18876@ns.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bob Hinden From: greg_minshall@Novell.COM Subject: (IPng) draft-hinden-ipng-ipv6-spec-00.txt Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, Here are some comments on your latest (i hope!) draft. 1. The ..X. bit of Hop-by-Hop option encodes "include in integrity checksum". I suspect that this is true for Hop-by-Hop, but not for End-to-End, is going to confuse people. This is especially unfortunate with things like options which tend to not get stressed much as implementations are developed and released, and then by the time bugs are discovered you have an installed base with incorrect behaviour. (How many TCPs, like *mine*, were fielded that couldn't grok TCP options in one way or the other?) I'd suggest simplifying by saying that the ..X. bit encodes "include in integrity checksum" for both Hop-by-Hop and End-to-End. 2. In the flow ID, you have the TClass field. First, i'd suggest dropping the whole field, at least for "flow-controlled" traffic. Second, if you are going to keep it, i'm not sure that the distinguishing characteristic between 0-7 and 8-15 should be "flow-controlled versus not". For example, much of the MBONE traffic may well be "flow-controlled" in the future, but may *still* want to indicate which packets are better to drop. I'm really at a loss, but one possibility would be to say the entire 0-15 is a drop priority within this source-destination pair, or some such. 3. "Unlike IPv4, when UDP [datagrams] are originated by an IPv6 node... if that computation yields a result of zero [(which will never happen on a 2s complement machine)], it must be changed to hex FFFF..." Almost all of our machines are 2s complement and this keeps an extra "if" from creeping into the checksum code. 4. (preparing to duck behind the wall...) Translating gateways are fundamentally evil, and should be abolished. Greg ------------------------------------------------------------------------------ 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 Nov 11 09:32:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11739; Fri, 11 Nov 94 09:32:35 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11733; Fri, 11 Nov 94 09:32:25 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA16443; Fri, 11 Nov 1994 09:27:48 -0800 Date: Fri, 11 Nov 1994 09:27:48 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411111727.JAA16443@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <94Nov11.080039pst.34050@swallow.parc.xerox.com> Subject: Re: (IPng) Which m-cast groups to join? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I think we should stick with the current terminology, e.g. > any IPv6 module forwarder non-forwarder > --------------- --------- ------------- > node router host 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 Fri Nov 11 09:56:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11845; Fri, 11 Nov 94 09:56:36 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11837; Fri, 11 Nov 94 09:56:24 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA17590; Fri, 11 Nov 1994 09:51:47 -0800 Date: Fri, 11 Nov 1994 09:51:47 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411111751.JAA17590@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9411111437.AA29583@Sun.COM> Subject: re: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, > >>Therefore, somewhere along the way, while the packet is winding its way > >>to the edge of the source enterprise, some router must ASSERT the > >>enterprise policy and ENFORCE particular routing decisions, and the only > >>way in hand right now is to insert routing headers. > > > >No, that's not the only way. You can prepend headers instead. > > That is correct. In THEORY an explicit route can be realized either via > encapsulation or via a special header. However, in PRACTICE the > implications of these two alternatives are quite different. I think you took the argument a bit too far. I think there is a middle ground here. The way I think this would be used would result in only one encapsulation header and that header would include a routing header. The source host would send it's datagrams without any routing header. The source host would not have any knowledge about any routing policies. When the datagrams reached the site border router (which did know about the sites routing policies), that border router would encapsulate the datagram in another header which included a routing header. The router header includes a source route which implements the sites routing policy. The datagrams would be forwarded in the normal manner (based on the routing header) to the destination site border router. This border router would de-encapsulated the datagram and forward it to the destination host inside of the site. 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 Fri Nov 11 10:00:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11857; Fri, 11 Nov 94 10:00:22 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11851; Fri, 11 Nov 94 10:00:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07416; Fri, 11 Nov 94 09:55:56 PST Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA02044; Fri, 11 Nov 94 09:55:23 PST Received: by pluto.dss.com (4.1/SMI-4.0) id AA02595; Fri, 11 Nov 94 12:55:12 EST From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9411111755.AA02595@pluto.dss.com> Subject: Re: (IPng) IPv6 Neighbor Discovery To: martillo@pluto.dss.com (Joachim Martillo) Date: Fri, 11 Nov 1994 12:55:10 -0500 (EST) Cc: ipng@sunroof.Eng.Sun.COM, mario@pluto.dss.com, Telford001@aol.com In-Reply-To: <9411111440.AA01157@pluto.dss.com> from "Joachim Martillo" at Nov 11, 94 09:40:03 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1090 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > It depends on what you mean by network management. I often consider > putting an SNMP network manager in the Constellation series bridge > routers. It already has built into it a forms menu interface which > would be perfect for managing Constellation series bridge routers and > it would not be too hard to add functionality to manage Cisco or Bay > networks routers. For minimal cost, customers would get a > high-performance bridge router + switch and an SNMP manager, but > obviously in this case the router MUST be in the all-host group even > though the whole purpose of the router functionality were network ^^^^^^ Actually, host was meant. > management. 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 Nov 11 10:19:07 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11916; Fri, 11 Nov 94 10:19:07 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11910; Fri, 11 Nov 94 10:18:59 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11050; Fri, 11 Nov 94 10:14:40 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA09919; Thu, 10 Nov 94 17:16:29 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14586(5)>; Thu, 10 Nov 1994 17:15:22 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Thu, 10 Nov 1994 17:15:08 -0800 To: stripes@uunet.uu.net (Josh Osborne) Cc: jhalpern@newbridge.com (Joel Halpern), conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: stripes's message of Thu, 10 Nov 94 04:55:11 -0800. Date: Thu, 10 Nov 1994 17:15:04 PST From: Steve Deering Message-Id: <94Nov10.171508pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Based on responses to my recent message on this subject, here seems to be be confusion and/or disagreement about IPv6 "host" / "router" / "node" terminology, so let me try to clear it up or figure out if it needs to be changed. In the IPv4 world, the word "host" is ambiguous -- it is used to mean any of the following, *different* things: (1) Any box that runs IP. (This meaning is evident in the frequently heard comment: "remember that routers are hosts too.") (2) A box that runs IP but is not a router. (This meaning is evident in statements such as: "hosts shouldn't snoop on routing protocols", or in use of the term "multihomed hosts" for things that do not include routers.) (3) A box that runs IP and whose "primary" purpose or most common role is to run application software (e.g., if its faceplate says "Sun", or "Apple" it's a host, whereas if its faceplate says "Proteon" or "cisco", it's not a host). (There are also occasional arguments over whether a "host" is a box, i.e., a computer, or an entity or module or process running on a computer. And those arguments often segue into a discussion about whether or not a computer is one CPU or possibly many, and on it goes...) This ambiguity has led to lots of annoying interruptions in conversations ("When you say host, do you mean to include routers?"), unnecessary misunderstandings ("What do you mean, hosts shouldn't snoop routing protocols?! I insist on being able to use one of my Suns as a backup router for when my cisco fails!), and probably some misinterpretation of protocol specs. With SIP[P], I had *hoped* to eliminate that ambiguity, at least within the specs themselves and within the discussions of the people working on the specs. To that end, the SIP[P] (and now, IPv6) specs included the following definitions: node - a protocol module that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. The SIPP WG seemed to be comfortable with these definitions, but IPv6 is not SIPP, so I guess we have to open this up for debate in the IPng WG. *For the purposes of the IPv6-layer specs*, I believe we need clear and unambiguous terms for the three kinds of objects defined above. Most of the specs apply to all IPv6 implementations (i.e., all "nodes", in the SIPP terminology). For those specs specifically concerned with routing issues (in the general sense, which includes issues of address resolution, neighbor discovery, redirects, etc.), there is frequently a need to distinguish between forwarders ("routers") and non-forwarders ("hosts"). This distinction ought never be needed at any protocol layer above or below the Internet layer. Furthermore, the Internet-layer specifications ought to be faceplate-independent, so we don't need terms (*in this context*) to distinguish between boxes manufactured primarily to serve the role of routers vs. boxes built to be application support platforms. So, for the concepts: any IPv6 module forwarder non-forwarder --------------- --------- ------------- I have been using the terms: node router host A possible alternative, with some Internet historical validity, would be: system router host but I find the word "system" to be too vague and overloaded, relative to the word "node". Or there's the OSI terminology: system intermediate system end system which compounds the vagueness of "system" with verbosity. Another possibility would be: host router non-router which assigns the term "host" to any IPv6 box. Could we get used to saying "multihomed non-routers"? Or we could use: host router end host which lacks the cleanliness of one-word terms for each concept, but like host/router/non-router presumably would please those people who want to use the word "host" for any IPv6 box. ************************************************************************* I suggest that those people who feel that it is *essential* to change the IPv6 terminology from what is currently specified (node/router/host) present their arguments on the IPng list *over the next week only* (we have *much* more important things to argue about), and if there appears to be significant momentum behind an alternative set of terms, we'll make a choice at IETF in San Jose. OK? ************************************************************************* With that background, let me answer the responses to my earlier message: > From: stripes@uunet.uu.net (Josh Osborne): > > Ok, what kind of things do we only want non-routers to recieve? Router advertisements, probably. I say "probably", because we *may* decide that router advertisements should go to all nodes instead. If we end up deciding not to send any packets to the all-hosts (i.e., non-routers) address, that's OK -- we've got *lots* of multicast address space, so allocating one multicast address that turns out never to be used is no big deal. > May I also suggest we change the name of the group to "non-router"? > That should reduce mistakes (well the Auspex is just a NFS server, > not a genneral purpose host... well just because I made my file > server a router too doesn't mean it isn't still a host...). I think that that will just replace one possible confusion with another. ("This box isn't a router, it's a workstation! So what if it's forwarding packets?...") > From: jhalpern@newbridge.com (Joel Halpern) > > Since I have been unable to tell, after repeated discussions on the list > and reading the documents, can you tell me > Why are routers not hosts? Because "host" is defined to mean "not router", in our terminology. If we want to refer to something that may be either a host or a router, we use the term "node". > In my experience, every router has a full set of host protocol stacks > including FTP, Telnet, name daemon and lookup, etc. About the only > thing I don't usually find there is an SMTP entity. The distinction between host and router, in our context, has *nothing* to do with what higher-layer protocols are present. We have no need to be concerned about what higher-layer protocols are present. See, this is the kind of problem created by ambiguous definitions. > From: conta@zk3.dec.com: > > "Turning forwarding on" may not mean to some "start router functions". *The* distinction between a host and a router is that only the latter does forwarding (i.e., "has forwarding turned on"). [more precisely, "do forwarding" needs to be qualified by "of packets not explicitly addressed to itself", as in the full definition given above. Thus, a host may forward packets expicitly source-routed through it.] > It may rather mean only one of the steps into making a host a router, which > is setting a flag that has the role of enabling/disabling forwarding of > packets among the hosts' interfaces. Without the rest of the steps, a > multihomed host does not necessarily become a router in the sense described > above. The state of the "do forwarding" flag determines whether a box is a router or a host, *by definition*. It's a simple, unambiguous definition. If a router fails to do all the things a router is supposed to do (i.e., the "rest of the steps" you are referring to), it is a broken router, not a multihomed host. 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 Nov 11 11:25:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11952; Fri, 11 Nov 94 11:25:55 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11946; Fri, 11 Nov 94 11:25:47 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22315; Fri, 11 Nov 94 11:21:29 PST Received: from CLYNN.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA19627; Fri, 11 Nov 94 11:21:01 PST Message-Id: <9411111921.AA19627@Sun.COM> Date: Fri, 11 Nov 94 14:11:31 EST From: Charles Lynn To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Which m-cast groups to join? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, Current practice has definite instances of boxes that forward packets sent to them but not addressed to them and do not participate in any routing protocol. To simply dismiss them by: > If a router fails to do all the things a router is supposed to do > (i.e., the "rest of the steps" you are referring to), it is a broken > router, not a multihomed host. seems to be just asking for more confusion in IPv6. I think it would be a lot easier for the community if they were acknowledged to exist, be useful in certain contexts, and have a clear specification of what multicast groups they should or should not join, etc. A term for them seems reasonable instead of repeating the two line description given above. 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 Nov 11 11:40:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11965; Fri, 11 Nov 94 11:40:23 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11959; Fri, 11 Nov 94 11:40:12 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24930; Fri, 11 Nov 94 11:35:53 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA22737; Fri, 11 Nov 94 11:35:26 PST To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) More comments on IPv6 draft spec Date: Fri, 11 Nov 94 19:34:40 GMT From: Ran Atkinson Message-Id: <9411111934.aa26231@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM (Quoted text below is from Greg Minshall) % 1. The ..X. bit of Hop-by-Hop option encodes "include in integrity % checksum". I suspect that this is true for Hop-by-Hop, but not for % End-to-End, is going to confuse people. This is especially % unfortunate with things like options which tend to not get stressed % much as implementations are developed and released, and then by the % time bugs are discovered you have an installed base with incorrect % behaviour. I'm not at all sure why you think this part of the spec is confusing. Please educate me on what part of it is confusing. % I'd suggest simplifying by saying that the ..X. bit encodes "include in % integrity checksum" for both Hop-by-Hop and End-to-End. The notion is that we have the "exclude from calculation" escape hatch mainly for the benefit of fields which must be altered _during transit_. My understanding is that stuff inside the End-to-End Header cannot, by definition, be changed during transit (if it did, it would by definition be a Hop-by-Hop option) hence it can (and should) always be included in the authentication calculation. % 4. (preparing to duck behind the wall...) Translating gateways are % fundamentally evil, and should be abolished. My experiences with translating gateways have all been strongly negative. I would not be saddened to see them disappear. 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 Fri Nov 11 12:37:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12052; Fri, 11 Nov 94 12:37:58 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12046; Fri, 11 Nov 94 12:37:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02842; Fri, 11 Nov 94 12:33:32 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA03555; Fri, 11 Nov 94 12:33:07 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14589(3)>; Fri, 11 Nov 1994 12:32:16 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Fri, 11 Nov 1994 12:32:06 -0800 To: Charles Lynn Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: clynn's message of Fri, 11 Nov 94 11:11:31 -0800. <9411111921.AA19627@Sun.COM> Date: Fri, 11 Nov 1994 12:32:05 PST From: Steve Deering Message-Id: <94Nov11.123206pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Charlie, > Current practice has definite instances of boxes that forward packets > sent to them but not addressed to them and do not participate in any > routing protocol. Of course. I never said that the things defined as "routers" necessarily participate in routing protocols. If it forwards packets not addressed to itself, it is defined to be a "router". If it doesn't, it's not. (Perhaps you are pointing up an ambiguity in the use of the term "router", similar to the ambiguities with "host". Does the word "router" always mean something that participates in routing protocols, to you? What word do you use for a box that does forwarding based only on wired-in or statically-configured forwarding entries?) > To simply dismiss them by: > > > If a router fails to do all the things a router is supposed to do > > (i.e., the "rest of the steps" you are referring to), it is a broken > > router, not a multihomed host. > > seems to be just asking for more confusion in IPv6. I think it would > be a lot easier for the community if they were acknowledged to exist, > be useful in certain contexts, and have a clear specification of what > multicast groups they should or should not join, etc. A term for them > seems reasonable instead of repeating the two line description given > above. The term for the boxes you are talking about is "router". They are acknowledged to exist. Why do you find my definition confusing? Various IPv6 protocol specs will specify what things routers MUST/SHOULD/ MAY/SHOULD NOT/MUST NOT do. For example: - Routers MAY participate in routing protocols. - Routers MUST join the all-routers multicast group. - Routers SHOULD emit Router Advertisements. - etc. (NOTE: these are only *examples* of possible requirements, not necessarily the actual requirements. The actual requirements will be whatever ends up in the specs that get adopted as Standards.) If a router violates any of the MUSTs or MUST NOTs, then it is a broken router (or a "non-conformant" router, if you prefer euphemisms). The SHOULDs and MAYs leave room for a wide variety of implementations, including the boxes you thought I was not acknowledging. Do we really have to invent entirely new terms ("nert", "eenert", "eyenert"?) because the familiar ones have too much semantic baggage? 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 Nov 11 12:56:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12084; Fri, 11 Nov 94 12:56:48 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12078; Fri, 11 Nov 94 12:56:41 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05198; Fri, 11 Nov 94 12:52:21 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA08835; Fri, 11 Nov 94 10:33:48 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14502(7)>; Fri, 11 Nov 1994 10:31:53 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Fri, 11 Nov 1994 10:31:41 -0800 To: yakov@watson.ibm.com Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) high-speed slicing and dicing of headers..... In-Reply-To: yakov's message of Fri, 11 Nov 94 06:35:06 -0800. <94Nov11.063728pst.14475(1)@alpha.xerox.com> Date: Fri, 11 Nov 1994 10:31:34 PST From: Steve Deering Message-Id: <94Nov11.103141pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Yakov, > ...In THEORY an explicit route can be realized either via > encapsulation or via a special header. However, in PRACTICE the > implications of these two alternatives are quite different. I agree entirely. I consider this conversation to be an attempt to identify the practical implications of each approach. > For example, if the the enterprise policy asserted by a router results > in a route that has N elements (A, B, C, D), then the encapsulation > approach would either result in N-times encapsulation (so that a packet > will carry at some point along the route N headers), or a coordination > with all the elements in the route that would allow these elements to > insert correct encapsulation... It is apparent that either I have not been writing clearly enough or you have not been reading my recent messages carefully enough. I am not arguing for exclusive use of encapsulation instead of the routing header -- both have their place. In particular, when an originator of a packet (and note that an entry point to a tunnel is an originator of a packet -- the encapsulating packet, not the payload packet) wishes to explicitly identify intermediate hops, then I claim that a routing header is the right thing to use. On the other hand, when a router that is not the originator of a packet wishes to exert explicit routing control over the packet, it should, in my opinion, prepend a new base header, for all the reasons I gave in my initial message in this thread. NOTE THAT, if the encapsulating router wishes to identify multiple intermediaries, it should prepend both a new fixed header *and* a routing header. Thus, for your example, I would have the enterprise's policy-asserting router emit a packet of the following form: encapsulating IPv6 header routing header original IPv6 header rest of original packet The encapsulating IPv6 header would contain the encapsulating router's address as its source (so error messages go to the right place), and A as its destination. The routing header would contain addresses B, C, and D (assuming D is the last hop before the ultimate destination). The original header contains the original source address and the ultimate destination address. I think if you count up the bytes in my scheme and in the ERP scheme, that you will find that my scheme takes either exactly the same number of bytes or at most 8 more bytes than your scheme. (I am asking you to do the counting, because I am still fuzzy on some of the details of ERP.) And as the designer of the extension header mechanism of IPv6, and someone who has experience with both forms of header munging (in MBone tunnels), it is my judgement that this is, architecturally, the "right" way to do in-transit explicit route assertion for IPv6. 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 Nov 11 13:14:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12133; Fri, 11 Nov 94 13:14:23 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12127; Fri, 11 Nov 94 13:14:12 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07693; Fri, 11 Nov 94 13:09:53 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA09096; Fri, 11 Nov 94 13:09:18 PST Received: by nero.dcrc.com (4.1/1.34) id AA20462; Fri, 11 Nov 94 15:52:58 EST Date: Fri, 11 Nov 94 15:52:58 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411112052.AA20462@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Which m-cast groups to join? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM As one who agitated a little about this terminology thing, I thought I would post another thought on the subject. Given Steve Deering's recent message implying that we would soon be putting together a sort of "IPng router requirements" doc, I will stop my fussing over definitions and instead beg to see this document sooner rather than later. My real concern is to know what I have to implement in the packet-forwarding-device that I write code for, in order for it to forward (and occasionally originate) packets. Thank you. -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 Nov 11 13:14:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12145; Fri, 11 Nov 94 13:14:45 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12134; Fri, 11 Nov 94 13:14:31 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07726; Fri, 11 Nov 94 13:10:13 PST Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA09215; Fri, 11 Nov 94 13:09:46 PST Received: by pluto.dss.com (4.1/SMI-4.0) id AA04170; Fri, 11 Nov 94 16:09:40 EST From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9411112109.AA04170@pluto.dss.com> Subject: Re: (IPng) Which m-cast groups to join? To: ipng@sunroof.Eng.Sun.COM Date: Fri, 11 Nov 1994 16:09:38 -0500 (EST) Cc: stripes@uunet.uu.net, jhalpern@newbridge.com, conta@zk3.dec.com, deering@parc.xerox.com, mario@pluto.dss.com (Mario Savvides) In-Reply-To: <94Nov10.171508pst.12173@skylark.parc.xerox.com> from "Steve Deering" at Nov 10, 94 05:15:04 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1190 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Based on responses to my recent message on this subject, here seems to be > be confusion and/or disagreement about IPv6 "host" / "router" / "node" > terminology, so let me try to clear it up or figure out if it needs to be > changed. > In the IPv4 world, the word "host" is ambiguous -- it is used to mean any of > the following, *different* things: > (1) Any box that runs IP. (This meaning is evident in the frequently > heard comment: "remember that routers are hosts too.") There is some logic to calling anything that has at least one Host ID an host. As for multihomed hosts or non-routers, I should point out that it would not be unreasonable to run a multihomed host which has perhaps 3 interfaces as a router across two interfaces and as an end host along the third interface. 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 Nov 11 14:49:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12271; Fri, 11 Nov 94 14:49:19 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12265; Fri, 11 Nov 94 14:49:12 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25587; Fri, 11 Nov 94 14:44:52 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA28544; Fri, 11 Nov 94 14:44:01 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14563(6)>; Fri, 11 Nov 1994 14:43:41 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Fri, 11 Nov 1994 14:43:29 -0800 To: martillo@pluto.dss.com (Joachim Martillo) Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: martillo's message of Fri, 11 Nov 94 13:09:38 -0800. <9411112109.AA04170@pluto.dss.com> Date: Fri, 11 Nov 1994 14:43:17 PST From: Steve Deering Message-Id: <94Nov11.144329pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joachim, > There is some logic to calling anything that has at least one Host ID > an host. I don't remember if we have anything called a Host ID in IPv6 (maybe that's what we've called the lowest-order element in an address?), but if we do, it should probably be changed to Node ID (unless and until we decide to change our terminology). > As for multihomed hosts or non-routers, I should point out > that it would not be unreasonable to run a multihomed host which has > perhaps 3 interfaces as a router across two interfaces and as an end > host along the third interface. Now that's an interesting observation. So, is "routerness" a property of an interface, rather than a property of a node? Or maybe it's a property of an interface half (you could permit forwarding of packets *from* a particular interface, but not *to* that interface, or vice versa). Or should we make up new terms (houter? roust?) for such schizophrenic boxes? We could *really* drag this out... 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 Nov 11 17:27:11 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12486; Fri, 11 Nov 94 17:27:11 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12473; Fri, 11 Nov 94 17:26:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20851; Fri, 11 Nov 94 17:22:31 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA03428; Fri, 11 Nov 94 17:22:09 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-07.dialip.mich.net [141.211.7.18]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id UAA24594 for ; Fri, 11 Nov 1994 20:22:05 -0500 Date: Sat, 12 Nov 94 00:36:12 GMT From: "William Allen Simpson" Message-Id: <3429.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) node/host/router Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Steve Deering > [Sorry if you get this as a duplicate. I posted the original more than > 14 hours ago and it still hasn't shown up on the list (at least from here), > even though other messages I posted since then showed up within 15 minutes.] > Yeah, I've been having the same problem. > The SIPP WG seemed to be comfortable with these definitions, but IPv6 is > not SIPP, so I guess we have to open this up for debate in the IPng WG. > Why? Is _everything_ up for debate? Can't we just take the results of the SIPP design team, and get on with it? For the record, I hate ambiguity, and like the clear terms node/host/router. I kept changing the drafts to match the changes as we discussed this in SIPP. All of my drafts use the terms, and I'd _really_ be annoyed to change them again. 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 Nov 11 17:27:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12493; Fri, 11 Nov 94 17:27:18 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12479; Fri, 11 Nov 94 17:26:52 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20859; Fri, 11 Nov 94 17:22:33 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA03433; Fri, 11 Nov 94 17:22:11 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-07.dialip.mich.net [141.211.7.18]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id UAA24597 for ; Fri, 11 Nov 1994 20:22:08 -0500 Date: Sat, 12 Nov 94 00:41:23 GMT From: "William Allen Simpson" Message-Id: <3430.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Service Discovery 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)) > To Bill: These 1000 time-outs only happens because the server does > not advertise its media address. In your neighbor discovery > specifications you also define a Server-Advertisement, but at the > moment nothing is done with it. You might add something like: > > Each server MUST have a (configurable) switch whether it will send > Server-Advertisements. If Server-Advertisements are send, it will > be done with an interval of SERVER-ADVERTISEMENT-INTERVAL seconds > (default: ... ) > Yes, in the early drafts, routers were just a type of server. One simple elegant discovery mechanism. All servers advertised periodically, including routers. But, the SIPP design team decided to split off servers from routers, and other methods of service discovery were discussed, particularly anycast. Since then, the IPv4 Service Location WG has started to use multicast, and we may not have to define an IPv6 discovery for servers. For now, I'm removing the service parts from the drafts, until I've had a chance to see how SvrLoc fits into IPv6. 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 Nov 11 17:27:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12504; Fri, 11 Nov 94 17:27:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12487; Fri, 11 Nov 94 17:27:11 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20909; Fri, 11 Nov 94 17:22:52 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA03439; Fri, 11 Nov 94 17:22:14 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-07.dialip.mich.net [141.211.7.18]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id UAA24600 for ; Fri, 11 Nov 1994 20:22:11 -0500 Date: Sat, 12 Nov 94 00:50:20 GMT From: "William Allen Simpson" Message-Id: <3431.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 Neighbor Discovery 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 that situations a network manager can take care of this timing out > plus many sollicitations. Another option is: > > A node MIGHT have a (configurable) switch controlling whether > General-Advertisements are send to the unicast address or to the > all-hosts multicast address. > > I agree, configurations, configurations, but the requirements for > very small and very big subnets are different and (CPU/disk/memory) > resources in hosts are different. What is optimal for one network > might be counter productive in other networks. > This is a good idea. I've been talking with others about a similar idea. Instead of a configuration, just look at the number of active destinations in the Hop Cache. If it is less than 4, use Unicast. Otherwise, use All-Nodes multicast. Thanks. 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 Nov 11 18:41:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12588; Fri, 11 Nov 94 18:41:45 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12582; Fri, 11 Nov 94 18:41:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27977; Fri, 11 Nov 94 18:37:18 PST Received: from databus.databus.com by Sun.COM (sun-barr.Sun.COM) id AA03593; Fri, 11 Nov 94 18:36:53 PST Date: Fri, 11 Nov 94 21:36 EST Message-Id: <9411112136.AA02393@databus.databus.com> From: Barney Wolff To: ipng@sunroof.Eng.Sun.COM Subject: Re: Terminology (was: Re: (IPng) Which m-cast groups to join? Content-Length: 1643 Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > any IPv6 module forwarder non-forwarder > --------------- --------- ------------- > node router host Here I go revealing my ignorance again: If my host wants to Telnet to the management interface at a router, what, if anything, does my IPv6 stack and/or my Ethernet driver do differently than it would if I were talking to a non-routing host? Does the stack have to make a test, at any point, for what kind of node a packet is going to, or is it just that a router's Ethernet address will already be in the ARP cache (or equivalent) because the router is advertising? I'm not asking quite innocently - if my stack has to do something different when a router is the intended direct destination of a packet, than it would for a non-router, I don't like that. In particular, if the router's link-layer address is not in my cache, for whatever reason, I want to be able to solicit it (or send the packet to the hashed multicast address, whatever is decided) just the way I would if it were not a router - so the router needs to listen to that link-layer address. If the router wasn't in my cache, I didn't know it was a router, so I *can't* do anything other than I would ordinarily do. And, as has been pointed out, we can't insist that a lightweight host on a big link-layer network keep track of every router. Router advertisement is a heuristic that wins most of the time on most networks. We shouldn't either give it up or make it the only way to learn the link-layer address of the router. 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 Fri Nov 11 19:20:33 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12605; Fri, 11 Nov 94 19:20:33 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12599; Fri, 11 Nov 94 19:20:25 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01341; Fri, 11 Nov 94 19:16:06 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA08560; Fri, 11 Nov 94 19:15:45 PST Received: from swallow.parc.xerox.com ([13.2.116.18]) by alpha.xerox.com with SMTP id <14505(2)>; Fri, 11 Nov 1994 19:15:19 PST Received: from localhost by swallow.parc.xerox.com with SMTP id <34050>; Fri, 11 Nov 1994 19:15:12 -0800 To: Barney Wolff Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng) Re: Terminology In-Reply-To: barney's message of Fri, 11 Nov 94 18:36:00 -0800. <9411112136.AA02393@databus.databus.com> Date: Fri, 11 Nov 1994 19:15:08 PST From: Steve Deering Message-Id: <94Nov11.191512pst.34050@swallow.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Here I go revealing my ignorance again: If my host wants to Telnet > to the management interface at a router, what, if anything, does my > IPv6 stack and/or my Ethernet driver do differently than it would > if I were talking to a non-routing host? Does the stack have to > make a test, at any point, for what kind of node a packet is going > to, or is it just that a router's Ethernet address will already be > in the ARP cache (or equivalent) because the router is advertising? The latter. > I'm not asking quite innocently - if my stack has to do something > different when a router is the intended direct destination of a > packet, than it would for a non-router, I don't like that. In > particular, if the router's link-layer address is not in my cache, > for whatever reason, I want to be able to solicit it (or send the > packet to the hashed multicast address, whatever is decided) just > the way I would if it were not a router - so the router needs to > listen to that link-layer address. If the router wasn't in my > cache, I didn't know it was a router, so I *can't* do anything > other than I would ordinarily do. Exactly right. Of course, you won't be sending a Router Solicitation (since you don't know that the thing you are soliciting is a router) -- it'll be a General Solicitation. 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 Nov 11 19:56:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12637; Fri, 11 Nov 94 19:56:54 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12619; Fri, 11 Nov 94 19:56:24 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02891; Fri, 11 Nov 94 19:52:06 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11690; Fri, 11 Nov 94 19:51:43 PST 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 WAA06565 for ; Fri, 11 Nov 1994 22:51:41 -0500 Date: Sat, 12 Nov 94 03:01:51 GMT From: "William Allen Simpson" Message-Id: <3434.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) draft-hinden-ipng-ipv6-spec-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I'd suggest simplifying by saying that the ..X. bit encodes "include in > integrity checksum" for both Hop-by-Hop and End-to-End. > The End-to-End is always integrity checked, so it would be a pointless bit. Instead, I'd suggest finishing the document split (as we agree a couple of meetings ago). We all understand that different protocols may have different encodings. These are different "protocol" numbers (headers), and should be in different documents just like all other unrelated protocols. > Second, if you are going to keep it, i'm not sure that the distinguishing > characteristic between 0-7 and 8-15 should be "flow-controlled versus not". > For example, much of the MBONE traffic may well be "flow-controlled" in > the future, but may *still* want to indicate which packets are better to > drop. I'm really at a loss, but one possibility would be to say the entire > 0-15 is a drop priority within this source-destination pair, or some such. > I concur. > 4. (preparing to duck behind the wall...) Translating gateways are > fundamentally evil, and should be abolished. > Hear, Hear!!! 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 Nov 11 19:56:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12638; Fri, 11 Nov 94 19:56:56 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12624; Fri, 11 Nov 94 19:56:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02894; Fri, 11 Nov 94 19:52:07 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11694; Fri, 11 Nov 94 19:51:45 PST 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 WAA06568 for ; Fri, 11 Nov 1994 22:51:43 -0500 Date: Sat, 12 Nov 94 03:07:23 GMT From: "William Allen Simpson" Message-Id: <3435.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Implementor Minutes - Thanks Bob Hinden Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: bound@zk3.dec.com > I am working on rooms for us Sunday Dec 3 1-6 p.m. and Fri Dec 9 9-Noon > at the Fairmont Hotel for implementors meeting. Waiting to hear back > from Megan. > Wait a minute! We agreed on a Friday meeting at Boston. I've already bought my (non-refundable) plane tickets, and am not arriving until 10:40 pm Sunday, and staying through the Friday. One day worked just fine in Toronto. And why is a non-chair organizing this? 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 Nov 11 19:57:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12639; Fri, 11 Nov 94 19:57:01 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12631; Fri, 11 Nov 94 19:56:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02897; Fri, 11 Nov 94 19:52:10 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA11699; Fri, 11 Nov 94 19:51:48 PST 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 WAA06571 for ; Fri, 11 Nov 1994 22:51:45 -0500 Date: Sat, 12 Nov 94 03:12:14 GMT From: "William Allen Simpson" Message-Id: <3436.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) embedded IEEE Addresses Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > This allows (that I can see right now), three quite different > kinds off autoconf servers... > I agree that your list of possible methods is a good beginning. There is also a fourth. The HOST makes the address. We MUST have this in order to communicate with the auto-configuration service, and to operate in the "dentist office" environment. > The substance to my original comment was that for this to > be practical, hosts must not attempt to construct their own > addresses Wrong!!! Hosts MUST construct their own addresses. Those addresses are called "local-use" for a reason. > But this does not mean that IEEE addresses in IPv6 addresses > are unnecessary, they'll be useful for the the first kind of > which is likely to be both the default > style, andd thee most popular. > I'd be very surprised, since we should NEVER give any site a large enough allocation to waste 48 bits at the bottom of their address. Assignment in CIDR sized blocks certainly won't allow it. > Note, its my personal preference, which I don't believe that > most of the rest fo the addrconf group shares (and perhaps none > do), ... > I do not support using ICMP for addrconf > purposes, I'd prefer to use specific link level packets for > this (UDP if it has to be IPv6 based) - that is, PPP address > negotiation over PPP links, perhaps something like RARP on > ethernet, etc. Blech! And I certainly don't. As far as I know, PPP is not adding support for IPv6. IPv6 is supposed to self-configure. That's why we have a requirements draft. > The first thing is simply to delete all references to > address assignment, which is the province of addrconf. Discovery of the address is extremely important to discovery. Once, they were all in the same document. They are no longer in the processing and formats drafts, as addrconf drafts are being written by someone else, but they will remain in the requirements draft! It is up to addrconf to conform to the requirements. 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 Nov 11 20:09:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12664; Fri, 11 Nov 94 20:09:13 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12658; Fri, 11 Nov 94 20:09:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03636; Fri, 11 Nov 94 20:04:43 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA12525; Fri, 11 Nov 94 20:04:21 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id XAA13380 for ipng@sunroof.Eng.Sun.COM; Fri, 11 Nov 1994 23:05:53 -0500 (EST) Date: Fri, 11 Nov 1994 23:05:53 -0500 (EST) From: Scott Bradner Message-Id: <199411120405.XAA13380@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Implementor Minutes - Thanks Bob Hinden Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > And why is a non-chair organizing this? Bill, A number of people have a problem with the IETF having implementers meetings as an IETF function. It is far easier for a non-chair to be able to say that the meeting has no IETF status, it is just co-located. (like the appletalk group a while back) - also Jim has organized this type of meeting before (a SIPP one and the Cambridge IPng one) Scott (as AD) ------------------------------------------------------------------------------ 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 Nov 12 09:26:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12743; Sat, 12 Nov 94 09:26:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12737; Sat, 12 Nov 94 09:26:32 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16404; Sat, 12 Nov 94 09:22:13 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA14894; Sat, 12 Nov 94 09:21:50 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id MAA14133 for ipng@sunroof.Eng.Sun.COM; Sat, 12 Nov 1994 12:23:24 -0500 (EST) Date: Sat, 12 Nov 1994 12:23:24 -0500 (EST) From: Scott Bradner Message-Id: <199411121723.MAA14133@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) requirements Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > as addrconf drafts are being written > by someone else, but they will remain in the requirements draft! It is > up to addrconf to conform to the requirements. It should be noted that the referenced requirements draft was not on the list of documents referred to the ipng working group in the ipng AD's recommendation. 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 Sat Nov 12 10:41:22 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12827; Sat, 12 Nov 94 10:41:22 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12815; Sat, 12 Nov 94 10:41:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17675; Sat, 12 Nov 94 10:36:44 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA17513; Sat, 12 Nov 94 10:36:21 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-13.dialip.mich.net [141.211.7.55]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA21386 for ; Sat, 12 Nov 1994 13:36:18 -0500 Date: Sat, 12 Nov 94 18:18:03 GMT From: "William Allen Simpson" Message-Id: <3443.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Discovery Hop Limit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Had another idea to eliminate user configuration. The Hop Limit (IPv4 TTL) is currently 64. It may change someday. Rather than have each user update their system, the routers can advertise the current Hop Limit to use. Thus, it is only a network administrator problem, and fewer places need to be updated. Done. 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 Sat Nov 12 10:41:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12828; Sat, 12 Nov 94 10:41:26 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12821; Sat, 12 Nov 94 10:41:05 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17684; Sat, 12 Nov 94 10:36:47 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA17517; Sat, 12 Nov 94 10:36:23 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-13.dialip.mich.net [141.211.7.55]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA21389 for ; Sat, 12 Nov 1994 13:36:21 -0500 Date: Sat, 12 Nov 94 18:20:40 GMT From: "William Allen Simpson" Message-Id: <3444.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Discovery QoS Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM IPv4 had a QoS per redirect. IPv6 has no QoS field. I still have a QoS in the Redirect like IPv4. Should I get rid of it? 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 Sat Nov 12 12:38:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12859; Sat, 12 Nov 94 12:38:54 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12853; Sat, 12 Nov 94 12:38:46 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20301; Sat, 12 Nov 94 12:34:28 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA21799; Sat, 12 Nov 94 12:34:00 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01349; Sun, 13 Nov 1994 07:18:01 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM, addrconf@cisco.com Subject: Re: (IPng) embedded IEEE Addresses In-Reply-To: Your message of "Sat, 12 Nov 1994 03:12:14 GMT." <3436.bill.simpson@um.cc.umich.edu> Date: Sun, 13 Nov 1994 07:17:55 +1100 Message-Id: <13255.784671475@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Sat, 12 Nov 94 03:12:14 GMT From: "William Allen Simpson" Message-ID: <3436.bill.simpson@um.cc.umich.edu> There is also a fourth. The HOST makes the address. This one I oppose, its the one I think should never happen. We MUST have this in order to communicate with the auto-configuration service, This presupposes that we're using IPv6 to communicate with autoconfiguration, which I would prefer not to do, and that a valid address of some kind is needed even in that eventuality, which doesn't really have to happen. and to operate in the "dentist office" environment. This one is the hard case here .. my model would actually be that hosts still don't assign their own addresses, but rather they look for an addrconf server, always, if no addrconf server is found, then a host simply starts a simple, stateless, one and runs it, answering queries initially from itself, and then from other hosts with "local use" addresses with a very short lease time (of the order of a few minutes probably) until another addrconf server is observed running, at which point it simply turns off its server. This basically means that the first host on a cable (or partitioned piece of cable) becomes the addrconf server for that cable until something more reliable is located. When the clients with local use addresses come to renew them after their short lease expires and a real server is running, that server will invalidate the local use address. If several hosts all decide to become addrconf servers at the same instant, that's OK, the algorithm that they all use is identical, they will notice each other and turn off anyway. This will only happen as a race condition, any other addrconf server that starts later will be a configured one - except where two segments without configured servers join. In that case all previous temporary host based servers will see the others and turn off. The first host that needs to renew its lease will fail to find any addrconf server at all, and start its local simple one. The advantage of this is that if an addrconf server exists on a cable, hosts never construct addresses of their own, and if net management doesn't want some particular host to operate on this cable, it will simply be denied an address, and won't be able to communicate, even locally. Wrong!!! Hosts MUST construct their own addresses. Wrong!!!! (I have more !'s than you do, so I MUST be right.) Those addresses are called "local-use" for a reason. Yes, I understand that, but even local use is not necessarily valid use. I'd be very surprised, since we should NEVER give any site a large enough allocation to waste 48 bits at the bottom of their address. Personally, I agree with that. I also expect that this is exactly what will not happen, and that the minimum that a site is likely to get is of the order of 64 bits. Its incredibly wasteful, but it does allow the trivially simple algorithms for address assignment that people seem to want. > purposes, I'd prefer to use specific link level packets for > this (UDP if it has to be IPv6 based) Blech! And I certainly don't. I had gathered that. I believe I understand the reasons that people don't like link specific packets, though I don't agree with them. I have absolutely no comprehension why anyone would want to use ICMP over UDP for a query/request type protocol (as distinct from sending error/diagnostic type messages). I'm still looking for someone to attempt to explain that one. As far as I know, PPP is not adding support for IPv6. Then ask it to. Adding an extra address format to the address negotiation can't be that large a task can it? kre ps: this topic has diverged well off ipng list business and into addrconf, I am sending this to both lists, with the intent that it be moved to addrconf. I have added a Reply-To directing replies to addrconf@cisco.com however I believe that that revolting software that runs the ipng list will destroy that and direct replies back to ipng. If you reply to this please override that, and reply only to addrconf@cisco.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 Nov 13 02:00:47 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13243; Sun, 13 Nov 94 02:00:47 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13237; Sun, 13 Nov 94 02:00:36 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04247; Sun, 13 Nov 94 01:56:17 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22130; Sun, 13 Nov 94 01:55:53 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-12.dialip.mich.net [35.1.48.93]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id EAA05498 for ; Sun, 13 Nov 1994 04:55:51 -0500 Date: Sun, 13 Nov 94 09:29:47 GMT From: "William Allen Simpson" Message-Id: <3447.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) requirements Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Scott Bradner > It should be noted that the referenced requirements draft was not on > the list of documents referred to the ipng working group in the ipng > AD's recommendation. > Then, either: 1) the AD's recommendation is incomplete, or 2) the AD made a formal decision not to include Neighbor Discovery. Please clarify. 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 Nov 13 11:36:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13371; Sun, 13 Nov 94 11:36:15 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13365; Sun, 13 Nov 94 11:36:08 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09658; Sun, 13 Nov 94 11:31:49 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA07245; Sun, 13 Nov 94 11:31:25 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14486(5)>; Sun, 13 Nov 1994 11:31:18 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Sun, 13 Nov 1994 11:31:13 -0800 To: "William Allen Simpson" Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Discovery Hop Limit In-Reply-To: bill.simpson's message of Sat, 12 Nov 94 10:18:03 -0800. <3443.bill.simpson@um.cc.umich.edu> Date: Sun, 13 Nov 1994 11:31:01 PST From: Steve Deering Message-Id: <94Nov13.113113pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, > Rather than have each user update their system, the routers can > advertise the current Hop Limit to use. Sounds like a good idea to me. The spec should say that hosts should use the max of the recommended Hop Limits, in cases where different routers are advertising different values. Make sure you also still require that this value be manually-configurable in hosts, for hosts attached to links that do not support router advertisements (e.g., X.25), or links on which router advertisements have been manually disabled for whatever reason. You should still specify a default value for cases when no advertisements have been heard and no manual configuration has been done. If you agree with the implication of the previous paragraph that there may be routers present but not advertising, then the default should be something larger than 1. We might also think about distributing the recommended initial Hop Limit in routing protocols, so upping the value in one router can cause all the other routers in the same routing domain to up their advertised values. > Done. I suggest that you wait a while to see if anyone identifies any problems with your idea before declaring it a done deal. 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 Sun Nov 13 11:50:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13383; Sun, 13 Nov 94 11:50:21 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13377; Sun, 13 Nov 94 11:50:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09920; Sun, 13 Nov 94 11:45:55 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA07720; Sun, 13 Nov 94 11:45:31 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14422(5)>; Sun, 13 Nov 1994 11:45:19 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Sun, 13 Nov 1994 11:45:15 -0800 To: "William Allen Simpson" Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) Discovery QoS In-Reply-To: bill.simpson's message of Sat, 12 Nov 94 10:20:40 -0800. <3444.bill.simpson@um.cc.umich.edu> Date: Sun, 13 Nov 1994 11:45:11 PST From: Steve Deering Message-Id: <94Nov13.114515pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > IPv4 had a QoS per redirect. IPv6 has no QoS field. Actually, IPv4 has ToS, not QoS. :-) > I still have a QoS in the Redirect like IPv4. Should I get rid of it? Yes, I think. My intention was that the TClass field could effect queueing behavior, but was not meant to effect the routing of a packet, so the argument in favor of Redirect for ToS does not apply to TClass. (I recognize that this point of view is non-obvious and subject to change, but until it does change, I don't think we should specify TClass-granularity redirects.) There may be a need to redirect just those packets belonging to a particular flow, but it would be the reponsibility of the flow set-up protocol to include a Redirect Flow message, if needed. 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 Sun Nov 13 11:56:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13395; Sun, 13 Nov 94 11:56:49 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13389; Sun, 13 Nov 94 11:56:42 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10045; Sun, 13 Nov 94 11:52:24 PST Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA07962; Sun, 13 Nov 94 11:52:00 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14422(8)>; Sun, 13 Nov 1994 11:51:50 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Sun, 13 Nov 1994 11:51:46 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: Re: (IPng) Discovery QoS In-Reply-To: deering's message of Sun, 13 Nov 94 11:45:11 -0800. <94Nov13.114515pst.12173@skylark.parc.xerox.com> Date: Sun, 13 Nov 1994 11:51:36 PST From: Steve Deering Message-Id: <94Nov13.115146pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Yes, I think. My intention was that the TClass field could effect queueing > behavior, but was not meant to effect the routing of a packet, ... Oops, excuse the grammatical gaffe. Change "effect" to "affect" above. 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 Sun Nov 13 18:06:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13570; Sun, 13 Nov 94 18:06:46 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13564; Sun, 13 Nov 94 18:06:39 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17702; Sun, 13 Nov 94 18:02:20 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22163; Sun, 13 Nov 94 18:01:48 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA24158; Mon, 14 Nov 1994 13:00:55 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25280; Mon, 14 Nov 94 11:54:52 +1100 Message-Id: <9411140054.AA25280@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Mon, 14 Nov 94 10:58:08 AUS Date: Mon, 14 Nov 94 10:38:01 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: (IPng) node/host/router To: ipng@sunroof.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM my view, node, host and router are ok by me. Host = End System. something that does not forward IP packets and provides a IP Service Interface to a higher layer function. Router = Intermediate System. somthing that does forward IP packets ** . Node = either of the above. ** The exception in a router is that it provides a IP6 service interface to its management entity (SNMP/Telnet). ie. its application is only there to serve the basic needs of the router. Therefore the router because of this function is not considered a "host" Host and Router are Functions. They can be combined in an implementation. 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 Sun Nov 13 18:07:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13582; Sun, 13 Nov 94 18:07:15 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13576; Sun, 13 Nov 94 18:07:08 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17708; Sun, 13 Nov 94 18:02:49 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22188; Sun, 13 Nov 94 18:02:21 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA24242; Mon, 14 Nov 1994 13:02:00 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25303; Mon, 14 Nov 94 12:00:09 +1100 Message-Id: <9411140100.AA25303@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Mon, 14 Nov 94 11:03:24 AUS Date: Mon, 14 Nov 94 10:38:01 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: (IPng) node/host/router To: ipng@sunroof.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Forwarded to: internet[ipng@sunroof.eng.sun.com] cc: Comments by: Alan Lloyd@Marketing@DCTHQ -------------------------- [Original Message] ------------------------- my view, node, host and router are ok by me. Host = End System. something that does not forward IP packets and provides a IP Service Interface to a higher layer function. Router = Intermediate System. somthing that does forward IP packets ** . Node = either of the above. ** The exception in a router is that it provides a IP6 service interface to its management entity (SNMP/Telnet). ie. its application is only there to serve the basic needs of the router. Therefore the router because of this function is not considered a "host" Host and Router are Functions. They can be combined in an implementation. 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 Sun Nov 13 18:09:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13594; Sun, 13 Nov 94 18:09:02 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13588; Sun, 13 Nov 94 18:08:55 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17813; Sun, 13 Nov 94 18:04:36 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22302; Sun, 13 Nov 94 18:03:55 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA24257; Mon, 14 Nov 1994 13:02:42 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25355; Mon, 14 Nov 94 12:20:45 +1100 Message-Id: <9411140120.AA25355@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Mon, 14 Nov 94 11:24:01 AUS Date: Mon, 14 Nov 94 11:03:49 AUS From: Alan.Lloyd@datacraft.com.au Subject: (IPng) IP6 authentication To: ipng@sunroof.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM fogive me cos I do not have SIPP AUTH. but will get it. DO I have a mis conception with Authentication. the SIPP doc 4.6 says "All SIPP NODES". the IPNG Recommendation doc 11.1 - * security-- "encryption at the internetwork layer". I made an assumption that authentication (ie proof of originator) can be performed within any node of the network. Yet some posts say it is end to end. If it is end to end then the Authentication Hdr should really be part of ESP (ie keep all the security in one place). If it is not end to end then each node in the network could verify the authentication hdr. Believing that the Internet in total requires some optional security function, the router processing option is the answer. So please confirm. Is "Authentication" end to end or any node. If it is End to End the Auth Hdr can be moved to ESP. 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 Sun Nov 13 18:10:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13606; Sun, 13 Nov 94 18:10:12 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13600; Sun, 13 Nov 94 18:10:04 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17861; Sun, 13 Nov 94 18:05:45 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22426; Sun, 13 Nov 94 18:05:16 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA24314; Mon, 14 Nov 1994 13:05:03 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25426; Mon, 14 Nov 94 13:14:29 +1100 Message-Id: <9411140214.AA25426@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Mon, 14 Nov 94 12:17:46 AUS Date: Mon, 14 Nov 94 12:11:12 AUS From: Alan.Lloyd@datacraft.com.au Subject: (IPng) December meeting - Hotels. To: cclark@cnri.reston.va.us, ipng@sunroof.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sorry to bother the list with this. Unable to get into the Fairmont, no response from the De Anza. So can any one suggest an alternative hotel or three somewhere near the Fairmont for similar (or lower) price. 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 Sun Nov 13 18:13:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13618; Sun, 13 Nov 94 18:13:50 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13612; Sun, 13 Nov 94 18:13:43 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18002; Sun, 13 Nov 94 18:09:24 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA22841; Sun, 13 Nov 94 18:08:48 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AB24421; Mon, 14 Nov 1994 13:08:35 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA25252; Mon, 14 Nov 94 11:28:19 +1100 Message-Id: <9411140028.AA25252@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Mon, 14 Nov 94 10:31:34 AUS Date: Mon, 14 Nov 94 08:51:50 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: Re: (IPng) management of IP6 routers To: ipng@sunroof.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM re, my query on management and ugrades to SNMP should be on the SNMP list. (from joel). A point of approach. Protocols are the result of (distributed) functions. The protocols do not happen on their own. (Some one must put bits on the wire in the form understood by BOTH ends.) Functions (processing functions) have a data model to represent the data that will be acted on that may stimulate protocol interactions or be updated by protocol interactions. For example. IP6 creates a FUNCTION call flow labels/control that manifests itself as data structures within the nodes and protocol on the wire (Tclass and Flow Id). Its designer should determine that the data structures (and there management) are best served as: 1) Flat attributes, which are ideal for an "interface". OR 2) as a data hierarchy which best serve multiple (and possibly nested) structures attached to a higher level structure. ie a Flow attributes attached to a user's app structure attached to an IP address/ flow process attached to a Hop Cache attached to a router. The point is that the management "protocol" should be determined from the management requirements of the defined process/information/ data model of the function. Not forced on it by the "Management protocol" which may be deficient. For example. The CMIP design was based on its management information which were defined as Objects and structured into Object Trees ( a bit like a directory tree). ie. CMIP has operations SET, GET, ACTION. Managed Objects in their definitions specify their support of these operations. CMIP has a naming structure field. Managed Objects have names.(If an object does not have a name it does not exist!) Its name indicates what node, entity,reference (its place in the tree) of where the object exists. CMIP has a Scope and Filter parameter that enables tree structures of Managed Objects to be access and "searched". eg. Mgt Op = GET User(s)(returned attributes) where Base Object = All Flow tables, Filter on - Flow attribute/Tclass = interactive traffic, Scope = all objects below the base object. Protocol is defined on the function/data it serves. Management protocol is defined on the management function/ data it serves. So the question I think is: is IPng and all its protocols / functions with all its data models best served (from a management perspective) by structuring its data structures into hierarchial trees or having them all as flat attributes. Keep network scale of the new Internet and the richness of the management functions needed in mind here. Big routers may have thousands of managed "objects", so flat datamodels could be undesirable. The answer to this will then put the requirements on possible modifications to SNMP. I think placing this on the SNMP list is to early. The managed datamodels of IP6 functions need to be determined first. And please do not see this as just a CMIP push. Getting the management right for IP6 is a key issue. Integrating its management with carrier technologies will be wonderful. ON a point of order though. Does the writer of the function / protocol (eg. Discovery) also develop the MIB. Or does that go off to the SNMP group? 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 Sun Nov 13 18:57:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13655; Sun, 13 Nov 94 18:57:27 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13649; Sun, 13 Nov 94 18:57:16 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18967; Sun, 13 Nov 94 18:52:57 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA24947; Sun, 13 Nov 94 18:52:21 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id VAA00967 for ipng@sunroof.Eng.Sun.COM; Sun, 13 Nov 1994 21:53:56 -0500 (EST) Date: Sun, 13 Nov 1994 21:53:56 -0500 (EST) From: Scott Bradner Message-Id: <199411140253.VAA00967@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) management of IP6 routers Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > ON a point of order though. Does the writer of the function / protocol (eg. > Discovery) also develop the MIB. Or does that go off to the SNMP group? In general the IETF is now trying to get the MIBs done by the people who are doing the protocols rather than being done by a seperate working group in the network management area. In other words the MIB will be done by the ipngwg working group. 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 Sun Nov 13 20:00:44 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13676; Sun, 13 Nov 94 20:00:44 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13670; Sun, 13 Nov 94 20:00:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20247; Sun, 13 Nov 94 19:56:18 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA28620; Sun, 13 Nov 94 19:55:54 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA12925; Sun, 13 Nov 94 19:52:05 -0800 Received: by xirtlu.zk3.dec.com; id AA29465; Sun, 13 Nov 1994 22:52:04 -0500 Message-Id: <9411140352.AA29465@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: Your message of "Fri, 11 Nov 94 08:00:32 PST." <94Nov11.080039pst.34050@swallow.parc.xerox.com> Date: Sun, 13 Nov 94 22:51:58 -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, > node - a protocol module that implements IPv6. > > router - a node that forwards IPv6 packets not explicitly > addressed to itself. > > host - any node that is not a router. I can live with the above. If a specification then states that a function is performed by a router, then it is also stating that the function should not be performed by the host. But if the specification mean't both host and router then it should be changed to node. If I disagree with the author or IPng mail responder using the above definitions will make the continued discourse clear. That would be very cool. I do agree with you that there are more important topics to discuss. But, it is critical to state what functions cannot be performed on a host or router. That is as important as anything we are working on for IPng IMHO, because it defines potential IPng product markets too. /jim /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 Nov 13 20:03:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13688; Sun, 13 Nov 94 20:03:25 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13682; Sun, 13 Nov 94 20:03:18 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA20324; Sun, 13 Nov 94 19:59:00 PST Received: from cps212.cps.cmich.edu by Sun.COM (sun-barr.Sun.COM) id AA28810; Sun, 13 Nov 94 19:58:35 PST Received: (from wilson@localhost) by cps212.cps.cmich.edu (8.6.9/8.6.9) id WAA09087 for ipng@sunroof.Eng.Sun.COM; Sun, 13 Nov 1994 22:58:32 -0500 From: Brad Wilson Message-Id: <199411140358.WAA09087@cps212.cps.cmich.edu> Subject: Re: (IPng) IPng Implementors Meeting Minutes To: ipng@sunroof.Eng.Sun.COM Date: Sun, 13 Nov 1994 22:58:31 -0500 (EST) In-Reply-To: from "Alan Cox" at Nov 10, 94 10:17:39 am X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2057 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> All implementations will need this in the real world anyway - DNS isn't >> reliable enough or secure enough for some applications (even with security >> a remote DNS could be subverted by physical access). Completely agreed. >> I really wish we could pick something like IKMP and say 'use me' - but >> it just can't be done yet. We in pppext went through the same thing with compression protocols. We came to the conclusion that a choice could nnot be mandated, even one that is free of charge because it may be feasable to implement in all situations. IPv6 should require an explicit knowledge of the impact of security (ie, tossing packets with unknown security w/ errors), but cannot realistically mandate a protocol. >> For the free IP stack world if it involves a patent it either means >> a) It won't get implemented in free stacks - or As an implementor of a free stack, I would be pretty upset if the IETF "forced" me to purchase a patent. It won't happen. It's great to level the playing field, but remember that some people won't even want to play. >> So anything requiring a patent can be considered in specification terms >> as OPTIONAL, whatever the spec says it really is classed as. I would go even further to say that unless a general consensus is reached about the feasibility og requiring something, that it be optional. But that is how the IETF always works, so I'll presume that for now... ;-) >> How about sending a suitable protocol violation error back and ignoring the >> frame. Nobody has written much IPv6 stuff yet so being nasty now will stop >> anyone getting it wrong undetected later.. One would quote the "be liberal in what you accept" clause here... there *will* be implementations that will do it wrong, and your customer isn't going to care if you're following the rules; all they know if XYZ stack and FooBar(TM) stack work okay together. -- Brad Wilson Crucial Software Share and Enjoy! msg++; smiley++; Internet: wilson@cps201.cps.cmich.edu Speaking for myself and myself alone ------------------------------------------------------------------------------ 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 Nov 13 21:15:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13709; Sun, 13 Nov 94 21:15:23 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13703; Sun, 13 Nov 94 21:15:16 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22126; Sun, 13 Nov 94 21:10:57 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03169; Sun, 13 Nov 94 21:10:33 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA14740; Sun, 13 Nov 94 21:05:49 -0800 Received: by xirtlu.zk3.dec.com; id AA00564; Mon, 14 Nov 1994 00:05:48 -0500 Message-Id: <9411140505.AA00564@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Re: Terminology In-Reply-To: Your message of "Fri, 11 Nov 94 19:15:08 PST." <94Nov11.191512pst.34050@swallow.parc.xerox.com> Date: Mon, 14 Nov 94 00:05:42 -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, >Exactly right. Of course, you won't be sending a Router Solicitation >(since you don't know that the thing you are soliciting is a router) -- >it'll be a General Solicitation. So is this an ALL-NODES-MULTICAST solicitation? /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 Nov 13 22:11:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13725; Sun, 13 Nov 94 22:11:10 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13719; Sun, 13 Nov 94 22:11:03 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23088; Sun, 13 Nov 94 22:06:44 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05771; Sun, 13 Nov 94 22:06:19 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA16313; Sun, 13 Nov 94 22:02:27 -0800 Received: by xirtlu.zk3.dec.com; id AA01049; Mon, 14 Nov 1994 01:02:10 -0500 Message-Id: <9411140602.AA01049@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) Implementor Minutes - Thanks Bob Hinden In-Reply-To: Your message of "Sat, 12 Nov 94 03:07:23 GMT." <3435.bill.simpson@um.cc.umich.edu> Date: Mon, 14 Nov 94 01:02:04 -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 >> From: bound@zk3.dec.com >> I am working on rooms for us Sunday Dec 3 1-6 p.m. and Fri Dec 9 9-Noon >> at the Fairmont Hotel for implementors meeting. Waiting to hear back >> from Megan. >> >Wait a minute! We agreed on a Friday meeting at Boston. I've already >bought my (non-refundable) plane tickets, and am not arriving until >10:40 pm Sunday, and staying through the Friday. One day worked just >fine in Toronto. I am pretty sure I said Sunday too. But I did get comments most were going home Friday after noon like the last one. That was a 1/2 day in Toronto too. I did not think of this and only said I would prepare the logistics for the chairs, I "think" those suggesting it (chairs, ADs, and implementors) felt we needed the additional time (like a full court press in basket ball by the defense) at this point for IPv6. Scott answered your other question. /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 Nov 14 00:04:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13791; Mon, 14 Nov 94 00:04:09 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13785; Mon, 14 Nov 94 00:04:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25511; Sun, 13 Nov 94 23:59:43 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA12687; Sun, 13 Nov 94 23:59:13 PST Received: from anubis (anubis.network.com) by nsco.network.com (4.1/1.34) id AA21492; Mon, 14 Nov 94 02:13:28 CST Received: from eros.network.com by anubis (4.1/SMI-4.1) id AA26830; Mon, 14 Nov 94 01:58:53 CST Date: Mon, 14 Nov 94 01:58:53 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411140758.AA26830@anubis> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Neighbor Discovery: routers and ALL-HOST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [My original message:] > The first situation to consider is the role as host that the router > has: If the router is purely a router, its "host" function is > only there for network management. In that case the > management station shouldn't need to reach to routers > with an "all-host" multicast and the router MUST NOT be > in the all-host group. [mr Martillo reply:] It depends on what you mean by network management. I often consider putting an SNMP network manager in the Constellation series bridge routers. It already has built into it a forms menu interface which would be perfect for managing Constellation series bridge routers ..... [My reply:] Why are suddenly product names of ones own company needed in a discussion about protocol standards? ...... and it would not be too hard to add functionality to manage Cisco or Bay networks routers. For minimal cost, customers would get a high-performance bridge router + switch and an SNMP manager, but obviously in this case the router MUST be in the all- host group ..... [My reply:] Why the word "obviously"? What IPv6 specification did you find that specifies that an SNMP management station should send to the layer three multicasts address ALL-HOSTs? .... even though the whole purpose of the router functionality were network management. [My original message:] > The second situation is a piece of hardware being both a server and > a router. In such a situation this hardware will run two > independent code images, one for the server function and one for > the router function. One can think of several ways out of it: [mr Martillo reply:] The piece of hardware could also be both a client and a router too. I can think of lots of reasons to intimately link telnet, rlogin, ftp, X, NFS client functionality intimately with the router functionality. [My reply:] The ALL-HOST-multicast is a layer three multicast, why should one need to RECEIVE a layer three multicast address to act as telnet, rlogin, ftp, X or NFS client? [My original message:] > (a) The IP driver must be intelligent enough to hide the all-host > multicasts for the router code and to hide the all-router > multicasts for the server code. Such would mean we need to > start a discussion to find all potnetial problems and might > highly complicate the specifications for IPv6 [mr Martillo reply:] This exercise would represent design and not protocol specification. [My reply:] It should not be part of the Neighbor Discovery specs, that's true, but if the combination of server/router is not dealed with in the some spec, we can expect multiple implemementations from which at least 50% will cause problems with some new protocol that might be needed three years from now. The same comment applies to ------------------------------------------------------------------------------ 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 Nov 14 00:04:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13803; Mon, 14 Nov 94 00:04:45 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13797; Mon, 14 Nov 94 00:04:38 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25531; Mon, 14 Nov 94 00:00:19 PST Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA12728; Sun, 13 Nov 94 23:59:48 PST Received: from anubis (anubis.network.com) by nsco.network.com (4.1/1.34) id AA21495; Mon, 14 Nov 94 02:14:04 CST Received: from eros.network.com by anubis (4.1/SMI-4.1) id AA26833; Mon, 14 Nov 94 01:59:29 CST Date: Mon, 14 Nov 94 01:59:29 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9411140759.AA26833@anubis> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 Neighbor Discovery: routers and ALL-HOST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Subject: Routers in the ALL-HOST multicast? Let's first do a strange exercise: Let's assume the designers of IPv6 decided to give a name to all non- routers: "iets". We would have had only two questions: - Why give a second name "iets", besides the existing name "non-router"? - Why did they choose that name? No one would have had the feeling that he 'knows' that a router is also an iets, or that a router also has 'iets'-functionality. Also, these IPv6 designers specified three multicasts: All-nodes All-routers All-iets We would agree that All-nodes makes sense, we might want to talk to everyone, we would agree with All-routers, it makes sense to talk to all routers. We might wonder what the hell should be send to all- iets. Even if we can't think of anything we would NEVER have the feeling that a router should also receive the All-iets multicasts: A iets is per definition a non-router, so things send to iets-es are not for routers. A very valid question would still be: Why is it defined??? What is the use of it??? Now let's go to the reality of IPv6 specifications: All nodes with no router functionality are PER DEFINITION "host"-s. Remember that while reading a formal definition one should forget the common sense meaning of the word; this is NOT new to IPv6 protocol, in every protocol in this industry, as well as in each science on this planet, words used in (slightly or completely) other meanings as common sense learns us. In this specific case a IPv6 "host" is defined as "non-router", the only valid questions are: - Why this name? and - What is the benefit? Our feeling that a router also has some host-functionality is mixing our common sense idea of what a host is with a new formal definition. Such a mixing makes us believing that since a router can be a partner in a telnet session, it is for that a kind of host, so a router is also a host. THAT IS SIMPLY INCORRECT, nowhere in the IPv6 specs is said that something that accepts telnet is a "host" ( "host" as defined in IPv6). The same holds for all other protocols. We MUST realize that the word "host" is given a new meaning in IPv6. There are three multicasts defined: All-nodes All-routers All-hosts If we want to send something to all routers and all non-routers, it will be send to All-nodes. If we want to send something to all routers, it will be send to All-routers. The problem comes with the All-host multicast. Here we again mix up our feeling that we see as hosts and the IPv6 definition of "host"-s. Let us want to manage the network: if we want to contact all units on the network, one might in common language say: we send it to all hosts, but in IPv6 we say: we send it to all NODE-s. The multicast All-hosts is only to be used for packets that should not go to routers. The valid question (as asked by Joel Halpern a few days ago) is: Is there any need to have this All-host-multicast, for what do we want to send to it? As I said in earlier messages: If one claims that some routers should be in the All-host-multicast, one should be able to point at a defined packet in one of the IPv6 drafts, that (a) is send to the All-host-multicast and (b) a unit that is combination of router and something else needs this packet. Fred Rabouw ------------------------------------------------------------------------------ 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 Nov 14 02:23:45 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13949; Mon, 14 Nov 94 02:23:45 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13943; Mon, 14 Nov 94 02:23:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28574; Mon, 14 Nov 94 02:19:18 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA24964; Mon, 14 Nov 94 02:18:39 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) node/host/router To: ipng@sunroof.Eng.Sun.COM Date: Mon, 14 Nov 1994 10:18:46 +0100 (GMT) In-Reply-To: <9411140054.AA25280@cms.datacraft.com.au> from "Alan.Lloyd@datacraft.com.au" at Nov 14, 94 10:38:01 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 450 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > my view, > node, host and router are ok by me. It seems quite reasonable. It will need to be in big letters as a definition at the top of the final documents and some people won't read it first, but at the least it will be good for telling who has actually read the spec and who commented first ;) A glossary of IPng terminology and abbreviations is probably also an appropriate item for an RFC so everyone knows what ToS and stuff mean. 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 Mon Nov 14 05:06:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14050; Mon, 14 Nov 94 05:06:18 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14044; Mon, 14 Nov 94 05:06:04 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01306; Mon, 14 Nov 94 05:01:46 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA08764; Mon, 14 Nov 94 05:01:20 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id IAA01512 for ipng@sunroof.Eng.Sun.COM; Mon, 14 Nov 1994 08:02:55 -0500 (EST) Date: Mon, 14 Nov 1994 08:02:55 -0500 (EST) From: Scott Bradner Message-Id: <199411141302.IAA01512@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Implementor Minutes - Thanks Bob Hinden Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I am pretty sure I said Sunday too. yes, Sunday was part of the original suggestion during the implementers meeting. 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 Nov 14 06:32:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14145; Mon, 14 Nov 94 06:32:42 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14139; Mon, 14 Nov 94 06:32:35 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03897; Mon, 14 Nov 94 06:28:17 PST Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA16848; Mon, 14 Nov 94 06:27:51 PST Message-Id: <9411141427.AA16848@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1001; Mon, 14 Nov 94 09:27:58 EST Date: Mon, 14 Nov 94 09:26:14 EST From: yakov@watson.ibm.com To: deering@parc.xerox.com Cc: ipng@sunroof.Eng.Sun.COM, estrin@isi.edu Subject: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Fri, 11 Nov 1994 10:31:34 PST Steve, >I consider this conversation to be an attempt to identify the >practical implications of each approach. I agreed entirely. In essence, you're basically advocating full blown tunneling, while we're proposing tunneling scheme which retains minimal information and carries it in an internal extension. >Thus, for your example, I would have the enterprise's policy asserting >router emit a packet of the following form: > >encapsulating IPv6 header >routing header >original IPv6 header >rest of original packet > >I think if you count up the bytes in my scheme and in the ERP scheme, that >you will find that my scheme takes either exactly the same number of bytes >or at most 8 more bytes than your scheme. That is correct for the case where there is only one ERP header AND there is no Hop-by-Hop Options header. First consider the case where there is more than one ERP header (after all, policies may need to be asserted more than once along a path). In this case the following shows the differences: Your proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header routing header 1 routing header 1 encapsulating IPv6 header routing header 2 routing header 2 ....... ..... original IPv6 header original IPv6 header rest of original packet rest of original packet Thus, in presence of more than one ERP header your scheme will take 8 + 16 * (N-1) octets more than the ERP scheme (where N is the number of ERP headers). For example, with just two ERO headers your scheme will take 24 more octets than the ERP scheme. Next consider the case where there is a Hop-by-Hop Options header present. In this case the following shows the differences: Your proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header original Hop-by-hop header original Hop-by-hop header routing header routing header original IPv6 header original IPv6 header original Hop-by-hop header rest of original packet rest of original packet Observe that in this case the Hop-by-hop Options header is present *twice* with your proposal, and only *once* with the ERP scheme. Again, your scheme incurs more octets overhead than the ERP scheme. [ The case where there is more than one ERP header and there is a Hop-by-hop header is left "as an exercise to the reader"... :-) ] >... as a designer of the extension header mechanism of IPv6, and >someone who has experience with both forms of header munging (in MBone >tunnels), it is my judgement that this is, architecturally, the "right" >way to do in-transit explicit route assertion... What were the specific factors that influenced your judgment ? Yakov. P.S. Interestingly enough, the discussion about full blown tunneling vs a tunneling scheme which retains minimal information was argued before in the Mobile IP WG. Current Mobile-IP I-D supports both schemes, but restricts the latter one (tunneling which retains minimal information) to the case of datagrams which are *not fragmented* prior to encapsulation. ------------------------------------------------------------------------------ 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 Nov 14 06:42:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14171; Mon, 14 Nov 94 06:42:09 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14165; Mon, 14 Nov 94 06:42:03 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04298; Mon, 14 Nov 94 06:37:44 PST Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA18026; Mon, 14 Nov 94 06:37:17 PST Message-Id: <9411141437.AA18026@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1211; Mon, 14 Nov 94 09:37:24 EST Date: Mon, 14 Nov 94 09:35:48 EST From: yakov@watson.ibm.com To: Bob.Hinden@Eng, ipng@sunroof.Eng.Sun.COM Subject: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Fri, 11 Nov 1994 09:51:47 -0800 Bob, >I think you took the argument a bit too far. I think there is a middle >group here. The way I think this would be used would result in only >one encapsulation header and that header would incur a routing header. Not exactly (see below). > >The source host would send it's datagram without any routing header. >the source host would not have any knowledge about any routing policies. >When the datagram reaches the site border router (which did know about >the sites routing policies), that border router would encapsulated the >datagram in another header which includes a routing header. This assumes that routing policies need to be asserted only *once* -- by "the site border router". How would your scheme work when routing policies need to be asserted more than once along a path ? How many encapsulations would your scheme require in that case ? Yakov. ------------------------------------------------------------------------------ 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 Nov 14 06:45:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14183; Mon, 14 Nov 94 06:45:30 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14177; Mon, 14 Nov 94 06:45:23 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04426; Mon, 14 Nov 94 06:41:05 PST Received: from sadis01.kelly.af.mil by Sun.COM (sun-barr.Sun.COM) id AA18462; Mon, 14 Nov 94 06:40:38 PST Received: by sadis01.kelly.af.mil (5.65b/1.0.1-rct) id AA19706; Mon, 14 Nov 94 08:41:18 -0600 Message-Id: <9411141441.AA19706@sadis01.kelly.af.mil> Date: Mon, 14 Nov 94 08:41:18 -0600 From: rrietz@sadis01.kelly.af.mil (RONALD E. RIETZ - FMPS) Subject: Re: (IPng) node/host/router To: ipng@sunroof.Eng.Sun.COM X-Orig-Date: Mon, 14 Nov 1994 10:18:46 +0100 (GMT) X-Orig-From: iialan@iifeak.swan.ac.uk (Alan Cox) X-Orig-Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > A glossary of IPng terminology and abbreviations is probably also an appropriate > item for an RFC so everyone knows what ToS and stuff mean. > > Alan > I have been lurking until now on this list. This is a very good suggestion. A central, unified 'data-base' of definitions is critical to the success of IPng. A large part of the traffic on this list has been the defining of terms. Ron _ Ronald Rietz +1 (210) 925-4747(V) (DSN)945-4747 _| ~-. SA-ALC/FMPS +1 (210) 925-7725(F) \, *_} 505 Perrin Rd. rrietz@sadis01.kelly.af.mil \( Kelly AFB TX 78241-6435 ------------------------------------------------------------------------------ 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 Nov 14 07:16:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14244; Mon, 14 Nov 94 07:16:19 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14238; Mon, 14 Nov 94 07:16:08 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05857; Mon, 14 Nov 94 07:11:49 PST Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA22560; Mon, 14 Nov 94 07:11:23 PST Subject: (IPng) More multicast questions To: IPng Mailing list Date: Mon, 14 Nov 1994 10:11:30 -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: 814 Message-Id: <9411141511.aa27325@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A few questions about IPv6 multicast: 1. When searching for multicast groups I'm in, should I ignore the scoping bits? For example, I'm a network time server, and I receive a global-scope network time multicast packet. I should process this packet accordingly, right? Another way to phrase this is: When I join a multicast group (either transient or permanent), do I join it on ALL scopes? 2. What's the deal with intra-node scope? Isn't this just a glorified loopback mechanism? Or do I loopback a copy for each possible interface? If my "node" is actually a whole subnet (some bizarre multi- processor idea comes to mind), does this mean I send to each sub-node inside my node? I'm no expert on multicast, so I'll take any help I can get here. Thanks, Dan McD. ------------------------------------------------------------------------------ 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 Nov 14 07:19:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14264; Mon, 14 Nov 94 07:19:46 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14258; Mon, 14 Nov 94 07:19:35 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06009; Mon, 14 Nov 94 07:15:16 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA22996; Mon, 14 Nov 94 07:14:42 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id KAA01811 for ipng@sunroof.Eng.Sun.COM; Mon, 14 Nov 1994 10:15:56 -0500 (EST) Date: Mon, 14 Nov 1994 10:15:56 -0500 (EST) From: Scott Bradner Message-Id: <199411141515.KAA01811@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPv6 address representation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It was just pointed out to me that currently URLs treat colons a bit special (and I can think of a number of other places that this happens, colon is a common field seperator). This is going to cause confusion with the IPv6 address represntation which is colon rich. Any suggestions about how to deal with this? requite quotes around IPv6 addresses in such cases? ... 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 Nov 14 07:25:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14288; Mon, 14 Nov 94 07:25:06 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14282; Mon, 14 Nov 94 07:24:55 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06345; Mon, 14 Nov 94 07:20:37 PST Received: from nero.dcrc.com ([131.226.3.20]) by Sun.COM (sun-barr.Sun.COM) id AA24014; Mon, 14 Nov 94 07:19:52 PST Received: by nero.dcrc.com (4.1/1.34) id AA25685; Mon, 14 Nov 94 10:16:05 EST Date: Mon, 14 Nov 94 10:16:05 EST From: mad@nero.dcrc.com (Mike Davis) Message-Id: <9411141516.AA25685@nero.dcrc.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9411140054.AA25280@cms.datacraft.com.au> (Alan.Lloyd@datacraft.com.au) Subject: Re: re: (IPng) node/host/router Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 14 Nov 94 10:38:01 AUS From: Alan.Lloyd@datacraft.com.au my view, node, host and router are ok by me. Me too, as long as I know what parts of IPv6 my *router* has to implement to interwork with other vendor's equipment. Host = End System. something that does not forward IP packets and provides a IP Service Interface to a higher layer function. Router = Intermediate System. somthing that does forward IP packets ** . Node = either of the above. You definition of a Host is not the same as that of IPv6 insofar that IPv6 doesn't care what about "higher layer function[s.]" ** The exception in a router is that it provides a IP6 service interface to its management entity (SNMP/Telnet). ie. its application is only there to serve the basic needs of the router. Therefore the router because of this function is not considered a "host" Host and Router are Functions. They can be combined in an implementation. According to where the definitions stand now, Host and Router are not functions, they are (exhuastive and mutally exclusive) categories of IPv6 communications devices. While a device can be one or the other through time, it can only be one at a given time. Regards Alan@Oz If I can repeat thoughts written elsewhere, I don't care if we call them node/host/router or foo/bar/baz, as long as I know how to make my baz, er router, talk to other nodes. The reason I made waves in the first place is because I did not know what the IPv6 expected my equipment to do in certain situations, and the terminology applied very slightly different names to given concepts than my experience did. Basically, I've sorted through that, but I still am not sure of certain functions of certain nodes, a topic which I will first try to resolve on my own, and then make more waves if necessary. Thanks -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 Mon Nov 14 07:43:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14312; Mon, 14 Nov 94 07:43:59 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14306; Mon, 14 Nov 94 07:43:52 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07464; Mon, 14 Nov 94 07:39:33 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA27183; Mon, 14 Nov 94 07:39:02 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPv6 address representation To: ipng@sunroof.Eng.Sun.COM Date: Mon, 14 Nov 1994 15:39:11 +0100 (GMT) In-Reply-To: <199411141515.KAA01811@newdev.harvard.edu> from "Scott Bradner" at Nov 14, 94 10:15:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 622 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > It was just pointed out to me that currently URLs treat colons > a bit special (and I can think of a number of other places that > this happens, colon is a common field seperator). This is > going to cause confusion with the IPv6 address represntation which > is colon rich. Well a dotted IPv6 representation will have an awful lot of advantages. It wont break bootpd, all the stuff that 'knows' : is ethernet . is ip etc. Maybe ':' wasn't a brilliant idea after all. At least if its fixed now it doesn't cause future problems. Personally since '.' is the IP special already I'd knock the : over and use .. 8) 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 Mon Nov 14 07:59:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14328; Mon, 14 Nov 94 07:59:05 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14322; Mon, 14 Nov 94 07:58:58 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08499; Mon, 14 Nov 94 07:54:39 PST Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA00220; Mon, 14 Nov 94 07:54:11 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14223; Mon, 14 Nov 1994 16:54:07 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA00566; Mon, 14 Nov 1994 16:54:04 +0100 Message-Id: <9411141554.AA00566@dxcoms.cern.ch> Subject: Re: (IPng) IPv6 address representation To: ipng@sunroof.Eng.Sun.COM Date: Mon, 14 Nov 1994 16:54:04 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199411141515.KAA01811@newdev.harvard.edu> from "Scott Bradner" at Nov 14, 94 10:15:56 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: 1312 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott, http://128.141.13.198:8000/ becomes http://::128.141.13.198:8000/ which isn't actually broken However, you can construct pure IPv6 addresses for which the : is ambiguous with the last word of an address. http://1080::800:200C:417A:8000/ is the 8000 a port # or an address word? The simplest fix is an alternative URL syntax using something other than : before the port #. For example, in the case of a pure IPv6 address (where the only separators are colons), use a period before the port #. http://1080::800:200C:417A.8000/ Brian >--------- Text sent by Scott Bradner follows: > > > It was just pointed out to me that currently URLs treat colons > a bit special (and I can think of a number of other places that > this happens, colon is a common field seperator). This is > going to cause confusion with the IPv6 address represntation which > is colon rich. > > Any suggestions about how to deal with this? requite quotes around > IPv6 addresses in such cases? ... > > 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 > ------------------------------------------------------------------------------ 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 Nov 14 08:14:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14391; Mon, 14 Nov 94 08:14:03 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14385; Mon, 14 Nov 94 08:13:56 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10015; Mon, 14 Nov 94 08:09:37 PST Received: from ceres.fokus.gmd.de by Sun.COM (sun-barr.Sun.COM) id AA03124; Mon, 14 Nov 94 08:08:57 PST Message-Id: <9411141608.AA03124@Sun.COM> Received: from fokus.gmd.de by ceres.fokus.gmd.de id <00461-0@ceres.fokus.gmd.de>; Mon, 14 Nov 1994 17:11:46 +0100 Subject: Re: (IPng) IPv6 address representation To: ipng@sunroof.Eng.Sun.COM Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 14 Nov 1994 17:11:46 +0100 From: Henning Schulzrinne Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > It was just pointed out to me that currently URLs treat colons > > a bit special (and I can think of a number of other places that > > this happens, colon is a common field seperator). This is > > going to cause confusion with the IPv6 address represntation which > > is colon rich. > > Well a dotted IPv6 representation will have an awful lot of advantages. It > wont break bootpd, all the stuff that 'knows' : is ethernet . is ip etc. Maybe > ':' wasn't a brilliant idea after all. At least if its fixed now it doesn't > cause future problems. > > Personally since '.' is the IP special already I'd knock the : over and use .. > 8) > Given that IP6 addresses are noticeably longer than IP4 addresses and the latter always appear as 'dotted quads', why can't dots be used as before? Having to quote : in URLs would seem extremely cumbersome, although numeric addresses probably shouldn't appear in a URL in the first place. -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14423; Mon, 14 Nov 94 08:25:55 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14417; Mon, 14 Nov 94 08:25:47 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10860; Mon, 14 Nov 94 08:21:29 PST Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA04911; Mon, 14 Nov 94 08:20:56 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA15517; Mon, 14 Nov 94 11:09:19 EST Received: from cabernet.wellfleet by wellfleet (4.1/SMI-4.1) id AA08818; Mon, 14 Nov 94 11:09:23 EST Date: Mon, 14 Nov 94 11:09:23 EST From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9411141609.AA08818@wellfleet> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Implementor Minutes - Thanks Bob Hinden Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > >> From: bound@zk3.dec.com > >> I am working on rooms for us Sunday Dec 3 1-6 p.m. and Fri Dec 9 9-Noon > >> at the Fairmont Hotel for implementors meeting. Waiting to hear back > >> from Megan. > >> > > >Wait a minute! We agreed on a Friday meeting at Boston. I've already > >bought my (non-refundable) plane tickets, and am not arriving until > >10:40 pm Sunday, and staying through the Friday. One day worked just > >fine in Toronto. > > I am pretty sure I said Sunday too. But I did get comments most were > going home Friday after noon like the last one. That was a 1/2 day in > Toronto too. I did not think of this and only said I would prepare > the logistics for the chairs, I "think" those suggesting it (chairs, > ADs, and implementors) felt we needed the additional time (like a full > court press in basket ball by the defense) at this point for IPv6. I recall our agreeing to Sunday and Friday at the interim implementor's meeting. My notes say that we agreed to meet Sunday afternoon and Friday morning. Sunday afternoon is good for East coast folks, since an early flight out Sunday will arrive just after noon. Ross ------------------------------------------------------------------------------ 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 Nov 14 08:43:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14465; Mon, 14 Nov 94 08:43:18 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14459; Mon, 14 Nov 94 08:43:06 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA16643; Mon, 14 Nov 1994 08:38:23 -0800 Date: Mon, 14 Nov 1994 08:38:23 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411141638.IAA16643@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Subject: Re: (IPng) node/host/router Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan Cox writes: > > my view, > > node, host and router are ok by me. > > It seems quite reasonable. It will need to be in big letters as a definition > at the top of the final documents and some people won't read it first, but > at the least it will be good for telling who has actually read the spec and > who commented first ;) Section 2 of the IPv6 specification is titled Terminology where these and other terms are defined. > A glossary of IPng terminology and abbreviations is probably also an > appropriate item for an RFC so everyone knows what ToS and stuff mean. Yes, I agree. But after we get the first set of documents into the standards process. 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 Nov 14 08:45:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14488; Mon, 14 Nov 94 08:45:28 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14482; Mon, 14 Nov 94 08:45:22 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12678; Mon, 14 Nov 94 08:41:03 PST Received: from postoffice3.mail.cornell.edu by Sun.COM (sun-barr.Sun.COM) id AA08662; Mon, 14 Nov 94 08:40:22 PST Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id LAA04070 for ; Mon, 14 Nov 1994 11:40:17 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Nov 1994 11:40:21 -0500 To: ipng@sunroof.Eng.Sun.COM From: Scott Brim Subject: Re: (IPng) IPv6 address representation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 10:54 AM 11/14/94, Brian Carpenter CERN-CN wrote: >The simplest fix is an alternative URL syntax using something other >than : before the port #. It'll be a lot easier to change IPv6 syntax than to change URL syntax. Go ahead, find all the URLs in the world with port numbers in them :-) ...Scott (the other 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 Nov 14 08:49:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14500; Mon, 14 Nov 94 08:49:41 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14494; Mon, 14 Nov 94 08:49:31 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id IAA16844; Mon, 14 Nov 1994 08:44:50 -0800 Date: Mon, 14 Nov 1994 08:44:50 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411141644.IAA16844@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199411141302.IAA01512@newdev.harvard.edu> Subject: Re: (IPng) Implementor Minutes - Thanks Bob Hinden Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott Bradner writes: > > I am pretty sure I said Sunday too. > > yes, Sunday was part of the original suggestion during the implementers > meeting. The minutes from the implementors meeting show: Next Meetings ------------- There will be two IPng implementors meetings at the December IETF. The first will be on Sunday December 4, 1994 at 1PM. The second will be December 9 at 9AM. 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 Nov 14 10:16:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14602; Mon, 14 Nov 94 10:16:49 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14596; Mon, 14 Nov 94 10:16:43 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA28264; Mon, 14 Nov 94 10:12:23 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA29096; Mon, 14 Nov 94 10:11:54 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06561; Tue, 15 Nov 1994 04:56:46 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) node router host Date: Tue, 15 Nov 1994 04:56:32 +1100 Message-Id: <13572.784835792@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have no problem with "node" as the label for any entity that speaks IPv6, nor with "router" for a node that forwards packets (though a node that forwards on two interfaces, and not on a third is certainly a case that needs careful consideration). However, while the label "host" for something that is a node and not a router doesn't bother me, the concept of defining this by exclusion does. Its hard to imagine many cases where this will be useful - almost every time you attempt to use a concept which is defined only as not being something else you tend to run into trouble, you find it covers a bit more than what you really wanted, or misses something that should be included. By all means keep the definition, but take care to examine every place its used, if there actually are any, and make sure that it is expressing exactly what is intended, and not just what seems right at first glance. 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 Mon Nov 14 13:02:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14992; Mon, 14 Nov 94 13:02:53 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14986; Mon, 14 Nov 94 13:02:46 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25218; Mon, 14 Nov 94 12:58:22 PST Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29325; Mon, 14 Nov 94 12:54:49 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA15778; Mon, 14 Nov 94 12:23:19 -0800 Received: by xirtlu.zk3.dec.com; id AA25705; Mon, 14 Nov 1994 15:23:10 -0500 Message-Id: <9411142023.AA25705@xirtlu.zk3.dec.com> To: addrconf@cisco.com Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com Subject: Re: (IPng) embedded IEEE Addresses In-Reply-To: Your message of "Sun, 13 Nov 94 07:17:55 +1100." <13255.784671475@munnari.OZ.AU> Date: Mon, 14 Nov 94 15:23:04 -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 >Date: Sun, 13 Nov 1994 07:17:55 +1100 >Message-Id: <13255.784671475@munnari.OZ.AU> >From: Robert Elz Date: Sat, 12 Nov 94 03:12:14 GMT From: "William Allen Simpson" Message-ID: <3436.bill.simpson@um.cc.umich.edu> There is also a fourth. The HOST makes the address. >This one I oppose, its the one I think should never happen. Well I don't think MAC addresses are the only solution either. So I believe we need some scheme developed how hosts can make the address, when required. We MUST have this in order to communicate with the auto-configuration service, >This presupposes that we're using IPv6 to communicate with >autoconfiguration, which I would prefer not to do, and that >a valid address of some kind is needed even in that eventuality, >which doesn't really have to happen. I can't parse the above! What do you mean "...using IPv6 to ..." of course we are: please explain. > and to operate in the "dentist office" environment. There are many other environments where a router may not exist. >This one is the hard case here .. my model would actually be >that hosts still don't assign their own addresses, but rather >they look for an addrconf server, always, if no addrconf server >is found, then a host simply starts a simple, stateless, one >and runs it, answering queries initially from itself, and then How would it determine the structure of addresses to provide? >from other hosts with "local use" addresses with a very short How are these hosts determining their local use address? >lease time (of the order of a few minutes probably) until another >addrconf server is observed running, at which point it simply >turns off its server. This basically means that the first >host on a cable (or partitioned piece of cable) becomes the >addrconf server for that cable until something more reliable >is located. When the clients with local use addresses come to >renew them after their short lease expires and a real server is >running, that server will invalidate the local use address. >If several hosts all decide to become addrconf servers at the >same instant, that's OK, the algorithm that they all use is >identical, they will notice each other and turn off anyway. >This will only happen as a race condition, any other addrconf >server that starts later will be a configured one - except where >two segments without configured servers join. In that case >all previous temporary host based servers will see the others >and turn off. The first host that needs to renew its lease will >fail to find any addrconf server at all, and start its local >simple one. Too many heuristics for host processing. This is much to complex. >The advantage of this is that if an addrconf server exists >on a cable, hosts never construct addresses of their own, and What? You state the use of local use addresses above. I am trying to follow you but you go back and forth or I need more in between the thought flows. >if net management doesn't want some particular host to operate >on this cable, it will simply be denied an address, and won't >be able to communicate, even locally. This is an overide and I think its a good idea, just not in the manner you suggest. > purposes, I'd prefer to use specific link level packets for > this (UDP if it has to be IPv6 based) Blech! And I certainly don't. >I had gathered that. I believe I understand the reasons that >people don't like link specific packets, though I don't agree >with them. I have absolutely no comprehension why anyone >would want to use ICMP over UDP for a query/request type protocol >(as distinct from sending error/diagnostic type messages). >I'm still looking for someone to attempt to explain that one. Its engineering trade-offs. Autoconfiguration will use the processes and syntax of system discovery packets and the semantics to determine the structure of its address (prefix size, change in prefix, etc.). This is solicitation and advertisement (unicast | multicast) and is at the ICMP layer. The reason this has been moved to the ICMP layer is it permits extensibility for implementors to develop or change formats for system discovery. All services suggested in discovery have been removed in the hope that service location will work using UDP. Processing these using ICMP instead of UDP is an order of magnitude faster than moving this functionality to UDP and then into an application layer, for a set of processing functions per system discovery which will be consistent on the network. So we already have a design, some code, and a model to use ICMP for system discovery in the IPng base group. For autoconfiguration at present there is an address request packet, address assignment packet, and several extension formats. These can be implemented efficiently using the same model as system discovery in the case where the host (autoconfig is only configuring addresses for hosts) first comes onto the network. I would like to see if its possible to not even bother the transport layer until the entire host is configured. So what we have done is: 1. Accept and absorb the engineering trade-offs for ICMP vs UDP for system discovery, but believe its better than where the ARP or other link layer code sits presently on a BSD implementation for argument sake. 2. For Autoconfiguration absorb the above previously accepted engineering trade-offs, because the performance gain is possible for autoconfiguration processing too. Now once the host is configured and changes need to take place or extended functions, such as registration of DNS parts from the client, then I believe there could be a reason to move this to UDP. This gets into what is DHCPng in IPv6 and what is stateful vs stateless. In addition should we want to renumber (though I doubt this will ever work as people are hoping, for a long time) that too could be done with UDP. But for those functions where the network operation is consistent on the link for sometime, and there are potential race conditions, then processing those packets on the host at the ICMP layer is prudent engineering design IMHO. >ps: this topic has diverged well off ipng list business and >into addrconf, I am sending this to both lists, with the >intent that it be moved to addrconf. I have added a Reply-To >directing replies to addrconf@cisco.com however I believe that >that revolting software that runs the ipng list will destroy >that and direct replies back to ipng. If you reply to this >please override that, and reply only to addrconf@cisco.com Well I have to complain and not agree with you this is just an addrconf issue. Its also a base IPng issue because we have the model and engineering trade-offs in IPng. If addrconf or other WGs break any of the base IPng models then that is a discussion for IPng base group. So I copied both lists. As much as I did not want to. Some day we will all be able to send focused mail to a particular WG. /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 Nov 14 14:31:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15145; Mon, 14 Nov 94 14:31:57 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15139; Mon, 14 Nov 94 14:31:50 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08109; Mon, 14 Nov 94 14:27:30 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA12623; Mon, 14 Nov 94 14:26:29 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA21824; Mon, 14 Nov 1994 17:25:34 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA22010; Mon, 14 Nov 1994 17:25:32 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA26363; Mon, 14 Nov 1994 17:01:59 -0500 Message-Id: <9411142201.AA26363@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Which m-cast groups to join? In-Reply-To: Your message of "Thu, 10 Nov 94 17:15:04 PST." <94Nov10.171508pst.12173@skylark.parc.xerox.com> Date: Mon, 14 Nov 94 17:01:59 -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: Steve Deering ...... node - a protocol module that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. >From my point of view the terminology node/host/router is more adequate than any other possible choices mentioned. 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 Nov 14 14:33:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15173; Mon, 14 Nov 94 14:33:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15155; Mon, 14 Nov 94 14:33:18 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08427; Mon, 14 Nov 94 14:28:59 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA13018; Mon, 14 Nov 94 14:28:13 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-00.dialip.mich.net [141.211.7.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA23950 for ; Mon, 14 Nov 1994 17:12:36 -0500 Date: Mon, 14 Nov 94 17:07:23 GMT From: "William Allen Simpson" Message-Id: <3453.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Definitions Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I have been lurking until now on this list. This is a very good > suggestion. A central, unified 'data-base' of definitions is critical > to the success of IPng. A large part of the traffic on this list has > been the defining of terms. > We have one, it's called the overview. They are also in the IPv6 header spec. 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 Nov 14 14:33:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15174; Mon, 14 Nov 94 14:33:57 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15161; Mon, 14 Nov 94 14:33:24 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08440; Mon, 14 Nov 94 14:29:05 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB13018; Mon, 14 Nov 94 14:28:35 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-00.dialip.mich.net [141.211.7.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA23959 for ; Mon, 14 Nov 1994 17:12:42 -0500 Date: Mon, 14 Nov 94 17:13:15 GMT From: "William Allen Simpson" Message-Id: <3455.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery Hop Limit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Steve Deering > I suggest that you wait a while to see if anyone identifies any problems > with your idea before declaring it a done deal. > Glad you liked it. Done means it was in the draft I sent to the i-d on Sunday. It will be easy to delete if anybody finds a reason it is unacceptable. 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 Nov 14 14:34:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15178; Mon, 14 Nov 94 14:34:05 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15167; Mon, 14 Nov 94 14:33:29 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08462; Mon, 14 Nov 94 14:29:10 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB13018; Mon, 14 Nov 94 14:28:42 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-00.dialip.mich.net [141.211.7.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA23956 for ; Mon, 14 Nov 1994 17:12:39 -0500 Date: Mon, 14 Nov 94 17:10:17 GMT From: "William Allen Simpson" Message-Id: <3454.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > P.S. Interestingly enough, the discussion about full blown tunneling vs > a tunneling scheme which retains minimal information was argued before > in the Mobile IP WG. Current Mobile-IP I-D supports both schemes, but > restricts the latter one (tunneling which retains minimal information) > to the case of datagrams which are *not fragmented* prior to encapsulation. > You are rather out of date. Actually, the WG decided 8 months ago that the IP in IP would be the default. The in-line "minimal" header is optional, as it can _only_ be used when datagrams are not fragmented. IPv4 fragments on low bandwidth links a lot! 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 Nov 14 14:39:00 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15197; Mon, 14 Nov 94 14:39:00 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15191; Mon, 14 Nov 94 14:38:49 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09403; Mon, 14 Nov 94 14:34:30 PST Received: from by Sun.COM (sun-barr.Sun.COM) id AB13018; Mon, 14 Nov 94 14:28:46 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-00.dialip.mich.net [141.211.7.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA23943 for ; Mon, 14 Nov 1994 17:12:33 -0500 Date: Mon, 14 Nov 94 17:00:45 GMT From: "William Allen Simpson" Message-Id: <3452.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Implementor Minutes - Thanks Bob Hinden Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: rcallon@pobox.wellfleet.com (Ross Callon) > My notes say that we agreed to meet > Sunday afternoon and Friday morning. Sunday afternoon is good > for East coast folks, since an early flight out Sunday will > arrive just after noon. > Well, my notes missed it. Sorry. I won't be there. Don't change anything of importance. (sigh) Besides, an early flight from Detroit only gets there by 2:30pm PST (and I *hate* getting up before 7 am -- or even 10 am). I'd have to fly out Saturday. The direct flights that Northworst used to have to SJ a few years ago don't exist anymore, I'm sorry to say. Must have more flights from Boston. 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 Nov 14 16:36:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15461; Mon, 14 Nov 94 16:36:34 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15455; Mon, 14 Nov 94 16:36:26 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27939; Mon, 14 Nov 94 16:32:06 PST Received: from avalon.mpce.mq.edu.au by Sun.COM (sun-barr.Sun.COM) id AA05581; Mon, 14 Nov 94 16:31:27 PST Message-Id: <9411150031.AA05581@Sun.COM> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA12217; Tue, 15 Nov 94 11:31:12 edt From: Andrew Myles Subject: Re: (IPng) high-speed slicing and dicing of headers..... To: ipng@sunroof.Eng.Sun.COM Date: Tue, 15 Nov 94 11:31:09 EDT In-Reply-To: <3454.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Nov 14, 94 5:10 pm Mailer: Elm [revision: 64.9] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM G'day Bill, Re: tunnelling > You are rather out of date. Actually you are wrong. > Actually, the WG decided 8 months ago that > the IP in IP would be the default. True. > The in-line "minimal" header is optional, True. > as it can _only_ be used when datagrams are not fragmented. Wrong!!!!!!!!!!!! The deal is as follows: The minimal encapsulation can be fragmented, however, the fragments cannot be tunnelled using minimal encapsulation. Your continuing misunderstanding of this point is of great concern. Andrew -- -------------------------------------------------------------------------------- Andrew Myles e-mail: andrewm@mpce.mq.edu.au Electronics Department www: http://www.mpce.mq.edu.au/~andrewm/ Macquarie University 2109 archive: ftp://avalon.mpce.mq.edu.au/dist Sydney, NSW voice: +61 2 8509071 (W), +61 2 8786060 (H) Australia fax: +61 2 8509128 -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Nov 14 17:36:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15534; Mon, 14 Nov 94 17:36:58 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15528; Mon, 14 Nov 94 17:36:51 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA07174; Mon, 14 Nov 94 17:32:32 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA20289; Mon, 14 Nov 94 17:32:04 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA28937; Mon, 14 Nov 1994 20:32:01 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA31833; Mon, 14 Nov 1994 20:31:58 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA26619; Mon, 14 Nov 1994 20:08:25 -0500 Message-Id: <9411150108.AA26619@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Discovery Hop Limit In-Reply-To: Your message of "Sat, 12 Nov 94 18:18:03 GMT." <3443.bill.simpson@um.cc.umich.edu> Date: Mon, 14 Nov 94 20:08:25 -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" Subject: (IPng) Discovery Hop Limit Had another idea to eliminate user configuration. The Hop Limit (IPv4 TTL) is currently 64. It may change someday. That's the recommended default value. I know implementations setting it to 128. Rather than have each user update their system, the routers can advertise the current Hop Limit to use. Currently, systems have default TTL values which users or system managers may decide to change depending on application, transport protocol, or system necessities. >From that perspective, TTL in IPv4 seem to be rather a host specific parameter - application and system manager configurable. Furthemore, each protocol may have its own default values, which I know for a fact that people find useful for TCP, UDP, and ICMP - in fact I would see a protocol & port granularity even more useful. My gut feeling is that the 'hop count' or TTL is not a 'routing information' parameter such as a router's address or MTUs for the routers interfaces. Based on current DHCP efforts, and in absence of more compelling reasons, I would rather leave 'hop limit' (TTL) as it is, as a possible DHCP parameter, like other host networking specific parameters, settable on a per host and per (transport) protocol basis. Thus, it is only a network administrator problem, and fewer places need to be updated. Done Bill.Simpson@um.cc.umich.edu I am not sure your above premises are always or in majority of cases applicable: I do know of people needing higher values than certain systems default TTL values in IPv4. I also know many places where "the routers person" is not "the hosts person" as far as administration is concerned. That's why my feeling is rather DHCP... 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 Mon Nov 14 17:42:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15567; Mon, 14 Nov 94 17:42:59 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15561; Mon, 14 Nov 94 17:42:51 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08014; Mon, 14 Nov 94 17:38:33 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA21728; Mon, 14 Nov 94 17:37:55 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA29124; Mon, 14 Nov 1994 20:37:47 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA32122; Mon, 14 Nov 1994 20:37:45 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA26642; Mon, 14 Nov 1994 20:14:07 -0500 Message-Id: <9411150114.AA26642@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) Discovery Hop Limit In-Reply-To: Your message of "Sun, 13 Nov 94 11:31:01 PST." <94Nov13.113113pst.12173@skylark.parc.xerox.com> Date: Mon, 14 Nov 94 20:14:07 -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: Steve Deering Bill, .... We might also think about distributing the recommended initial Hop Limit in routing protocols, so upping the value in one router can cause all the other routers in the same routing domain to up their advertised values. This would be a compelling reason for having 'hop count' in router advertisments rather than DHCP - routing protocols distributing 'hop limit' information as a way to keep what source hosts set in packets that originate. > Done. I suggest that you wait a while to see if anyone identifies any problems with your idea before declaring it a done deal. Steve Agree. 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 Nov 14 18:02:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15596; Mon, 14 Nov 94 18:02:59 PST Received: from jurassic.Eng.Sun.COM (jurassic-52) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15590; Mon, 14 Nov 94 18:02:48 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id RAA09040; Mon, 14 Nov 1994 17:58:07 -0800 Date: Mon, 14 Nov 1994 17:58:07 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411150158.RAA09040@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <3453.bill.simpson@um.cc.umich.edu> Subject: re: (IPng) Definitions Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill, > We have one, it's called the overview. They are also in the IPv6 header > spec. Good suggestion. I will add a terminology section to the next version of the overview document. Thanks, 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 Nov 14 18:33:35 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15629; Mon, 14 Nov 94 18:33:35 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15623; Mon, 14 Nov 94 18:33:28 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13924; Mon, 14 Nov 94 18:29:08 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA03039; Mon, 14 Nov 94 18:28:41 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA01476; Mon, 14 Nov 1994 21:28:33 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA00026; Mon, 14 Nov 1994 21:28:31 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA26723; Mon, 14 Nov 1994 21:04:58 -0500 Message-Id: <9411150204.AA26723@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) high-speed slicing and dicing of headers..... In-Reply-To: Your message of "Mon, 14 Nov 94 09:26:14 EST." <9411141427.AA16848@Sun.COM> Date: Mon, 14 Nov 94 21:04:58 -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: yakov@watson.ibm.com .... That is correct for the case where there is only one ERP header AND there is no Hop-by-Hop Options header. First consider the case where there is more than one ERP header (after all, policies may need to be asserted more than once along a path). In this case the following shows the differences: Your proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header routing header 1 routing header 1 encapsulating IPv6 header routing header 2 routing header 2 ....... ..... original IPv6 header original IPv6 header rest of original packet rest of original packet Yakov, The draft - the October 1994 version - reads to me differently than your ERP scheme above, in the sense that the ERP header is inserted after the main original header rather than an encapsulating header. As a matter of fact it seems that the word tunnel or encapsulating is not mentioned at all in the draft. I gathered from the mailing list that it was also others people's reading as well. I think the draft could be more clear in that direction. Your proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header original Hop-by-hop header original Hop-by-hop header routing header routing header original IPv6 header original IPv6 header original Hop-by-hop header rest of original packet rest of original packet Observe that in this case the Hop-by-hop Options header is present *twice* with your proposal, and only *once* with the ERP scheme. Again, your scheme incurs more octets overhead than the ERP scheme. .... I may refer again to a version of the document which is not the most recent, so apologies, but there is no hop-by-hop processing in the draft that I can refer to. For your scheme to work correctly, the hop-by-hop header should be reinserted after the original IPv6 header, upon decapsulating the original payload. Is that the case, or some other mechanism is envisaged?, and where is that documented?. 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 Nov 14 18:55:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15641; Mon, 14 Nov 94 18:55:46 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15635; Mon, 14 Nov 94 18:55:34 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16479; Mon, 14 Nov 94 18:51:15 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA08422; Mon, 14 Nov 94 18:50:48 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id VAA04573 for ipng@sunroof.Eng.Sun.COM; Mon, 14 Nov 1994 21:52:11 -0500 (EST) Date: Mon, 14 Nov 1994 21:52:11 -0500 (EST) From: Scott Bradner Message-Id: <199411150252.VAA04573@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM ----- Your proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header original Hop-by-hop header original Hop-by-hop header routing header routing header original IPv6 header original IPv6 header original Hop-by-hop header rest of original packet rest of original packet ---- What if the encapsulating node wants to have a different set of hop-by-hop options or just wants to add one or more new options (as I can think that it might) - the resulting hop-by-hop header following the encapsulating IPv6 header could be a sum of the two sets of requirements or just those of the encapsulating node depending on it's whim. 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 Nov 14 20:31:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15707; Mon, 14 Nov 94 20:31:28 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15701; Mon, 14 Nov 94 20:31:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA22629; Mon, 14 Nov 94 20:26:58 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA22684; Mon, 14 Nov 94 20:26:32 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA19653 for ; Mon, 14 Nov 1994 23:26:30 -0500 Date: Tue, 15 Nov 94 03:50:41 GMT From: "William Allen Simpson" Message-Id: <3458.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Andrew Myles > True. > True. > > > as it can _only_ be used when datagrams are not fragmented. > > Wrong!!!!!!!!!!!! > How is it I'm right about all the details, but wrong about the actual meaning, when I'm the one who _wrote_ that meaning? > The deal is as follows: > > The minimal encapsulation can be fragmented, however, the > fragments cannot be tunnelled using minimal encapsulation. > This makes neither semantic nor grammatic sense. I take note of your difficulty expressing yourself in a foreign language. > Your continuing misunderstanding of this point is of great concern. > Ahhh, but then (and I quote): From: Andrew Myles Date: Sat, 21 May 94 3:45:26 EST you clearly do not understand Mobile-IP. I suggest that you share the flight to SJ with Alan. You have a lot of attitude in common. In the meantime, this is unrelated to IPng. We are not using any form of "minimal" encapasulation. 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 Nov 14 21:33:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15812; Mon, 14 Nov 94 21:33:31 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15806; Mon, 14 Nov 94 21:33:24 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA25593; Mon, 14 Nov 94 21:29:05 PST Received: from avalon.mpce.mq.edu.au by Sun.COM (sun-barr.Sun.COM) id AA28263; Mon, 14 Nov 94 21:28:32 PST Message-Id: <9411150528.AA28263@Sun.COM> Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA12459; Tue, 15 Nov 94 16:28:23 edt From: Andrew Myles Subject: Re: (IPng) high-speed slicing and dicing of headers..... To: ipng@sunroof.Eng.Sun.COM Date: Tue, 15 Nov 94 16:28:21 EDT In-Reply-To: <3458.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Nov 15, 94 3:50 am Mailer: Elm [revision: 64.9] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM G'day all, I apologise to the rest of the list but I just have to reply to Bill Simpson's message. I will not further extend this thread. > > The deal is as follows: > > > > The minimal encapsulation can be fragmented, however, the > > fragments cannot be tunnelled using minimal encapsulation. > > This makes neither semantic nor grammatic sense. I will use my best "English" to help make the point clearer to you. A packet that is minimally encapsulated may be fragmented. However, fragments may not be tunnelled using minimal encapsulation. > I take note of your > difficulty expressing yourself in a foreign language. I guess it is possible that you have not heard that we speak a close derivitive of English in Australia. :) Otherwise, all I can say is that comments, such as this, are inappropriate in the IETF. > I suggest that you share the flight to SJ with Alan. You have a lot of > attitude in common. Ditto. I don't suppose an apology is possible to either myself or Alan? Andrew -- -------------------------------------------------------------------------------- Andrew Myles e-mail: andrewm@mpce.mq.edu.au Electronics Department www: http://www.mpce.mq.edu.au/~andrewm/ Macquarie University 2109 archive: ftp://avalon.mpce.mq.edu.au/dist Sydney, NSW voice: +61 2 8509071 (W), +61 2 8786060 (H) Australia fax: +61 2 8509128 -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Nov 14 21:54:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15824; Mon, 14 Nov 94 21:54:55 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15818; Mon, 14 Nov 94 21:54:48 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26266; Mon, 14 Nov 94 21:50:29 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA00280; Mon, 14 Nov 94 21:50:03 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA19614; Mon, 14 Nov 94 21:45:24 -0800 Received: by xirtlu.zk3.dec.com; id AA05407; Tue, 15 Nov 1994 00:45:20 -0500 Message-Id: <9411150545.AA05407@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Implementors Mtg(s) - SJ - Fairmont Hotel - Garden Room Date: Tue, 15 Nov 94 00:45:14 -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 ------- Forwarded Message Date: Mon, 14 Nov 94 19:30:05 -0500 From: Megan Davies Walnut Hi Jim, The Implementor's group will be meeting in the Garden Room. Megan >> Hi Megan, >> >> Do you know the rooms for implementor meetings yet? >> >> Sun Dec 4 1-6 p.m. >> Fri Dec 9 9-Noon >> >> Want to let the mailing list know on IPng. >> >> 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 Mon Nov 14 21:55:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15836; Mon, 14 Nov 94 21:55:36 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15830; Mon, 14 Nov 94 21:55:28 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA26309; Mon, 14 Nov 94 21:51:09 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA00328; Mon, 14 Nov 94 21:50:34 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AB24836; Tue, 15 Nov 1994 16:49:56 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA27991; Tue, 15 Nov 94 17:47:08 +1100 Message-Id: <9411150647.AA27991@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Tue, 15 Nov 94 16:50:45 AUS Date: Tue, 15 Nov 94 16:42:26 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: Re: re: (IPng) node/host/router To: ipng@sunroof2.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM dear mad, thanks for the enlightenment. your reply . "Host and routers are NOT functions, they are categories of communications". Would these categories be somewhat based on the "function" of the device in question? (In a very quiet voice) Communications is initiated by a "function" and its style and properties and classification is dependent on that function. However, because this issue affects the scheme of the universe, we must debate this one over a beer at SJ. I suppose because I know what I mean and you know what you mean, we are both mean. So who will shout the beer? 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 Nov 14 22:18:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15849; Mon, 14 Nov 94 22:18:21 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15843; Mon, 14 Nov 94 22:18:14 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27188; Mon, 14 Nov 94 22:13:55 PST Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA02583; Mon, 14 Nov 94 22:13:16 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA25458; Tue, 15 Nov 1994 17:12:30 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA28051; Tue, 15 Nov 94 18:10:18 +1100 Message-Id: <9411150710.AA28051@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Tue, 15 Nov 94 17:13:56 AUS Date: Tue, 15 Nov 94 16:56:17 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: Re: (IPng) high-speed slicing and dicing of headers..... To: ipng@sunroof2.Eng.Sun.COM Cc: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM thank you bill for your reference to me and my attitude. I think the saying goes , that if you continually have problems with other people and things, the answer can be found in the mirror. Attitude? well I do have strong conviction over some of the areas of my expertise. But I also believe in learning to improve one's capability and working relationships with people. This can be a long process. I started with the IETF in a painful way, but hopefully I have gone forward with this and started to contribute. So please do not mention my attitude when the evidence shows it is yours that still seems to attract most of the flames on this list. Look in the Mirror! 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 Nov 14 22:22:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15861; Mon, 14 Nov 94 22:22:53 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15855; Mon, 14 Nov 94 22:22:46 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27395; Mon, 14 Nov 94 22:18:27 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA03102; Mon, 14 Nov 94 22:17:59 PST Received: from styrax.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA08430; Tue, 15 Nov 1994 01:17:55 -0500 Received: from brigit.zk3.dec.com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM) id AA10068; Tue, 15 Nov 1994 01:17:51 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA27199; Tue, 15 Nov 1994 00:54:16 -0500 Message-Id: <9411150554.AA27199@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, bound@zk3.dec.com, set@thumper.bellcore.com, bob.gilligan@Eng Subject: (IPng) a few IPv6 API draft related comments: Date: Tue, 15 Nov 94 00:54:16 -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 -------- Here are a few comments on the IPv6 API draft: 1. On p6 - 4.3. The Socket Functions - system calls that handle IPv6 addresses do not mention 'sndmsg' and 'rcvmsg'. Is the omitting intentional? 2. On p10 to p13, "4.8. Handling of IPv6 Source Routing": 2.1 I think that for 'connect' or 'sendto' (or 'sndmsg') the array should be arranged differently, to match the IPv6 header, as it follows: sockaddr_in6[0] source address sockaddr_in6[1] first hop address ... sockaddr_in6[n-1] last hop address sockaddr_in6[n] destination address (ipv6 header has the order: source address destination address) 2.2 I think that returning the reversed source route headers for an accepted connection or a received packet is a good idea and useful capability, since it allows alternate 'accept' and 'connects', and 'receives' and 'sends' without any additional address processing. However, I think that this function should be asked for, through a system call flag on the ('accept' or) 'receive' call. The default address array returned should be in a non-reversed format, in which the array elements have the same meaning as in 2.1. This is because it may be useful to process the address array in a similar fashion for both send and receive. To provide a complete set of source routing functions, the ('connect' or 'send') calls should provide a function of reversing an array source routing, before passing the information down to the IPv6 layer, which could be enabled through a system call flag. The default behavior is certainly a matter of choice, however, a complete set of calls that handle non reversed addresses should be provided. 3. On p13, on "4.9 Sending and Receiving Multicast Packets". 3.1 IP_MULTICAST_IF I am not sure whether it is necessary. I can see two clear cases, that will be handled without this parameter: 3.1.1. socket bound to ADDR_ANY - send the multicast packet on all interfaces i.e. all links. 3.1.2. socket bound to IPv6 address - send the multicast packet only on the interface that has the bound IPv6 address. 3.2 IP_MULTICAST_TTL Is this really needed? since a 'hop count function' exist for unicast, which can be used? I am afraid, that there will be more confusion having two separate functions for setting 'hop count'. 4. On p15 "4.11 Address Conversion Functions" should/could provide a function for reversing a source routing array. 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 Mon Nov 14 23:26:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15994; Mon, 14 Nov 94 23:26:38 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15988; Mon, 14 Nov 94 23:26:30 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29612; Mon, 14 Nov 94 23:22:12 PST Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA08125; Mon, 14 Nov 94 23:21:44 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06806; Tue, 15 Nov 1994 08:21:41 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02110; Tue, 15 Nov 1994 08:21:39 +0100 Message-Id: <9411150721.AA02110@dxcoms.cern.ch> Subject: Re: (IPng) IPv6 address representation To: ipng@sunroof.Eng.Sun.COM Date: Tue, 15 Nov 1994 08:21:39 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: from "Scott Brim" at Nov 14, 94 11:40:21 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: 1134 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott Bri*, You don't need to change any existing URLs. //128.141.13.198:8000/ remains valid. You do have to add IPv6 addresses to the URL definition, but you have to do that anyway, whatever the format, I think. Or else ban IPv6 addresses in URLs. You can't use periods in IPv6 addresses, unless somebody knows how to tell whether 128 is decimal or hexadecimal by inspection. If colons are broken we would have to use something else. Brian >--------- Text sent by Scott Brim follows: > > At 10:54 AM 11/14/94, Brian Carpenter CERN-CN wrote: > >The simplest fix is an alternative URL syntax using something other > >than : before the port #. > > It'll be a lot easier to change IPv6 syntax than to change URL syntax. > Go ahead, find all the URLs in the world with port numbers in them :-) > > ...Scott (the other 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 > ------------------------------------------------------------------------------ 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 Nov 15 00:11:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16054; Tue, 15 Nov 94 00:11:51 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16048; Tue, 15 Nov 94 00:11:44 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA01297; Tue, 15 Nov 94 00:07:25 PST Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA14809; Tue, 15 Nov 94 00:06:50 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA23362; Tue, 15 Nov 94 00:03:05 -0800 Received: by xirtlu.zk3.dec.com; id AA06460; Tue, 15 Nov 1994 03:03:03 -0500 Message-Id: <9411150803.AA06460@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Attitude : Its represents your character Date: Tue, 15 Nov 94 03:02:56 -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 >Date: Tue, 15 Nov 94 16:56:17 AUS >From: Alan.Lloyd@datacraft.com.au >Attitude? I like yours it makes me think, check my position, determine if I am clear, and also gives me a needed perspective that is not U.S. centric, and more international. Plus your always professional and courteous like 99.9% of my colleagues on this mail list. I would not worry too much about the .001% that seem to have an unfriendly electronic tone in their mail. What goes around comes around we say in the U.S. It usually results that an attitude adjustment takes place at some point in time. Much like the one from a song by one of our well known country singers in one of his diatribes )---> Mr. Hank Williams Jr. /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 Nov 15 02:18:19 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16260; Tue, 15 Nov 94 02:18:19 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16254; Tue, 15 Nov 94 02:18:11 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06120; Tue, 15 Nov 94 02:13:52 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA26073; Tue, 15 Nov 94 02:13:21 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) a few IPv6 API draft related comments: To: ipng@sunroof.Eng.Sun.COM Date: Tue, 15 Nov 1994 10:13:27 +0100 (GMT) In-Reply-To: <9411150554.AA27199@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Nov 15, 94 00:54:16 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1259 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 2.2 I think that returning the reversed source route headers > for an accepted connection or a received packet is a > good idea and useful capability, > since it allows alternate 'accept' and 'connects', and > 'receives' and 'sends' without any additional address processing. > > However, I think that this function should be asked for, through > a system call flag on the ('accept' or) 'receive' call. I question this. ip6_reverse_address() or similar belongs as a user mode library call not a potentially kernel function. > The default behavior is certainly a matter of choice, however, a > complete set of calls that handle non reversed addresses should be > provided. One routine to do the reversing is all thats needed, and this will also encourage people to make one copy of the address reverse it and store it away not simply spend all day reversing addresses in the syscalls. > 3.2 IP_MULTICAST_TTL > Is this really needed? since a 'hop count function' exist for unicast, which > can be used? I am afraid, that there will be more confusion having two > separate functions for setting 'hop count'. Its in IPv4 multicast and its used by some people in cases where one socket sends both multicast and unicast datagrams. 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 Tue Nov 15 02:28:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16276; Tue, 15 Nov 94 02:28:24 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16270; Tue, 15 Nov 94 02:28:17 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA06293; Tue, 15 Nov 94 02:23:58 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA27002; Tue, 15 Nov 94 02:23:28 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) high-speed slicing and dicing of headers..... To: ipng@sunroof.Eng.Sun.COM Date: Tue, 15 Nov 1994 10:23:39 +0100 (GMT) In-Reply-To: <9411150528.AA28263@Sun.COM> from "Andrew Myles" at Nov 15, 94 04:28:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 270 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > A packet that is minimally encapsulated may be fragmented. However, > fragments may not be tunnelled using minimal encapsulation. I also BTW couldn't parse the original version of that - it now makes sense. However I agree Bill was well out of order. 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 Tue Nov 15 05:02:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16346; Tue, 15 Nov 94 05:02:37 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16340; Tue, 15 Nov 94 05:02:28 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09149; Tue, 15 Nov 94 04:58:09 PST Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA11939; Tue, 15 Nov 94 04:57:27 PST Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA11892; Tue, 15 Nov 1994 14:00:08 +0100 Message-Id: <199411151300.AA11892@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) node router host In-Reply-To: Your message of "Tue, 15 Nov 1994 04:56:32 +1100." <13572.784835792@munnari.OZ.AU> Date: Tue, 15 Nov 1994 14:00:04 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >However, while the label "host" for something that is a node >and not a router doesn't bother me, the concept of defining >this by exclusion does. The more I see this thread, the more I believe that we have one concept too many. I understand what a router is, can thus easily explain that some nodes take part in routing and some don't. The logic and the history are behind the use of "router" and "host" to distinguish those two categories. However, as Robert mentions, the distinction is positive. A router is a host that does something more, i.e. forwarding. In fact, there are few things that hosts do and that routers in practice don't. Most routers, for example, provide telnet accesses. Many will originate tftp connections. Colocating various servers and routers is quite common. The whole thread started from a precise configuration problem: when does a node join the "all nodes" list, but does not join the "all hosts" list. My personal opinion is: never. Let's just have two groups, i.e. all hosts and all routers. Beside, as routers have to listen to all multicast groups, defining a specific multicast group for "every hosts but the routers" is not terribly useful. 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 Tue Nov 15 05:42:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16418; Tue, 15 Nov 94 05:42:24 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16412; Tue, 15 Nov 94 05:42:16 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10219; Tue, 15 Nov 94 05:37:58 PST Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA15557; Tue, 15 Nov 94 05:37:31 PST Message-Id: <9411151337.AA15557@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7813; Tue, 15 Nov 94 08:37:37 EST Date: Tue, 15 Nov 94 08:34:06 EST From: yakov@watson.ibm.com To: sob@newdev.harvard.edu Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) high-speed slicing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Scott, >What if the encapsulating node wants to have a different set of >hop-by-hop options or just wants to add one or more new options That brings the issue of what is the *exact* semantics of the Hop-by-Hop Options header and the interaction of this semantics with encapsulation. As stated in the IPv6 document: "... is the Hop-by-Hop Options header, which carries information that must be examined by every node along a packet's delivery path." To illustrate some of the issues assume that the original packet has the Hop-by-Hop Options header: original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of original packet Furthermore, assume that some router along the path decides to encapsulate this packet. Then conceivably there are two choices: Choice 1: encapsulating IPv6 header (src = X, dst = Y) original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of the original packet Choice 2: encapsulating IPv6 header (src = X, dst = Y) original Hop-by-Hop header original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of the original packet To preserve currently specified semantics of the Hop-by-Hop Options header (it must be examined by every node along a packet's delivery path), it follows that all the nodes (routers) between A and B, *including all the nodes between X and Y*, have to examine the original Hop-by-Hop header. Observer that with Choice 1 it would be rather difficult to preserve the semantics. If the router that performs the encapsulation wants to add one or more Hop-by-Hop options, then I think that the correct semantics would be to require that these added options will apply only to the nodes in the path between src and dst, as specified in the encapsulating header, but the options inserted by the original source should be applied to all the nodes (including the nodes in the encapsulation path). Using the above example I would assume that if router X (the router that performs encapsulation) wants to add some Hop-by-Hop options, then these options *must* be examined by every node along a packet's delivery path from X to Y, but once the packet reaches Y all the nodes in the path from Y to B must *not* examine these options. The options specified in the original Hop-by-Hop header *must* be examined by *all* the nodes along the path, including all the nodes along the path from X to Y. Yakov. P.S. Correct me if I am wrong, but it seems that handling of Hop-by-Hop options in conjuction with encapsulation is left open in the current set of IPv6 documents. ------------------------------------------------------------------------------ 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 Nov 15 05:50:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16430; Tue, 15 Nov 94 05:50:17 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16424; Tue, 15 Nov 94 05:50:06 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10514; Tue, 15 Nov 94 05:45:47 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA16677; Tue, 15 Nov 94 05:45:17 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id IAA05887; Tue, 15 Nov 1994 08:46:51 -0500 (EST) Date: Tue, 15 Nov 1994 08:46:51 -0500 (EST) From: Scott Bradner Message-Id: <199411151346.IAA05887@newdev.harvard.edu> To: sob@newdev.harvard.edu, yakov@watson.ibm.com Subject: (IPng) Re: high-speed slicing Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > P.S. Correct me if I am wrong, but it seems that handling of Hop-by-Hop options in conjuction with encapsulation is left open in the current set of IPv6 documents. well, that is kinda what I was hinting at :-) 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 Tue Nov 15 05:51:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16442; Tue, 15 Nov 94 05:51:04 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16436; Tue, 15 Nov 94 05:50:56 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10560; Tue, 15 Nov 94 05:46:37 PST Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA16767; Tue, 15 Nov 94 05:46:03 PST Message-Id: <9411151346.AA16767@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7939; Tue, 15 Nov 94 08:46:09 EST Date: Tue, 15 Nov 94 08:45:07 EST From: yakov@watson.ibm.com To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Mon, 14 Nov 94 21:04:58 -0500 Alex, >... the ERP header is inserted after the main original header rather than >an encapsulating header... You are absolutely correct. My mistake. So, let me restate the pictures. For just ERP headers: Steve's proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header routing header 1 routing header 1 encapsulating IPv6 header routing header 2 routing header 2 ....... ..... rest of original packet original IPv6 header rest of original packet For ERP headers in presence of Hop-by-Hop Options header: Steve's proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header original Hop-by-hop header original Hop-by-hop header routing header routing header original IPv6 header rest of original packet original Hop-by-hop header rest of original packet Yakov. ------------------------------------------------------------------------------ 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 Nov 15 07:29:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16546; Tue, 15 Nov 94 07:29:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16534; Tue, 15 Nov 94 07:29:24 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14395; Tue, 15 Nov 94 07:25:05 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA29507; Tue, 15 Nov 94 07:24:38 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-11.dialip.mich.net [35.1.48.92]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA07118 for ; Tue, 15 Nov 1994 10:24:34 -0500 Date: Tue, 15 Nov 94 13:04:37 GMT From: "William Allen Simpson" Message-Id: <3459.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Discovery LifeTimes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > To: ietf@CNRI.Reston.VA.US > From: "Perry E. Metzger" > Similarly, I've noted that some proposed discovery formats indicate > lifetimes for advertised information in (16 bit value) seconds. In an > era where many people are noting that a couple of seconds lifetime for > some information on T3s is almost too long, the upper bound of these > values (18.2 hours) seems very high, and the lower bound, one second, > is certain to seem like a very long period when we are dealing > routinely with links that operate in the tens to hundreds of gigabits > per second. > We've talked about this before, but here it is again: The LifeTime has nothing to do with link speed, except that more advertisements tend to congest slower links. The LifeTime is related to how long humans are willing to wait for black hole detection (see Design Requirements, 3.6), and to the speed at which a processor saturated system can be _required_ to handle the updates (ibid 3.2). Since this gives us a range of 10 seconds to 1 second (reflected in IPng Mobility RFC-1688), the current range is entirely adequate. MIBs routinely use fields calibrated in 100 milliseconds, so that would be another possible scale. But, I don't see how we can REQUIRE _every_ node to actually handle such update speeds. On the other hand, some folks (with whom I do not agree) think that infinity is a useful lifetime. Thus, we have pushes for 32-bit address registration times, for example. And remember, during the update, we are now _HOLDING_ the data packets. This could have tremendous limitations on audio/video, exactly the type of packets where high bandwidth links might be useful. So, we now use the same default value established for IPv4 Router Discovery, which is 1800 seconds. Not terribly useful as a black-hole detection, but more friendly to audio/video. 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 Nov 15 07:29:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16547; Tue, 15 Nov 94 07:29:51 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16540; Tue, 15 Nov 94 07:29:30 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA14404; Tue, 15 Nov 94 07:25:10 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA29524; Tue, 15 Nov 94 07:24:43 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-11.dialip.mich.net [35.1.48.92]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA07126 for ; Tue, 15 Nov 1994 10:24:41 -0500 Date: Tue, 15 Nov 94 14:59:40 GMT From: "William Allen Simpson" Message-Id: <3461.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) node router host Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Christian Huitema > The whole thread started from a precise configuration problem: when does a > node join the "all nodes" list, but does not join the "all hosts" list. My > personal opinion is: never. Let's just have two groups, i.e. all hosts and all > routers. Beside, as routers have to listen to all multicast groups, defining a > specific multicast group for "every hosts but the routers" is not terribly > useful. > I agree. Since all-hosts is not used, and all-hosts is not defined in IPv4, we should simply delete all-hosts from the addressing draft. 1 is all-nodes (called all-systems in rfc-1700). 2 is all-routers (same as rfc-1700). 3 is reserved (same as rfc-1700). 11 is mobile-agents (same as rfc-1700). 7.0 .. 255 is selected-nodes (assigned by IANA). 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 Nov 15 08:55:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16657; Tue, 15 Nov 94 08:55:24 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16651; Tue, 15 Nov 94 08:55:12 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21810; Tue, 15 Nov 94 08:50:53 PST Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA14093; Tue, 15 Nov 94 08:47:49 PST Received: from relay.imsi.com by wintermute.imsi.com id KAA28986 for ; Tue, 15 Nov 1994 10:53:51 -0500 Received: from snark.imsi.com by relay.imsi.com id KAA17458 for ; Tue, 15 Nov 1994 10:53:50 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA02440; Tue, 15 Nov 94 10:53:50 EST Message-Id: <9411151553.AA02440@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Discovery LifeTimes In-Reply-To: Your message of "Tue, 15 Nov 1994 13:04:37 GMT." <3459.bill.simpson@um.cc.umich.edu> X-Reposting-Policy: redistribute only with permission Date: Tue, 15 Nov 1994 10:53:49 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "William Allen Simpson" says: > We've talked about this before, but here it is again: > > The LifeTime has nothing to do with link speed, except that more > advertisements tend to congest slower links. > > The LifeTime is related to how long humans are willing to wait for black > hole detection I do know what they are for -- thats my whole point. Black hole detection is too slow right now for my tastes. It would be unfortunate if it could never happen faster than one second. Certainly as you note the link speed isn't the only issue, but the overall progress of computing technology is. We must assume that in ten years computers will be far faster than they are today -- FAR faster. The processing a computer today can do in five seconds will be performed in five thousandths of a second in ten to fifteen years. Similarly, as you point out, links that would have been unsaturated by updates every ten seconds today would be very happy to handle updates every few millisecond without remotely noticed loss of bandwidth. As routers, hosts and links increase in speed it will be necessary for the switchover time in case of failure to go down proportionally. Machines and links have increased in speed by a factor of some thousands since IPv4 was specified -- we must assume the same over the lifetime of v6. We can already see ourselves operating within a factor of five of the LifeTime lower bound on advertisement -- surely what seems generous now will seem constraining when things are 1000 times or 10000 times faster, as they surely will be. We should not make the reliability of our networks remain static as hosts speed up -- we should aim for ever smaller outages. > MIBs routinely use fields calibrated in 100 milliseconds, so that would > be another possible scale. But, I don't see how we can REQUIRE _every_ > node to actually handle such update speeds. We don't have to require them to pay attention. NTP calibrates times in units far smaller than most hosts can handle and yet they use NTP very well. If someone rigs their router to advertise microsecond lifetimes well, they made a mistake. We can't protect people from everything -- someone could also drop coffee into their router and no amount of clever protocols will stop that. If you get a LifeTime thats smaller than you can deal with you should simply throw it away at your next clock tick. This is not the issue. The point is simply this: in the future, we are going to want to switch between routers in milliseconds in case of failure. This will seem as natural as switching in seconds seems today given that the routers will be thousands of times faster and the links capable of handling thousands of times the advertisements. Constraining ourselves this way when ICMP packets are not particularly bloated seems like a bad idea. My users already complain when it takes seconds for routers to recover -- how much more will they complain about that if we are stuck with the same recovery times in twenty years? I'd propose using a 32 bit number of 10E-6 seconds as the LifeTime parameter in discovery. This allows an advertisment for a router to live 1.12 hours -- far longer than needed to keep even 300 baud links unclogged -- and also allows us, in the future when hosts and links are orders of magnitude faster, to knock advertisements down to millisecond periods or beyond. If people really want "forever" they can simply set all 1's in the LifeTime as has been proposed. 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 Nov 15 10:08:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16723; Tue, 15 Nov 94 10:08:28 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16717; Tue, 15 Nov 94 10:08:21 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA02710; Tue, 15 Nov 94 10:04:02 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA28728; Tue, 15 Nov 94 10:03:21 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA10300; Tue, 15 Nov 1994 13:03:13 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA05385; Tue, 15 Nov 1994 13:03:10 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA27541; Tue, 15 Nov 1994 12:39:34 -0500 Message-Id: <9411151739.AA27541@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: yakov@watson.ibm.com, conta@zk3.dec.com Subject: Re: (IPng) high-speed slicing and dicing of headers..... In-Reply-To: Your message of "Tue, 15 Nov 94 08:45:07 EST." <9411151401.AA29542@decvax.dec.com> Date: Tue, 15 Nov 94 12:39:34 -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: yakov@watson.ibm.com For just ERP headers: Steve's proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header routing header 1 routing header 1 encapsulating IPv6 header routing header 2 routing header 2 ....... ..... rest of original packet original IPv6 header rest of original packet For ERP headers in presence of Hop-by-Hop Options header: Steve's proposal: ERP scheme: -------------- ----------- encapsulating IPv6 header encapsulating IPv6 header original Hop-by-hop header original Hop-by-hop header routing header routing header original IPv6 header rest of original packet original Hop-by-hop header rest of original packet Yakov. Yakov, Shouldn't it be?: .... ERP scheme ------------- original IPv6 main header routing header 1 routing header 2 .... rest of original packet .... .... ERP scheme ------------- original IPv6 main header original hop-by-hop header routing header rest of original packet Which is the way I read the draft. 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 Nov 15 10:44:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16771; Tue, 15 Nov 94 10:44:56 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16764; Tue, 15 Nov 94 10:44:49 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08467; Tue, 15 Nov 94 10:40:29 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA06153; Tue, 15 Nov 94 10:39:40 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA11770; Tue, 15 Nov 1994 13:38:01 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA06687; Tue, 15 Nov 1994 13:37:54 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA24899; Tue, 15 Nov 1994 13:14:19 -0500 Message-Id: <9411151814.AA24899@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: sob@newdev.harvard.edu, yakov@watson.ibm.comi, conta@zk3.dec.com Subject: Re: (IPng) high-speed slicing In-Reply-To: Your message of "Tue, 15 Nov 94 08:34:06 EST." <9411151337.AA15557@Sun.COM> Date: Tue, 15 Nov 94 13:14:19 -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: yakov@watson.ibm.com That brings the issue of what is the *exact* semantics of the Hop-by-Hop Options header and the interaction of this semantics with encapsulation. As stated in the IPv6 document: "... is the Hop-by-Hop Options header, which carries information that must be examined by every node along a packet's delivery path." .... Yakov. P.S. Correct me if I am wrong, but it seems that handling of Hop-by-Hop options in conjuction with encapsulation is left open in the current set of IPv6 documents. From: sob@newdev.harvard.edu well, that is kinda what I was hinting at :-) Yakov, and Scott, I concur that some clarification in the text would help disipate possible confusion, or misinterpretation. As I see it, the architecture is such that encapsulating a packet, means creating a complete new packet, with a new set of main header and extension headers, which means, new source and destination, new hop by hop options, new path, etc... The original packet is just a payload like any other payload. It is the encapsulator node (the entry in the tunnel) that may decide to use NONE, or PARTIAL, or ENTIRE information from the original packet's main and extension headers: hop by hop options, routing, etc... , based on the tunnel properties. The specs, I think, should not rule one way or another, but leave it open, as in fact do - perhaps clarify that it is open, i.e. none, partial, or entire reuse of original packet headers information is a choice to be made by the entry node in the tunnel, based on the tunnel properties. To illustrate the above, here is a subset of possible choices, which are valid: original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of original packet Encapsulator node choice 1: encapsulating IPv6 header (src = X, dst = Y) original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of the original packet Encapsulator node choice 2: encapsulating IPv6 header (src = X, dst = Y) original Hop-by-Hop header original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of the original packet Encapsulator node choice 3: encapsulating IPv6 header (src = X, dst = Y) new Hop-by-Hop header original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of the original packet Encapsulator node choice 4: encapsulating IPv6 header (src = X, dst = Y) new and original Hop-by-Hop header original IPv6 header (src = A, dst = B) original Hop-by-Hop header rest of the original packet ...etc... 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 Nov 15 10:59:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16787; Tue, 15 Nov 94 10:59:31 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16781; Tue, 15 Nov 94 10:59:20 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11194; Tue, 15 Nov 94 10:55:00 PST Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA09396; Tue, 15 Nov 94 10:54:23 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA06984; Tue, 15 Nov 1994 13:51:16 -0500 (EST) Date: Tue, 15 Nov 1994 13:51:16 -0500 (EST) From: Scott Bradner Message-Id: <199411151851.NAA06984@newdev.harvard.edu> To: conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing Cc: sob@newdev.harvard.edu, yakov@watson.ibm.comi Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex, > perhaps clarify that it is open I'm not so happy with this approach. I think specific scenarios should be detailed. I do think that allowing the encapsulating node to determine things is not all bad as long as there are some understood rules. Open options is just what gets standards into trouble. 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 Tue Nov 15 11:35:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16841; Tue, 15 Nov 94 11:35:51 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16835; Tue, 15 Nov 94 11:35:44 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17130; Tue, 15 Nov 94 11:31:25 PST Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA16794; Tue, 15 Nov 94 11:29:43 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA13888; Tue, 15 Nov 1994 14:29:08 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA12536; Tue, 15 Nov 1994 14:29:04 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA23462; Tue, 15 Nov 1994 14:05:31 -0500 Message-Id: <9411151905.AA23462@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) node router host In-Reply-To: Your message of "Tue, 15 Nov 94 14:59:40 GMT." <3461.bill.simpson@um.cc.umich.edu> Date: Tue, 15 Nov 94 14:05: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: Christian Huitema The whole thread started from a precise configuration problem: when does a node join the "all nodes" list, but does not join the "all hosts" list. My personal opinion is: never. Let's just have two groups, i.e. all hosts and all routers. Beside, as routers have to listen to all multicast groups, defining a specific multicast group for "every hosts but the routers" is not terribly useful. From: "William Allen Simpson" I agree. Since all-hosts is not used, and all-hosts is not defined in IPv4, we should simply delete all-hosts from the addressing draft. 1 is all-nodes (called all-systems in rfc-1700). 2 is all-routers (same as rfc-1700). 3 is reserved (same as rfc-1700). 11 is mobile-agents (same as rfc-1700). 7.0 .. 255 is selected-nodes (assigned by IANA). -------- Christian says: "Let's just have two groups, i.e. all hosts and all routers". Bill says:" I agree... we simply should delete all-hosts...(and use) all-nodes and all-routers". I am confused: "I agree" cotradicts "we ..delete all-hosts" did you Bill mean "I disagree", or "delete all-nodes, and use all-hosts and all-routers"?, or "since both routers and hosts will listen to "all-hosts" why not use "all-nodes" and get rid of "all-hosts"?. ??? 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 Nov 15 18:30:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17277; Tue, 15 Nov 94 18:30:56 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17271; Tue, 15 Nov 94 18:30:40 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23465; Tue, 15 Nov 94 18:26:21 PST Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA06758; Tue, 15 Nov 94 18:25:51 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11244; 15 Nov 94 16:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-simpson-ipv6-discov-formats-01.txt Date: Tue, 15 Nov 94 16:35:35 -0500 Message-Id: <9411151635.aa11244@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 : IPv6 Neighbor Discovery -- ICMP Message Formats Author(s) : W. Simpson Filename : draft-simpson-ipv6-discov-formats-01.txt Pages : 35 Date : 11/14/1994 This document specifies ICMP messages for identification of and forwarding to adjacent IPv6 nodes, including Mobility, Next Hop Determination and Router Discovery. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-ipv6-discov-formats-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-ipv6-discov-formats-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-formats-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: <19941114171240.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-discov-formats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-discov-formats-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941114171240.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 Wed Nov 16 01:04:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17413; Wed, 16 Nov 94 01:04:40 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17407; Wed, 16 Nov 94 01:04:33 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11056; Wed, 16 Nov 94 01:00:13 PST Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA15381; Wed, 16 Nov 94 00:59:43 PST Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA20597; Wed, 16 Nov 1994 10:02:40 +0100 Message-Id: <199411160902.AA20597@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) node router host In-Reply-To: Your message of "Tue, 15 Nov 1994 14:05:31 EST." <9411151905.AA23462@brigit.zk3.dec.com> Date: Wed, 16 Nov 1994 10:02:39 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Well, I proposed to keep two groups, one for "all systems" and one for "routers only". I called them "all hosts" and "all routers". Bill calls them "all nodes" and "all routers". I am not interested in discussing the details; in fact, in my old non-english seaking brain, host == node. Just pick address #1 for "everything" and address #2 for "routers only". 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 Wed Nov 16 01:35:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17447; Wed, 16 Nov 94 01:35:14 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17441; Wed, 16 Nov 94 01:35:07 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11794; Wed, 16 Nov 94 01:30:48 PST Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA17722; Wed, 16 Nov 94 01:30:16 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Discovery LifeTimes To: ipng@sunroof.Eng.Sun.COM Date: Wed, 16 Nov 1994 09:30:32 +0100 (GMT) In-Reply-To: <9411151553.AA02440@snark.imsi.com> from "Perry E. Metzger" at Nov 15, 94 10:53:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 546 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I'd propose using a 32 bit number of 10E-6 seconds as the LifeTime > parameter in discovery. This allows an advertisment for a router to > live 1.12 hours -- far longer than needed to keep even 300 baud links > unclogged -- and also allows us, in the future when hosts and links Are ultraslow links a problem anyway, surely people will do any router advertising locally and an infinite timeout entry across the link itself - much the same was as dial on demand ISDN bridge manufacturers are going to end up spoofing router advertising. 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 Wed Nov 16 11:21:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17691; Wed, 16 Nov 94 11:21:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17685; Wed, 16 Nov 94 11:21:29 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA18026; Wed, 16 Nov 1994 11:15:51 -0800 Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA15850; Wed, 16 Nov 94 11:16:38 PST Received: from ftp.com by ftp.com ; Wed, 16 Nov 1994 14:16:24 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 16 Nov 1994 14:16:24 -0500 Received: from solensky.mccoy.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA07403; Wed, 16 Nov 94 14:16:02 EST Date: Wed, 16 Nov 94 14:16:02 EST Message-Id: <9411161916.AA07403@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Wed Nov 16 14:15:58 1994] Originating-Client: mccoy.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Scott Bradner > > It was just pointed out to me that currently URLs treat colons > a bit special.. Any suggestions about how to deal with this? How about using '-' as the separator and '=' to denote the zero-suppressed fields? I'd prefer '=' over '--' since it's sometimes difficult to tell the difference between one and two dashes in hard-copy documentation. This also satisfies Tony Li's request to avoid the shift key for the delimiting character. -- Frank ------------------------------------------------------------------------------ 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 Nov 16 11:29:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17703; Wed, 16 Nov 94 11:29:12 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17697; Wed, 16 Nov 94 11:29:05 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA04619; Wed, 16 Nov 1994 11:24:20 -0800 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA03085; Wed, 16 Nov 1994 11:25:36 +0800 Date: Wed, 16 Nov 1994 11:25:36 +0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9411161925.AA03085@kandinsky.Eng.Sun.COM> To: conta@zk3.dec.com Subject: (IPng) re: a few IPv6 API draft related comments Cc: ipng@sunroof Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alex - > > 1. On p6 - 4.3. The Socket Functions - system calls that handle IPv6 > addresses do not mention 'sndmsg' and 'rcvmsg'. Is the omitting intentional? Yes. Thanks for pointing that out. I'll change the spec. > 2. On p10 to p13, "4.8. Handling of IPv6 Source Routing": > > 2.1 I think that for 'connect' or 'sendto' (or 'sndmsg') > > the array should be arranged differently, to match the > IPv6 header, as it follows . . . What is the reason for wanting that particular order? Performance? If so, remember that the system needs to break up the address buffer that is passed in in order to place the addresses into the IPv6 header. The source and first hop address go into the main IPv6 header, while the remaining n-2 addresses go into the option. My reasoning for selecting the ordering that I did is so that the first address in the buffer would be the same address whether or not the application is using source routes. That is, the first IPv6 address in the buffer passed in to sendto() is *always* the final destination; and the first address in the buffer returned by recvfrom() is *always* that of the originating node. I think this ordering will be more intuitive for the application writers. > 2.2 I think that returning the reversed source route headers > for an accepted connection or a received packet is a > good idea and useful capability, > since it allows alternate 'accept' and 'connects', and > 'receives' and 'sends' without any additional address processing. > > However, I think that this function should be asked for, through > a system call flag on the ('accept' or) 'receive' call. > > The default address array returned should be in a non-reversed > format, in which the array elements have the same meaning > as in 2.1. This is because it may be useful to process the address > array in a similar fashion for both send and receive. I disagree with this. As Alan Cox suggested, it is better to have the system just present and accept addresses in only *one* form. If the applications wants the addresses to be in the reverse order, it can easily reverse them. I don't think we should complicate a system API to do something that application code can easily do. > 3.1 IP_MULTICAST_IF > > I am not sure whether it is necessary. . . . Good question. I'd like to hear from people who have used the IPv4 multicast API to see they think that selection of the source interface could be better done via the bound address of the socket. > 3.2 IP_MULTICAST_TTL > > Is this really needed? since a 'hop count function' exist for unicast, which > can be used? I am afraid, that there will be more confusion having two > separate functions for setting 'hop count'. As Alan pointed out, the ability to specify different TTLs for unicast and multicast packets sent via the same socket has turned out to be a useful feature in IPv4. > 4. On p15 "4.11 Address Conversion Functions" > > should/could provide a function for reversing a source routing array. It would make sense to add such a function if we believe that it would be generally useful to applications. But I'm not sure I see how or when applications would need it. Given that the application can take the buffer that is returned by a recvfrom() call, and pass it directly into a sendto() call without any modification, why would the application need the reversal function? If we add a function for applications to reverse source route address buffers, then applications might be inclined to use it. Then they would need to remember what order each of their source route address buffers are in. I think it would be better if we simply define a canonical ordering for source route address buffers. If applications keep all of their source route address buffers in this form, and the system calls use this standard form, then we can *avoid* problems. Lets not invent the big-endian/little-endian problem all over again! 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 Wed Nov 16 12:12:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17728; Wed, 16 Nov 94 12:12:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17722; Wed, 16 Nov 94 12:12:29 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA21623; Wed, 16 Nov 1994 12:06:51 -0800 Received: from iifeak.swan.ac.uk ([137.44.100.1]) by Sun.COM (sun-barr.Sun.COM) id AA25784; Wed, 16 Nov 94 12:06:01 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPv6 address representation To: ipng@sunroof.Eng.Sun.COM Date: Wed, 16 Nov 1994 20:01:40 +0100 (GMT) In-Reply-To: <9411161916.AA07403@mailserv-D.ftp.com> from "Frank T Solensky" at Nov 16, 94 02:16:02 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > How about using '-' as the separator and '=' to denote the zero-suppressed > fields? I'd prefer '=' over '--' since it's sometimes difficult to tell > the difference between one and two dashes in hard-copy documentation. = is bad too many OS's use things like NAMESERVER=1.2.3.4 ------------------------------------------------------------------------------ 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 Nov 16 13:28:03 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17844; Wed, 16 Nov 94 13:28:03 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17838; Wed, 16 Nov 94 13:27:52 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA07143; Wed, 16 Nov 1994 13:22:13 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA07787; Wed, 16 Nov 94 13:21:53 PST Subject: Re: (IPng) re: a few IPv6 API draft related comments To: IPng Mailing list Date: Wed, 16 Nov 1994 16:20:57 -0500 (EST) From: Dan McDonald Cc: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9411162120.aa02313@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM (Regarding the selection of outbound interface w.r.t. multicast...) Using the interface that corresponds to the address of a bind(2) is a good idea. But Alex, didn't you say that if there was no bound address, a multicast packet should go out ALL interfaces? If so, IMHO that's a bad idea. Never mind what a hassle that is for the internals, but sending multicast packets out all multicast-capable interfaces could cause excessive network traffic, no? Wouldn't it also confuse multicast routing? (Steve D., help me here!) If not, then what would be the correct interface? I like the idea of a default route, or a route for all ff00::0 packets, which is what my code does right now when an interface has not been chosen explicitly. 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 Wed Nov 16 15:19:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17959; Wed, 16 Nov 94 15:19:04 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17913; Wed, 16 Nov 94 14:42:41 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA16403; Wed, 16 Nov 1994 14:37:03 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA22562; Wed, 16 Nov 94 14:37:18 PST From: Ran Atkinson Message-Id: <9411161533.ZM2184@sundance.itd.nrl.navy.mil> Date: Wed, 16 Nov 1994 15:33:40 -0500 In-Reply-To: Bob.Hinden@Eng.Sun.COM (Bob Hinden) "Security Docs" (Nov 16, 11:52) References: <199411161952.LAA05885@jurassic.Eng.Sun.COM> X-Mailer: Z-Mail (3.0.1 04apr94) To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) Revised Security Drafts available now 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 All, Thanks to help from Bob Hinden, the newly revised IPv6 security specs are available now for anonymous ftp. They have already been submitted to the Internet Drafts folks and should appear there in a few days. In the meantime, here are the URLs to get them from the Sun ftp site. IPv6 Security Architecture ftp://playground.sun.com/pub/ipng/draft-atkinson-ipng-sec-00.txt IPv6 Authentication header ftp://playground.sun.com/pub/ipng/draft-atkinson-ipng-auth-00.txt IPv6 Encapsulating Security Payload ftp://playground.sun.com/pub/ipng/draft-atkinson-ipng-esp-00.txt Comments on all are welcome. Discussion of these drafts normally occurs on the ipng mailing list. 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 Wed Nov 16 16:15:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18036; Wed, 16 Nov 94 16:15:41 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18030; Wed, 16 Nov 94 16:15:34 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA27398; Wed, 16 Nov 1994 16:09:55 -0800 From: conta@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA11055; Wed, 16 Nov 94 16:10:30 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA16661; Wed, 16 Nov 1994 19:09:12 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA08350; Wed, 16 Nov 1994 19:09:10 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA28335; Wed, 16 Nov 1994 18:45:36 -0500 Message-Id: <9411162345.AA28335@brigit.zk3.dec.com> To: Bob.Gilligan@Eng Cc: ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com Subject: (IPng) Re: a few IPv6 API draft related comments In-Reply-To: Your message of "Wed, 16 Nov 94 11:25:36 +0800." <9411161925.AA03085@kandinsky.Eng.Sun.COM> Date: Wed, 16 Nov 94 18:45:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Bob.Gilligan@eng.sun.com (Bob Gilligan) What is the reason for wanting that particular order? Performance? ... My reasoning for selecting the ordering that I did is so that the first address in the buffer would be the same address whether or not the application is using source routes. That is, the first IPv6 address in the buffer passed in to sendto() is *always* the final destination; and the first address in the buffer returned by recvfrom() is *always* that of the originating node. I think this ordering will be more intuitive for the application writers. Bob, My reasoning for a different order for 'connect', 'sendto' or 'sndmsg' is also intuitive, or perception related. Since the array of Source Route addresses specifies besides the path, also the source and the destination, I perceive as more natural to have the elements in the array ordered based on proximity, i.e. first = the closest. element [0] - the closest address - source address element [1] - next - first source route hop ... element [n-1] - next - last source route hop element [n] - the most distant - destination address If at an extreme, the Source Route array were used to specify the source and destination only - with no other addresses to specify Source Route path - the two only elements in the array would specify the source and destination, in that order. element [0] - the closest address - source address element [1] - the most distant - destination address >... > array in a similar fashion for both send and receive. I disagree with this. As Alan Cox suggested, it is better to have the system just present and accept addresses in only *one* form. If the applications wants the addresses to be in the reverse order, it can easily reverse them. In fact this is what I mean - to use by defualt *one* form. I believe right now the specs use two different forms: 'send',... - direct order 'recv',... - reverse order What I am suggesting, is to have 'send',... - direct order 'recv',... - direct order This implies though that to use the output of 'recv' to a subsequent 'send', the array must be put in reverse order. To make this more clear, if I had in my program a 'debugging' function, which would call a routine to print the source route array, with an output like: source: 1st SR hop: ... n SR hop: destination: I would have to reverse the output from 'recv' before calling the routine to output an incoming packet's source route. > 3.2 IP_MULTICAST_TTL As Alan pointed out, the ability to specify different TTLs for unicast and multicast packets sent via the same socket has turned out to be a useful feature in IPv4. I took Alan's point, and I think if this is useful in IPv4, then that's a good reason to keep it. > 4. On p15 "4.11 Address Conversion Functions" > > should/could provide a function for reversing a source routing array. It would make sense to add such a function if we believe that it would be generally useful to applications. I can think of at least several uses of such a routine - printing debugging information is just one - and it would save the time for users to write one, if the standard implementation would have one, just as other many routines for handling addresses. I do not have a strong opinion in this sense, although I may suggest such a routine for implementations that I can influence. 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 Wed Nov 16 16:18:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18048; Wed, 16 Nov 94 16:18:56 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18042; Wed, 16 Nov 94 16:18:49 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA27806; Wed, 16 Nov 1994 16:13:10 -0800 Received: from cheops.anu.edu.au by Sun.COM (sun-barr.Sun.COM) id AA11734; Wed, 16 Nov 94 16:13:38 PST Message-Id: <9411170013.AA11734@Sun.COM> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA22769; Thu, 17 Nov 94 11:13:23 +1100 From: Darren Reed Subject: Re: (IPng) Which m-cast groups to join? To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 11:13:22 +1100 (EDT) In-Reply-To: <94Nov11.080039pst.34050@swallow.parc.xerox.com> from "Steve Deering" at Nov 11, 94 08:00:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > any IPv6 module forwarder non-forwarder > --------------- --------- ------------- > > I have been using the terms: > > node router host > which compounds the vagueness of "system" with verbosity. > host router non-router > which assigns the term "host" to any IPv6 box. Could we get used to > saying "multihomed non-routers"? > > Or we could use: > host router end host I like this one. Or even better... node router end host Then there are multi-homed hosts which act as routers. Should these be called routers ? In the case of multi-homed unix workstations which forward packets, is it correct to call them a router above and beyond being a host ? I don't like the idea of a "host" necessarily NOT forwarding packets. A router (I see) is a specialised host, which is dedicated and built to forward packets if it is used as such. A special case of a node which forwards packets. If this is just for some document, then as long as it doesn't pretend to set in concrete the meanings and associations it uses w.r.t hosts and routers and what role they have in IPv6, it shouldn't matter too much so long as it(they) are all consistant. darren ------------------------------------------------------------------------------ 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 Nov 16 18:09:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18183; Wed, 16 Nov 94 18:09:12 PST Received: from snail.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18177; Wed, 16 Nov 94 18:09:00 PST Received: from Sun.COM (sun-barr) by snail.Sun.COM (4.1/SMI-4.1) id AA04996; Wed, 16 Nov 94 18:04:14 PST Received: from sg543689.eng.chrysler.com by Sun.COM (sun-barr.Sun.COM) id AA03836; Wed, 16 Nov 94 18:04:09 PST 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 UAA04880 for ; Wed, 16 Nov 1994 20:51:02 -0500 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.4/8.6.4) with SMTP id UAA08233 for ; Wed, 16 Nov 1994 20:51:00 -0500 Received: from grid (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA17653; Wed, 16 Nov 94 21:01:19 EST Message-Id: <9411170201.AA17653@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: Wed, 16 Nov 1994 20:50:18 -0600 To: ipng@sunroof From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) manual configuration Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I am running a bit behind, Ahem. I am in a launch of 1,500 dialup IP users :) >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. Another use of manual config, that I stated back in the beginning of the autoconfig work might be a plant cell controller. There is too much, economically, riding on such a unit to leave much to chance. If the network goes bluey, these things still have to do their best to keep the line rolling. The general figure is 15min of down time = $1M. Also if the line is down for, I think, 20 min. The workers go home... 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 Wed Nov 16 18:13:41 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18196; Wed, 16 Nov 94 18:13:41 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18190; Wed, 16 Nov 94 18:13:34 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA10020; Wed, 16 Nov 1994 18:07:55 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA04699; Wed, 16 Nov 94 18:08:30 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18270; Thu, 17 Nov 1994 12:39:51 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation In-Reply-To: Your message of "Wed, 16 Nov 1994 14:16:02 EST." <9411161916.AA07403@mailserv-D.ftp.com> Date: Thu, 17 Nov 1994 12:39:45 +1100 Message-Id: <13914.785036385@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Wed, 16 Nov 94 14:16:02 EST From: solensky@ftp.com (Frank T Solensky) Message-ID: <9411161916.AA07403@mailserv-D.ftp.com> How about using '-' as the separator and '=' to denote the zero-suppressed fields? I quite like this, better than ':'. From: iialan@iifeak.swan.ac.uk (Alan Cox) Date: Wed, 16 Nov 1994 20:01:40 +0100 (GMT) Message-Id: = is bad too many OS's use things like NAMESERVER=1.2.3.4 doesn't worry me, NAMESERVER==1.2.3.4 is not ambiguous, just a little odd, and can be written NAMESERVER=0=1.2.3.4 if it causes a problem. 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 Wed Nov 16 18:19:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18209; Wed, 16 Nov 94 18:19:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18203; Wed, 16 Nov 94 18:19:17 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA10667; Wed, 16 Nov 1994 18:13:38 -0800 From: yakov@watson.ibm.com Received: from by Sun.COM (sun-barr.Sun.COM) id AB03943; Wed, 16 Nov 94 07:54:41 PST Message-Id: <9411161554.AB03943@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6091; Wed, 16 Nov 94 08:56:34 EST Date: Wed, 16 Nov 94 08:55:26 EST To: conta@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) high-speed slicing and dicing of headers..... Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Tue, 15 Nov 94 12:39:34 -0500 Alex, >Shouldn't it be ?: > > ERP scheme: > ---------- > > original IPv6 main header > routing header 1 > routing header 2 > ..... > rest of original packet > > > ERP scheme: > ----------- > original IPv6 main header > original hop-by-hop header > routing header > rest of original packet > >Which is the way I read the draft. A router that inserts an ERP header certainly changes the "original IPv6 main header". For example, the router places the source address from the original header into the ERP header (it is saved there), and puts its own address in the source address field of the main header (see Section 5 in the ERP I-D). Also note that the destination address field in the "original IPv6 main header" changes as a packet follows an ERP route (see Sections 6.2.1 and 6.2.2 in the ERP I-D). So, it is not exactly the original main header any more. Yakov. ------------------------------------------------------------------------------ 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 Nov 16 19:49:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18274; Wed, 16 Nov 94 19:49:17 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18268; Wed, 16 Nov 94 19:49:07 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA17950; Wed, 16 Nov 1994 19:43:28 -0800 From: conta@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA21663; Wed, 16 Nov 94 19:44:17 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22691; Wed, 16 Nov 1994 22:44:14 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA12370; Wed, 16 Nov 1994 22:44:12 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA28419; Wed, 16 Nov 1994 22:20:37 -0500 Message-Id: <9411170320.AA28419@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) high-speed slicing In-Reply-To: Your message of "Wed, 16 Nov 94 08:57:50 EST." <9411161411.AA25209@decvax.dec.com> Date: Wed, 16 Nov 94 22:20:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: yakov@watson.ibm.com Alex, >... but leave it open That creates a problem when trying to define a semantics of the information carried by the Hop-by-Hop Options header -- if we'd to leave open how the Hop-by-Hop Options header is handled in presence of encapsulation, we MUST change the current definition of the Hop-by-Hop Options header by saying that the information carried by this header MAY be processed by any node along a path -- the current document states that the information carried by the header MUST be examined by every node along a packet's delivery path. Yakov. Yakov, I agree with you that there is a need for clarification, relative to handling of encapsulation, and the meaning and handling of the original packets headers in such a case. My interpretation is that the original headers are in general not meaningful during the transit of an encapsulated packet through a tunnel. If they were, we introduced a Pandora box, and a concept that architecturally is not clean. If however some of the original headers have to reflect the transit of the packet through a tunnel, those headers have to be processed appropriately at the entry or exit point in the tunnel. Furthermore, I read the current specifications as saying that the hop-by-hop header of a packet MUST be processed by every node along the path of THAT packet. Encapsulating the packet, at an entry in a tunnel means to me creating a NEW packet, as far as the headers is concerned. The new headers may contain none, part, or entire original header information, depending on the tunnel properties - tunnels may have different purposes, from where different properties. Would you agree? 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 Nov 16 19:52:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18286; Wed, 16 Nov 94 19:52:04 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18280; Wed, 16 Nov 94 19:51:58 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA18104; Wed, 16 Nov 1994 19:46:18 -0800 From: conta@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA22340; Wed, 16 Nov 94 19:47:08 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22800; Wed, 16 Nov 1994 22:47:05 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA12403; Wed, 16 Nov 1994 22:47:04 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA28655; Wed, 16 Nov 1994 22:23:31 -0500 Message-Id: <9411170323.AA28655@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: Re: (IPng) high-speed slicing Date: Wed, 16 Nov 94 22:23:31 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Your message of "Wed, 16 Nov 94 09:15:34 EST." <9411161416.AA25441@decvax.dec.com> --------------------- From: yakov@watson.ibm.com Alex, >Encapsulator node choice 1: >encapsulating IPv6 header (src = X, dst = Y) >original IPv6 header (src = A, dst = B) >original Hop-by-Hop header >rest of the original packet. To illustrate why this would be a problem, I'll use a specific case. As you know, there is a proposal to accommodate "jumbograms" (packets larger than 64K) by placing 0 in the Length field of the fixed header, and placing the actual packet length in the Hop-by-Hop Options header. With your choice 1 this proposal wouldn't work, as a router on the path from X to Y would try to find the length of a packet in the Hop-by-Hop Options header, but will find instead just the original IPv6 header. .... Yakov. Yakov, The jumbogram example is a very good example of a hop-by-hop header which MUST be replicated in the encapsulation headers. The jumbogram length as the datagram length, is carried as a hop-by-hop header, and therefore the entry point in a tunnel, which builds the encapsulating header, MUST put the resulting length, in a new hop-by-hop header, which in a similar fashion, i.e. hop-by-hop header, will carry the resulting length which is the original length + size encapsulating headers. If the entry point in the tunnel didn't do that, certainly the encapsulating datagram length would be bogus. 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 Nov 16 20:04:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18306; Wed, 16 Nov 94 20:04:17 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18300; Wed, 16 Nov 94 20:04:06 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA18712; Wed, 16 Nov 1994 19:58:26 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA24373; Wed, 16 Nov 94 19:59:08 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id XAA01264 for ipng@sunroof.Eng.Sun.COM; Wed, 16 Nov 1994 23:00:45 -0500 (EST) Date: Wed, 16 Nov 1994 23:00:45 -0500 (EST) From: Scott Bradner Message-Id: <199411170400.XAA01264@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I agree with you that there is a need for clarification, relative to handling > of encapsulation, and the meaning and handling of the original packets > headers in such a case. > My interpretation is that the original headers are in general not meaningful > during the transit of an encapsulated packet through a tunnel. If they were, > we introduced a Pandora box, and a concept that architecturally is not clean. What about hop count of the encapsulated packet? Should this increment as the encapsulated packet goes through the tunnel? If not and the tunnel is there just because IPv6 routing is not supported along some part of the path, how does the sending node control scope? Does traceroute return the routers along the tunnel or just the entry & exit? 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 Wed Nov 16 20:25:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18344; Wed, 16 Nov 94 20:25:16 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18338; Wed, 16 Nov 94 20:25:09 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA20350; Wed, 16 Nov 1994 20:19:29 -0800 From: conta@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA27362; Wed, 16 Nov 94 20:20:19 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA23638; Wed, 16 Nov 1994 23:20:15 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA12914; Wed, 16 Nov 1994 23:20:12 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA28735; Wed, 16 Nov 1994 22:56:39 -0500 Message-Id: <9411170356.AA28735@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: danmcd@sundance.itd.nrl.navy.mil, conta@zk3.dec.com Subject: Re: (IPng) re: a few IPv6 API draft related comments In-Reply-To: Your message of "Wed, 16 Nov 94 16:20:57 EST." <9411162120.aa02313@sundance.itd.nrl.navy.mil> Date: Wed, 16 Nov 94 22:56:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Dan McDonald (Regarding the selection of outbound interface w.r.t. multicast...) Using the interface that corresponds to the address of a bind(2) is a good idea. But Alex, didn't you say that if there was no bound address, a multicast packet should go out ALL interfaces? If so, IMHO that's a bad idea. Never mind what a hassle that is for the internals, but sending multicast packets out all multicast-capable interfaces could cause excessive network traffic, no? Wouldn't it also confuse multicast routing? (Steve D., help me here!) When a socket is bound to address 0 - INADDR_ANY - it receives packets from all interfaces that the host has - as opposed to when it is bound to a certain address and receives only packets destined to that address. In a way, similarly, and on the sending side, when the socket's binding address has the meaning of communicating with hosts that reach this host through all its interfaces, i.e. address 0, when the destination address defines a group of hosts, which spans multiple interfaces, I see it necessary to forward the packet on all those interfaces that have the destination multicast group enabled - I see this qualifying quite important, so my "all" is meant "all interfaces that are member of the destination multicast group". As far as the internals, is it too complex? If your access to the data link is asynchronous, when the transmit on the first interface completes, and control is given back to you (IPv6 layer), you requeue the packet on the next interface, and so on in a loop on all appropriate interfaces. If your access to the data link is synchronous, on return from the data link, you call data link (the appropriate driver) with the next interface, and so on in a loop on all appropriate interfaces. If not, then what would be the correct interface? I like the idea of a default route, or a route for all ff00::0 packets, which is what my code does right now when an interface has not been chosen explicitly. Dan Does the multicast packet get to all members of the destination group this way? If it doesn't you have a problem. 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 Nov 16 20:58:58 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18360; Wed, 16 Nov 94 20:58:58 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18354; Wed, 16 Nov 94 20:58:51 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA22092; Wed, 16 Nov 1994 20:53:13 -0800 From: conta@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA00923; Wed, 16 Nov 94 20:53:56 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA24868; Wed, 16 Nov 1994 23:53:53 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA13431; Wed, 16 Nov 1994 23:53:42 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA28765; Wed, 16 Nov 1994 23:30:08 -0500 Message-Id: <9411170430.AA28765@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com, sob@newdev.harvard.edu Subject: Re: (IPng) high-speed slicing In-Reply-To: Your message of "Wed, 16 Nov 94 23:00:45 EST." <199411170400.XAA01264@newdev.harvard.edu> Date: Wed, 16 Nov 94 23:30:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Scott Bradner > I agree with you that there is a need for clarification, relative to > handling > of encapsulation, and the meaning and handling of the original packets > headers in such a case. > My interpretation is that the original headers are in general not > meaningful > during the transit of an encapsulated packet through a tunnel. If they were > we introduced a Pandora box, and a concept that architecturally is not > clean. What about hop count of the encapsulated packet? Should this increment as the encapsulated packet goes through the tunnel? If not and the tunnel is there just because IPv6 routing is not supported along some part of the path, how does the sending node control scope? Does traceroute return the routers along the tunnel or just the entry & exit? Scott As I stated before, what and how various headers and headers fields of an original packet are handled during tunneling, depends in my opinion on the headers, headers fields, and last but not least the tunnel's purposes and properties. In fact, when the original headers are relevant in the tunnel, or for the transit in the tunnel, for architectural corectness, if I may say, it seems clear that we have three choices, that can be used solely, or combined: 1. replicate original headers in the encapsulating headers. 2. alter at the entry in the tunnel the original headers to reflect the transit through the tunnel 3. alter at the exit from the tunnel the original headers to reflect the transit through the tunnel As you can see, to reach over the encapsulating headers into the original headers when the packet is in transit inside the tunnel, is architecturally a bad or a NO choice. In case of IPv6 encapsulation in IPv4 packets, it seems reasonable to reflect the transit (in respect to hop count) of the IPv6 packet through an IPv4 tunnel, and also have traceroute indicate the IPv4 routers in the tunnel. These because in this case, the IPv4 tunnel is a mechanism that replaces a future but unextant yet IPv6 backbone. But I can think of tunnels, in which the hop count would be intentionally left intact. For instance a tunnel that would help avoid the 255 hop limit imposed by the IPv6 header, or a tunnel that would help increase packets' scope, without intervention at the source hosts. 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 Nov 16 21:19:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18377; Wed, 16 Nov 94 21:19:46 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18371; Wed, 16 Nov 94 21:19:35 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA22779; Wed, 16 Nov 1994 21:13:57 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA02909; Wed, 16 Nov 94 21:14:43 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id AAA01487; Thu, 17 Nov 1994 00:12:29 -0500 (EST) Date: Thu, 17 Nov 1994 00:12:29 -0500 (EST) From: Scott Bradner Message-Id: <199411170512.AAA01487@newdev.harvard.edu> To: conta@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing Cc: sob@newdev.harvard.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > As I stated before, what and how various headers and headers fields of an > original packet are handled during tunneling, depends in my opinion on > the headers, headers fields, and last but not least the tunnel's purposes > and properties. I'm much more concerned that the procedures be defined an not left to the whim of the implementer. 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 Wed Nov 16 23:54:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18475; Wed, 16 Nov 94 23:54:46 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18469; Wed, 16 Nov 94 23:54:39 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA27170; Wed, 16 Nov 1994 23:49:00 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA15281; Wed, 16 Nov 94 23:49:50 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA02520; Thu, 17 Nov 1994 18:49:38 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA02628; Thu, 17 Nov 94 19:47:08 +1100 Message-Id: <9411170847.AA02628@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Thu, 17 Nov 94 18:50:18 AUS Date: Thu, 17 Nov 94 17:45:06 AUS From: Alan.Lloyd@datacraft.com.au Subject: (IPng) Authentication and Mobiles To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Authentication: The other day I questioned if Authentication was end to end or per router. Any offers on this. ie. if it is end to end, the network does not handle authentication and the auth field could go in ESP. It is in the router, the router can then authenticate the originator, BUT the router / subnets/ domains will require some model of security domains and management. Mobiles: My original comments were that a separate allocation of an IP6 address block should be assigned to mobile. This will enable the creation of Mobile Cells and that mobile IP users are allocated a mobile IP6 address. A model similar to the PSTN mobile system. Rationale: well the care of address and Foriegn / Home agent model IMHO does not seem to scale well. Take a few million mobile users wandering randomly across the world accessing a few thousand providors. The big issues become the host based network traffic redirection and "care of address" addresses that have to be allocated to all the foriegn agents. Above these issues though are the main points of relibility, security and accounting. Reliability: If a home base is disconnected, the mobiles for that home base are dead. Security: the only system that has knowledge of the mobile is the home base. and the foriegn agent relies on the home to verify the mobiles authenticity. Say one plugs a mobile into a foriegn LAN and the mobile itself answers the foreign agent as the home base (it masquerades). ie. No third party authentication. The mobile can then use the resources of the foreign agent's network at its leasure. Accounting: I am making the assumption that the new internet will be "commercially oriented" and that network charges could be levied. In the case of the "care of address" model they are levied on the care of address or the home base that if it is on line. With the mobile address model, the charges are levied on that mobile number. Without a lenthy expose on the mobile issues. The current model is ok for IP network level mobility and does have minimal management issues. On the other hand the model being simple is not very robust or scales well or oriented to secure, and commercial mobile communications. Therefore the model selection is really dependent on the service requirements needed. ie Mobile Connectivity or Mobile Service. The more complex model naturally requires more "cell" based functions and management. Eg. the Cells will need databases of mobile addresses and user authentication data. They will also have to maintain and communicate resource utilisation statistics (even tie into a bank or credit union) and manage calls/ registrations. In closing, are my expectations of the mobile IP users too high (re accounting, security and robustness). Or is the current model accepted with these perceived limitations. 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 Nov 17 01:44:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18537; Thu, 17 Nov 94 01:44:01 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18531; Thu, 17 Nov 94 01:43:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id BAA29858; Thu, 17 Nov 1994 01:38:14 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA28834; Thu, 17 Nov 94 01:39:01 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) re: a few IPv6 API draft related comments To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 09:39:23 +0100 (GMT) In-Reply-To: <9411161925.AA03085@kandinsky.Eng.Sun.COM> from "Bob Gilligan" at Nov 16, 94 11:25:36 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > destination; and the first address in the buffer returned by > recvfrom() is *always* that of the originating node. I think this > ordering will be more intuitive for the application writers. This is also right as you can specify a small return buffer when you don't want the rest of the junk returned just who is [probably] at the other end. > > > 3.1 IP_MULTICAST_IF > > I am not sure whether it is necessary. . . . > Good question. I'd like to hear from people who have used the IPv4 > multicast API to see they think that selection of the source interface > could be better done via the bound address of the socket. Bind seems much more logical, I just have this terrible feeling that IP_MULTICAST_IF was probably added for a good reason.. 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 Nov 17 02:56:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18622; Thu, 17 Nov 94 02:56:10 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18616; Thu, 17 Nov 94 02:56:03 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA01471; Thu, 17 Nov 1994 02:50:24 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA05707; Thu, 17 Nov 94 02:51:10 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Re: a few IPv6 API draft related comments To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 10:51:40 +0100 (GMT) In-Reply-To: <9411162345.AA28335@brigit.zk3.dec.com> from "conta@zk3.dec.com" at Nov 16, 94 06:45:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In fact this is what I mean - to use by defualt *one* form. > > I believe right now the specs use two different forms: > > 'send',... - direct order > 'recv',... - reverse order > > What I am suggesting, is to have > > 'send',... - direct order > 'recv',... - direct order The reverse order is more useful as you can pass the options back. I'd argue it from a different standpoint. The initial suggestion is consistent in that everything is a path list from the viewpoint of that one host. In your case the view is as the sending end saw it. > > I can think of at least several uses of such a routine - printing debugging > information is just one - and it would save the time for users to write one, > if the standard implementation would have one, just as other many routines > for handling addresses. I do not have a strong opinion in this sense, although > I may suggest such a routine for implementations that I can influence. Certainly things like ipv6_ntoa() and the related functions must exist and in a defined form as part of the API (but not of course part of the kernel!) If this knows how to print full paths all the best. 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 Nov 17 03:13:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18638; Thu, 17 Nov 94 03:13:08 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18632; Thu, 17 Nov 94 03:13:01 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id DAA01726; Thu, 17 Nov 1994 03:07:21 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA10819; Thu, 17 Nov 94 03:07:11 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) high-speed slicing To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 11:07:40 +0100 (GMT) In-Reply-To: <199411170400.XAA01264@newdev.harvard.edu> from "Scott Bradner" at Nov 16, 94 11:00:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > What about hop count of the encapsulated packet? Should this increment as > the encapsulated packet goes through the tunnel? If not and the tunnel > is there just because IPv6 routing is not supported along some part of > the path, how does the sending node control scope? Does traceroute > return the routers along the tunnel or just the entry & exit? It has to increment somewhere to ensure its incremented once per second anyway to preserve the MSL of the internet for TCP (at least unless RFC1323 is made mandatory for TCP over IPv6) 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 Nov 17 03:46:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18660; Thu, 17 Nov 94 03:46:08 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18651; Thu, 17 Nov 94 03:45:58 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id DAA02192; Thu, 17 Nov 1994 03:40:18 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA12910; Thu, 17 Nov 94 03:41:06 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Authentication and Mobiles To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 11:41:35 +0100 (GMT) In-Reply-To: <9411170847.AA02628@cms.datacraft.com.au> from "Alan.Lloyd@datacraft.com.au" at Nov 17, 94 05:45:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Rationale: well the care of address and Foriegn / Home agent model IMHO does > not seem to scale well. Take a few million mobile users wandering randomly > across the world accessing a few thousand providors. The big issues become > the host based network traffic redirection and "care of address" addresses > that have to be allocated to all the foriegn agents. I would expect the providers in question to be in tens to hundreds of thousands. Everything for corporate blocks to small companies with an NCR wavelan style card each that they allow employees access to. > Accounting: I am making the assumption that the new internet will be > "commercially oriented" and that network charges could be levied. Certainly for some providers. However the big commercial people are probably not going to be using IPv6 mobile but their own below IPv6 layers so IPv6 will see a permanent connection - thats already happened with existing mobile data services. A sensible charging strategy is going to be important. Currently it looks like bandwidth will cease to be an issue on fixed links unless people find some pretty obnoxious things to run whereas the mobile arena is cramped for bandwidth, having some of it eaten away by health and safety changes and with no new area to expand into. 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 Nov 17 04:18:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18681; Thu, 17 Nov 94 04:18:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18675; Thu, 17 Nov 94 04:18:25 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA02792; Thu, 17 Nov 1994 04:12:45 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA14602; Thu, 17 Nov 94 04:13:37 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id HAA01966 for ipng@sunroof.Eng.Sun.COM; Thu, 17 Nov 1994 07:15:14 -0500 (EST) Date: Thu, 17 Nov 1994 07:15:14 -0500 (EST) From: Scott Bradner Message-Id: <199411171215.HAA01966@newdev.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) high-speed slicing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Alan, In IPng the 'hop count' is just a hop count and specifically is not also a time clock. 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 Nov 17 04:55:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18709; Thu, 17 Nov 94 04:55:54 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18703; Thu, 17 Nov 94 04:55:47 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA03636; Thu, 17 Nov 1994 04:50:06 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA17703; Thu, 17 Nov 94 04:50:51 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) high-speed slicing To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 12:51:20 +0100 (GMT) In-Reply-To: <199411171215.HAA01966@newdev.harvard.edu> from "Scott Bradner" at Nov 17, 94 07:15:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In IPng the 'hop count' is just a hop count and specifically > is not also a time clock. So RFC1323 and its successors are now mandatory for TCP or do we just get corrupt data when the packet life time is exceeded ? 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 Nov 17 05:28:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18734; Thu, 17 Nov 94 05:28:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18728; Thu, 17 Nov 94 05:28:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA04285; Thu, 17 Nov 1994 05:22:37 -0800 From: yakov@watson.ibm.com Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA20460; Thu, 17 Nov 94 05:23:28 PST Message-Id: <9411171323.AA20460@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3321; Thu, 17 Nov 94 08:23:34 EST Date: Thu, 17 Nov 94 08:22:07 EST To: ipng@sunroof.Eng.Sun.COM Cc: conta@zk3.dec.com Subject: (IPng) high-speed slicing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Ref: Your note of Wed, 16 Nov 94 22:20:37 -0500 Alex, >Furthermore, I read the current specifications as saying that the >hop-by-hop header of a packet MUST be processed by every node along the >path of THAT packet. > >Encapsulating the packet, at an entry in a tunnel means to me >creating a NEW packet, as far as the headers is concerned. >The new headers may contain none, part, or entire original >header information, depending on the tunnel properties -- tunnels >may have different purposes, from where different properties. >Would you agree ? No. I disagree. To me the argument about whether after the encapsulation we have the OLD or the NEW packet is of somewhat peripheral importance. What I think is important is that the semantics carried by certain fields of the packet has to be preserved. The example with the "jumbograms" shows that if the semantics (in this case the semantics carried by the Hop-by-hop Options header) isn't preserved, then we may end up with an undesirable consequences. If preserving the information in presence of tunneling is left as a "local choice", then the the entity that puts this information in the first place can't determine how this information will be processed. As such, "local choice" could lead to unpredictable results. So, in my mind for every piece of information carried by IPv6 there should be a statement about how this information should be handled in presence of tunnels. For example, there should be a statement that describes how to handle the Hop Count field (perhaps you should copy it in the outer header at the entrance to the tunnel and copy it out from the outer header to the original header at the tunnel's exit). There should be a statement that describes how to handle Hop-by-Hop Options header (perhaps it should be copied entirely). Etc.... Yakov. ------------------------------------------------------------------------------ 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 Nov 17 05:50:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18782; Thu, 17 Nov 94 05:50:05 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18776; Thu, 17 Nov 94 05:49:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA04803; Thu, 17 Nov 1994 05:44:15 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AB22469; Thu, 17 Nov 94 05:45:05 PST Received: by rodan.UU.NET id QQxqkk06799; Thu, 17 Nov 1994 08:44:52 -0500 From: stripes@uunet.uu.net (Josh Osborne) Message-Id: Subject: Re: (IPng) IPv6 address representation To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 08:44:52 -0500 (EST) In-Reply-To: <13914.785036385@munnari.OZ.AU> from "Robert Elz" at Nov 17, 94 12:39:45 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] > = is bad > too many OS's use things like > NAMESERVER=1.2.3.4 > >doesn't worry me, > > NAMESERVER==1.2.3.4 > >is not ambiguous, just a little odd, and can be written > > NAMESERVER=0=1.2.3.4 or we could use ".." rather then "=". ------------------------------------------------------------------------------ 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 Nov 17 06:11:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18815; Thu, 17 Nov 94 06:11:55 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18809; Thu, 17 Nov 94 06:11:48 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA05321; Thu, 17 Nov 1994 06:06:08 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA25132; Thu, 17 Nov 94 06:06:42 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) IPv6 address representation To: ipng@sunroof.Eng.Sun.COM Date: Thu, 17 Nov 1994 14:06:29 +0100 (GMT) In-Reply-To: from "Josh Osborne" at Nov 17, 94 08:44:52 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > NAMESERVER=0=1.2.3.4 > > or we could use ".." rather then "=". This is what I suggested and its in keeping with the use of things like ... in English 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 Nov 17 06:26:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18855; Thu, 17 Nov 94 06:26:29 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18849; Thu, 17 Nov 94 06:26:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA05797; Thu, 17 Nov 1994 06:20:43 -0800 Received: from nbkanata.Newbridge.COM by Sun.COM (sun-barr.Sun.COM) id AA27039; Thu, 17 Nov 94 06:21:23 PST Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA14843; Thu, 17 Nov 94 09:16:00 EST Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA15435; Thu, 17 Nov 94 09:15:59 EST Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA08910; Thu, 17 Nov 94 09:21:45 EST Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA10472; Thu, 17 Nov 1994 09:21:44 +0500 Date: Thu, 17 Nov 1994 09:21:44 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9411171421.AA10472@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) manual configuration X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I wonder if you could comment one something for me. The RIP working group chair has asked to be chartered to work on RIP for IPv6. My own view is that we do not need that. We need a good, working, router discovery so that hosts stop using RIP. In response, Gary suggested that RIP was much better than OSPF for networks with large numbers of dialin. Do you have any experience with that? Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. Routing AD ------------------------------------------------------------------------------ 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 Nov 17 07:16:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18889; Thu, 17 Nov 94 07:16:40 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18883; Thu, 17 Nov 94 07:16:32 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA07584; Thu, 17 Nov 1994 07:10:52 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA03638; Thu, 17 Nov 94 07:11:42 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14580(2)>; Thu, 17 Nov 1994 07:11:23 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Thu, 17 Nov 1994 07:11:04 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: iialan@iifeak.swan.ac.uk (Alan Cox), deering@parc.xerox.com Subject: Re: (IPng) high-speed slicing In-Reply-To: iialan's message of Thu, 17 Nov 94 03:51:20 -0800. Date: Thu, 17 Nov 1994 07:10:52 PST From: Steve Deering Message-Id: <94Nov17.071104pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sorry for not contributing to the discussions on encapsulation this week; I'm out of my office all this week and barely have enough email time to read everything -- I'll try to catch up on the weekend. Alan Cox wrote: > So RFC1323 and its successors are now mandatory for TCP or do we just get > corrupt data when the packet life time is exceeded ? Here's what the IPv6 spec says about that: 7.2 Maximum Packet Lifetime Unlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime. (That's why the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6.) In practice, very few, if any, IPv4 implementations conform to the requirement that they limit packet lifetime, so this is not really a change in practice. Any transport protocol that relies on the internet layer (whether IPv4 or IPv6) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets. 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 Thu Nov 17 07:27:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18918; Thu, 17 Nov 94 07:27:15 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18912; Thu, 17 Nov 94 07:27:08 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA08170; Thu, 17 Nov 1994 07:21:28 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA05337; Thu, 17 Nov 94 07:22:16 PST Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA19236; Thu, 17 Nov 1994 16:25:16 +0100 Message-Id: <199411171525.AA19236@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) manual configuration In-Reply-To: Your message of "Thu, 17 Nov 1994 09:21:44 +0500." <9411171421.AA10472@lobster.Newbridge.COM> Date: Thu, 17 Nov 1994 16:25:15 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joel, 1) We certainly do *not* need RIP for IPv6 routes' discovery. In fact, we should not need that for IPv4 route discovery either. 2) There is certainly a large fraction of netters, amongst which JJ Garcia-Luna and cisco are prominent, who believe that DV is actually a smarter technology than LS. The idea of doing a DVng protocol is not entirely stupid. 3) However, DVng does not mean RIP. It may well be that the correct answer at this stage is to let Gary do an experiment, and look at the result. If there is then a constituency for standardizing it, normal WG creation process should be applied. 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 Thu Nov 17 07:41:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18934; Thu, 17 Nov 94 07:41:24 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18928; Thu, 17 Nov 94 07:41:18 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA08998; Thu, 17 Nov 1994 07:35:38 -0800 Received: from nbkanata.Newbridge.COM by Sun.COM (sun-barr.Sun.COM) id AA07762; Thu, 17 Nov 94 07:36:18 PST Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA16371; Thu, 17 Nov 94 10:30:52 EST Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA19258; Thu, 17 Nov 94 10:30:45 EST Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA09456; Thu, 17 Nov 94 10:36:31 EST Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA10564; Thu, 17 Nov 1994 10:36:31 +0500 Date: Thu, 17 Nov 1994 10:36:31 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9411171536.AA10564@lobster.Newbridge.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) manual configuration X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM That might be a reasonable approach. However, Cisco has been very unwilling to submit their IGRP stuff (including their newer work) to the IETF process. Thanks for the suggestion, Joel ------------------------------------------------------------------------------ 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 Nov 17 09:59:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19029; Thu, 17 Nov 94 09:59:10 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19023; Thu, 17 Nov 94 09:59:03 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA19420; Thu, 17 Nov 1994 09:53:22 -0800 Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AA03928; Thu, 17 Nov 94 09:54:03 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA13381; Thu, 17 Nov 94 09:53:54 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA15313; Thu, 17 Nov 1994 09:52:41 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id JAA04529; Thu, 17 Nov 1994 09:53:54 -0800 Date: Thu, 17 Nov 1994 09:53:54 -0800 From: "Justin C. Walker" Message-Id: <199411171753.JAA04529@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: Bob.Gilligan@Eng, ipng@sunroof.Eng.Sun.COM, conta@zk3.dec.com In-Reply-To: conta@zk3.dec.com's message of Wed, 16 Nov 94 18:45:36 -0500 <9411162345.AA28335@brigit.zk3.dec.com> Subject: (IPng) Re: a few IPv6 API draft related comments Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> I believe right now the specs use two different forms: >> >> 'send',... - direct order >> 'recv',... - reverse order >> >> What I am suggesting, is to have >> >> 'send',... - direct order >> 'recv',... - direct order >> >> This implies though that to use the output of 'recv' to a subsequent 'send', >> the array must be put in reverse order. Adding my $0.02 to the pot, my preference is to see what was in the original packet. If I can bank on that, writing code for multiple platforms becomes easier (I don't have to figure out what the library implementer had in mind for intuitive order). Regards, Justin Justin C. Walker, Curmudgeon-At-Large *When the Texas legislature learned that Institute for General Semantics |deaths from handguns had passed those from Apple Business Systems |highway traffic accidents, they responded Apple Computer, Inc. |immediately to redress the balance: they 10500 North De Anza Blvd |raised the speed limit. Cupertino, CA 95014 | Molly Ivins *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ 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 Nov 17 10:18:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19065; Thu, 17 Nov 94 10:18:46 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14471; Mon, 14 Nov 94 08:44:49 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA12621; Mon, 14 Nov 94 08:40:29 PST Received: from mailer.psc.edu by Sun.COM (sun-barr.Sun.COM) id AA08574; Mon, 14 Nov 94 08:40:03 PST Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA01392; Mon, 14 Nov 1994 11:39:54 -0500 Message-Id: <9411141639.AA01392@mailer.psc.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation Date: Mon, 14 Nov 1994 11:39:52 -0500 From: "Matt Mathis" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I think we overlooked something..... IPv4's use of "." as a common sub-field separator within both names and addresses permitted certain simplifications in application parsers. While clearly most applications don't use this, it sort of scares me that the WWW problem was noticed so late. How many other are lurking? --MM-- ------------------------------------------------------------------------------ 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 Nov 17 12:09:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19199; Thu, 17 Nov 94 12:09:05 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19193; Thu, 17 Nov 94 12:08:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA06549; Thu, 17 Nov 1994 12:03:13 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA05675; Thu, 17 Nov 94 12:03:51 PST Received: from relay.imsi.com by wintermute.imsi.com id OAA00524 for ; Thu, 17 Nov 1994 14:59:43 -0500 Received: from snark.imsi.com by relay.imsi.com id OAA09086 for ; Thu, 17 Nov 1994 14:59:42 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA08876; Thu, 17 Nov 94 14:59:42 EST Message-Id: <9411171959.AA08876@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation In-Reply-To: Your message of "Mon, 14 Nov 1994 11:39:52 EST." <9411141639.AA01392@mailer.psc.edu> X-Reposting-Policy: redistribute only with permission Date: Thu, 17 Nov 1994 14:59:41 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM "Matt Mathis" says: > I think we overlooked something..... > > IPv4's use of "." as a common sub-field separator within both names and > addresses permitted certain simplifications in application parsers. While > clearly most applications don't use this, it sort of scares me that the WWW > problem was noticed so late. How many other are lurking? Sending mail to IP addresses might very well break; : characters are not valid in that field in RFC82[12] syntax. 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 Thu Nov 17 12:30:24 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19212; Thu, 17 Nov 94 12:30:24 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19206; Thu, 17 Nov 94 12:30:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA08890; Thu, 17 Nov 1994 12:24:36 -0800 Received: from mailhost.wco.ftp.com ([128.127.203.200]) by Sun.COM (sun-barr.Sun.COM) id AA10650; Thu, 17 Nov 94 12:24:13 PST Date: Thu, 17 Nov 94 12:18:13 PST Message-Id: <9411172018.AA05512@mailhost.wco.ftp.com> Received: from zoi (zoi.wco.ftp.com) by mailhost.wco.ftp.com; Thu, 17 Nov 94 12:18:14 PST X-Sender: veizades@128.127.203.200 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.Eng.Sun.COM From: veizades@ftp.com (John Veizades) Subject: (IPng) Service Location and Discovery for IPnG Cc: srv-location@ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have submitted the current document which describes service location into the internet drafts directory as "draft-veizades-ipng-srvloc-00.txt". This document describes a protocol for the discovery of services on a WAN. It is based on a datagram exchange protocol. The version described is for use over an IPv6 UDP. This protocol is also designed for use over other datagram protocols like IPv4 UDP and AppleTalk's DDP. This protocol will be discussed at the service location working group meeting (Tuesday 1330-1530). The abstact of this protocol follows. John Veizades... Service Location Working Group Chair -------------------------- The service location protocol provides a framework for the discovery and selection of network services. It relies on multicast support at the network layer of the protocol stack it is using. It does not specifically rely upon the TCP/IP protocol stack but makes use of concepts that are found in most TCP/IP protocol implementations. Traditionally, users find services using the name of a network host (a human readable text string) which is an alias for a network address. The service location protocol eliminates the need for a user to know the name of a network host supporting a service. Rather, the user supplies a set of attributes which describe the service. The service location protocol allows the user to bind this description to the network address of the service. ------------------------------------------------------------------------------ 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 Nov 17 13:43:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19278; Thu, 17 Nov 94 13:43:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19272; Thu, 17 Nov 94 13:43:46 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA14598; Thu, 17 Nov 1994 13:38:04 -0800 Received: from ftp.com ([128.127.2.122]) by Sun.COM (sun-barr.Sun.COM) id AA27399; Thu, 17 Nov 94 13:35:58 PST Received: from ftp.com by ftp.com ; Thu, 17 Nov 1994 11:58:44 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 17 Nov 1994 11:58:44 -0500 Received: from solensky.mccoy.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA18472; Thu, 17 Nov 94 11:58:17 EST Date: Thu, 17 Nov 94 11:58:17 EST Message-Id: <9411171658.AA18472@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Thu Nov 17 11:58:09 1994] Originating-Client: mccoy.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Sorry if this reappears later but the one from last night hasn't shown up yet.. Use of the double '=' is acceptable to many Unix interfaces (sh, csh, ksh and bash all accepted NAMESERVER==ffff-123.45.67.89 without any problem: the value of the first byte was '='. DOS wasn't too cooperative on my few attempts, but I'd expect that it wouldn't be specified in an environment variable very frequently anyway -- it'd usually be inside a configuration file instead. GUI's also shouldn't be a problem since most are going to have the user specify only the value and not the field identification. > From: iialan@iifeak.swan.ac.uk (Alan Cox) > > > > NAMESERVER=0=1.2.3.4 > > > > or we could use ".." rather then "=". > > This is what I suggested and its in keeping with the use of > things like ... in English But the goal of going to either ':' or '-' was so that periods always identify that portion of the address as being in dotted decimal notation rather than hex digits. And the idea of going to hex was to avoid having to do the mental decimal<->binary conversions when fields or masks aren't byte-aligned. -- Frank ------------------------------------------------------------------------------ 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 Nov 17 14:13:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19329; Thu, 17 Nov 94 14:13:38 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19323; Thu, 17 Nov 94 14:13:26 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA17727; Thu, 17 Nov 1994 14:07:44 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA05818; Thu, 17 Nov 94 14:08:01 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.9/merit-2.0) with SMTP id RAA01582 for ; Thu, 17 Nov 1994 17:07:24 -0500 Date: Thu, 17 Nov 94 21:55:06 GMT From: "William Allen Simpson" Message-Id: <3473.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) RIP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: jhalpern@Newbridge.COM (Joel Halpern) > The RIP working group chair has asked to be chartered to work on RIP for > IPv6. My own view is that we do not need that. We need a good, working, > router discovery so that hosts stop using RIP. > Well, we _have_ a good, working, router discovery. RIP is not for router discovery. RIP is for exchanging routing information. > In response, Gary suggested that RIP was much better than OSPF for > networks with large numbers of dialin. Do you have any experience > with that? > Or even _small_ numbers of dial-in. Meyer's demand RIP works fine, in my estimation, and standardizes something that all the small router vendors had been doing with proprietary techniques. We had a SIPP-RIP. The work should go forward. But, I really don't like RIP itself. It doesn't do anything that LS won't do better. I'd like a nicely specified LS for IPv6 mobility and multipath. Why don't you convene the OSPF WG, and get them to do demand dialing and mobility along with IPv6? 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 Nov 17 14:55:30 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19381; Thu, 17 Nov 94 14:55:30 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19375; Thu, 17 Nov 94 14:55:19 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA21741; Thu, 17 Nov 1994 14:49:37 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA16477; Thu, 17 Nov 94 14:49:25 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11464; 17 Nov 94 16:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof2.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-atkinson-ipng-auth-00.txt Date: Thu, 17 Nov 94 16:20:50 -0500 Message-Id: <9411171620.aa11464@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 Authentication Header Author(s) : R. Atkinson Filename : draft-atkinson-ipng-auth-00.txt Pages : 10 Date : 11/16/1994 The Internet community is working on a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). This memo describes the IPv6 Authentication Header. This optional header provides strong integrity and authentication for IPv6 datagrams. Non-repudiation might be provided by an authentication algorithm used with the Authentication Header, but it is not provided with all authentication algorithms that might be used. Confidentiality, and protection from traffic analysis are not provided by the Authentication Header. Users desiring confidentiality should consider using the IPv6 Encapsulating Security Protocol (ESP) either in lieu of or in conjunction with the Authentication Header. [NB: All references to "IPv6 Encapsulating Security Protocol" will be replaced with references to the "IPv6 Security Protocol (IPSP)" if/when such a document appears as an online Internet Draft]. This document assumes the reader has previously read and understood the related "IPv6 Security Overview" document which defines the overall security architecture for IPv6 and provides important background information for this specification. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-atkinson-ipng-auth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-auth-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-auth-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: <19941116154904.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-atkinson-ipng-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-atkinson-ipng-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941116154904.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 Thu Nov 17 15:35:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19424; Thu, 17 Nov 94 15:35:34 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19418; Thu, 17 Nov 94 15:35:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA25097; Thu, 17 Nov 1994 15:29:40 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA25711; Thu, 17 Nov 94 15:28:12 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11509; 17 Nov 94 16:21 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof2.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-atkinson-ipng-sec-00.txt Date: Thu, 17 Nov 94 16:21:50 -0500 Message-Id: <9411171621.aa11509@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 Security Architecture Author(s) : R. Atkinson Filename : draft-atkinson-ipng-sec-00.txt Pages : 13 Date : 11/16/1994 The Internet community is making a transition from version 4 of the Internet Protocol (IPv4) to version 6 of the Internet Protocol (IPv6). [Hi94] This memo describes the security mechanisms integrated into version 6 of the Internet Protocol (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. It also describes how security mechanisms outside the scope of the IPng effort (e.g. key management) relate to the IPv6 security mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-atkinson-ipng-sec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-sec-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-sec-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: <19941116160000.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-atkinson-ipng-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-atkinson-ipng-sec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941116160000.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 Thu Nov 17 15:39:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19452; Thu, 17 Nov 94 15:39:40 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19344; Thu, 17 Nov 94 14:43:39 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA20634; Thu, 17 Nov 1994 14:37:56 -0800 Received: from ccc.casc.com ([152.148.254.254]) by Sun.COM (sun-barr.Sun.COM) id AA13009; Thu, 17 Nov 94 14:36:47 PST Received: from alpo.casc.com ([152.148.10.6]) by ccc.casc.com (4.1/3.1.012693-Cascade) Received: from apollo13.cascade by alpo.casc.com (4.1/SMI-4.1) id AA11559; Thu, 17 Nov 94 14:13:28 EST Received: by apollo13.cascade (5.0/SMI-SVR4) id AA01163; Thu, 17 Nov 1994 14:11:18 +0500 Date: Thu, 17 Nov 1994 14:11:18 +0500 From: jmoy@alpo.casc.com (John Moy) Message-Id: <9411171911.AA01163@apollo13.cascade> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9411171421.AA10472@lobster.Newbridge.COM> (jhalpern@Newbridge.COM) Subject: Re: (IPng) manual configuration Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joel- I don't think that there is anything inherent in dial-up links that makes RIP a more attractive protocol. 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 Thu Nov 17 16:19:14 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19524; Thu, 17 Nov 94 16:19:14 PST Received: from jurassic.Eng.Sun.COM (jurassic-52) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19518; Thu, 17 Nov 94 16:19:03 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id QAA06539; Thu, 17 Nov 1994 16:14:18 -0800 Date: Thu, 17 Nov 1994 16:14:18 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411180014.QAA06539@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9411171421.AA10472@lobster.Newbridge.COM> Subject: Re: (IPng) manual configuration Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Joel, > The RIP working group chair has asked to be chartered to work on RIP for > IPv6. My own view is that we do not need that. We need a good, working, > router discovery so that hosts stop using RIP. I think the RIP w.g. should do an IPv6 version. RIP represents a very low entry routing protocol that in a lot of environments works just fine. It has problems scaling to large internets, though I am aware of some very large corporate networks which use it exclusively. In small to medium size networks it works just fine. The other choices for routing protocols (OSPF, ISIS) tend to be more complex, harder to administer, and manage. In the right environments RIP is a nice choice. 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 Fri Nov 18 00:35:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19837; Fri, 18 Nov 94 00:35:48 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19831; Fri, 18 Nov 94 00:35:40 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id AAA22945; Fri, 18 Nov 1994 00:29:57 -0800 Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA17305; Fri, 18 Nov 94 00:30:49 PST Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA22281; Fri, 18 Nov 1994 09:33:50 +0100 Message-Id: <199411180833.AA22281@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation In-Reply-To: Your message of "Thu, 17 Nov 1994 14:59:41 EST." <9411171959.AA08876@snark.imsi.com> Date: Fri, 18 Nov 1994 09:33:48 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM There certainly is a case for only using those characters which are allowed by the rfc-821 syntax, i.e. letters, numbers, hyphens and dots. Staying within the limits of 821 means that we guarantee that text-formed IPv6 addresses may be used wherever a domain name or an IPv4 address was expected. The only proposal which means this requirement is to use the hyphen as separation between 4-nibbles groups and double dots for ellipsis. The problem then is to find a way to differentiate domain names, ipv4 addresses and ipv6 addresses. Use of at least one ellipsis is enough to differentiate ipv6 from either ipv4 or dns; use of at least one hyphen is enough to differentiate ipv4 from dns; if one single dot is present, then the string has to be either ipv4 or dns, cannot be ipv6; if at least one non hexadecimal character is present, then the string has to be dns, not ipv6 or ipv4. However, the string: a0b1-c0b2-1-df-2-ca8e-d345-1234 would be both a valid ipv6 address and a valid dns name (in local variant). Are we going to suggest that dns names cannot be just made of hexadecimal characters and exactly 7 hyphens? Indeed, the probability of using this form is scarce... Christian Huitema .PS Use of hyphens and dots would also fulfill a requirement put forward by Tony Li, that we should only use lower cased keyboard keys. ------------------------------------------------------------------------------ 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 Nov 18 01:44:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19878; Fri, 18 Nov 94 01:44:27 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19872; Fri, 18 Nov 94 01:44:19 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id BAA24510; Fri, 18 Nov 1994 01:38:36 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA23726; Fri, 18 Nov 94 01:39:27 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) manual configuration To: ipng@sunroof.Eng.Sun.COM Date: Fri, 18 Nov 1994 09:39:56 +0100 (GMT) In-Reply-To: <9411171911.AA01163@apollo13.cascade> from "John Moy" at Nov 17, 94 02:11:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I don't think that there is anything inherent in dial-up links that makes > RIP a more attractive protocol. RIP happens to be easy to spoof and to mostly work if you learn and freeze the configurations. This is good for dial on demand links as you can avoid dialing regularly for routing updates. The tables are also complete enough and the algorithms well understood for automatically dialing on a signficant change of routing. 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 Fri Nov 18 02:47:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19958; Fri, 18 Nov 94 02:47:56 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19952; Fri, 18 Nov 94 02:47:43 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA25606; Fri, 18 Nov 1994 02:41:59 -0800 Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA29521; Fri, 18 Nov 94 02:42:40 PST Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id ; Fri, 18 Nov 1994 10:42:22 +0000 Received: by widow.spider.co.uk; Fri, 18 Nov 94 10:42:43 GMT From: Gerry Meyer Date: Fri, 18 Nov 94 10:38:49 GMT Message-Id: <20838.9411181038@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Fri, 18 Nov 94 10:38:49 GMT To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) manual configuration Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Christian Huitema wrote: >1) We certainly do *not* need RIP for IPv6 routes' discovery. In fact, we >should not need that for IPv4 route discovery either. >2) There is certainly a large fraction of netters, amongst which JJ >Garcia-Luna and cisco are prominent, who believe that DV is actually a smarter>technology than LS. The idea of doing a DVng protocol is not entirely stupid. >3) However, DVng does not mean RIP. It may well be that the correct answer at >this stage is to let Gary do an experiment, and look at the result. If there >is then a constituency for standardizing it, normal WG creation process should>be applied. The 128 bit IP6 address size is the thunderbolt which allows RIP to be unshackled from its past. Let Gary do the experiment. Gerry ------------------------------------------------------------------------------ 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 Nov 18 02:52:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19970; Fri, 18 Nov 94 02:52:05 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19964; Fri, 18 Nov 94 02:51:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA25688; Fri, 18 Nov 1994 02:46:09 -0800 Received: from relay1.pipex.net by Sun.COM (sun-barr.Sun.COM) id AA29918; Fri, 18 Nov 94 02:47:01 PST Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id ; Fri, 18 Nov 1994 10:46:35 +0000 Received: by widow.spider.co.uk; Fri, 18 Nov 94 10:46:55 GMT From: Gerry Meyer Date: Fri, 18 Nov 94 10:43:01 GMT Message-Id: <20868.9411181043@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Fri, 18 Nov 94 10:43:01 GMT To: ipng@sunroof.Eng.Sun.COM, jmoy@alpo.casc.com Subject: Re: (IPng) manual configuration Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM jmoy@alpo.casc.com (John Moy) wrote: >I don't think that there is anything inherent in dial-up links that makes >RIP a more attractive protocol. Having said that, for me, there are still a few unresolved issues with your last Demand OSPF draft. It doesn't seem to me to cope with distinguishing temporary VC resource problems - perhaps caused by trying to send a routing update to more locations than there are VCs to go round - and genuine link down problems which one would want to propagate back to routers on the LAN-ward side. Gerry ------------------------------------------------------------------------------ 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 Nov 18 04:14:28 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20023; Fri, 18 Nov 94 04:14:28 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20017; Fri, 18 Nov 94 04:14:17 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA27100; Fri, 18 Nov 1994 04:08:35 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA00594; Thu, 17 Nov 94 15:47:53 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11558; 17 Nov 94 16:22 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof2.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-atkinson-ipng-esp-00.txt Date: Thu, 17 Nov 94 16:22:44 -0500 Message-Id: <9411171622.aa11558@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 Encapsulating Security Payload (ESP) Author(s) : R. Atkinson Filename : draft-atkinson-ipng-esp-00.txt Pages : 12 Date : 11/16/1994 This memo describes the IPv6 Encapsulating Security Payload (ESP). ESP seeks to provide integrity and confidentiality to IPv6 datagrams. It may also provide authentication, depending on which algorithm and algorithm mode are used. Non-repudiation and protection from traffic analysis are not provided by ESP. The IPv6 Authentication Header (AH) might provide non-repudiation if used with certain authentication algorithms. The IPv6 Authentication Header may be used in conjunction with ESP to provide authentication. Users desiring integrity and authentication without confidentiality should use the IPv6 Authentication Header (AH) instead of ESP. This document assumes that the reader is familiar with the related document "IPv6 Security Architecture", which defines the overall security architecture for IPv6 and provides important background for this specification. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-atkinson-ipng-esp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-atkinson-ipng-esp-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-atkinson-ipng-esp-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: <19941116155604.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-atkinson-ipng-esp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-atkinson-ipng-esp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941116155604.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 Fri Nov 18 04:50:04 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20044; Fri, 18 Nov 94 04:50:04 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20038; Fri, 18 Nov 94 04:49:56 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA27615; Fri, 18 Nov 1994 04:44:13 -0800 Received: from atlas.xylogics.com by Sun.COM (sun-barr.Sun.COM) id AA12590; Fri, 18 Nov 94 04:44:56 PST Received: by atlas.xylogics.com id AA14870 (5.65c/UK-2.1-940401); Fri, 18 Nov 1994 07:47:09 -0500 From: Gary Scott Malkin Date: Fri, 18 Nov 1994 07:47:09 -0500 Message-Id: <14870.199411181247@atlas.xylogics.com> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: Alan Cox's message of Fri, 18 Nov 1994 09:39:56 +0100 (GMT) Subject: (IPng) manual configuration Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > RIP happens to be easy to spoof ... Not RIP-2 with Fred Baker's MD5 cryptography proposal. We would, of course, apply that same proposal to RIPng. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two! ------------------------------------------------------------------------------ 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 Nov 18 06:08:34 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20081; Fri, 18 Nov 94 06:08:34 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20075; Fri, 18 Nov 94 06:08:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA29516; Fri, 18 Nov 1994 06:02:39 -0800 Received: from ccc.casc.com ([152.148.254.254]) by Sun.COM (sun-barr.Sun.COM) id AA19944; Fri, 18 Nov 94 06:03:32 PST Received: from alpo.casc.com ([152.148.10.6]) by ccc.casc.com (4.1/3.1.012693-Cascade) Received: from apollo13.cascade by alpo.casc.com (4.1/SMI-4.1) id AA19877; Fri, 18 Nov 94 09:04:21 EST Received: by apollo13.cascade (5.0/SMI-SVR4) id AA01205; Fri, 18 Nov 1994 09:02:11 +0500 Date: Fri, 18 Nov 1994 09:02:11 +0500 From: jmoy@alpo.casc.com (John Moy) Message-Id: <9411181402.AA01205@apollo13.cascade> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <3473.bill.simpson@um.cc.umich.edu> Subject: Re: (IPng) RIP Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bill and Alan- Dial-in support for OSPF has been defined for a while; there is a March I-D which is going to be replaced in the next day or so. It has been implemented by a couple of router vendors already, so the OSPF WG is going to request that it be published as a Proposed Standard RFC. In my opinion, given existing RIP and OSPF implementations, the dial-up support for OSPF is actually easier to implement. However, there is no question that it is easier to write the initial RIP implementation, and that is the justification (in my mind anyway) for a RIPng. Gerry- I don't understand your concern about handling resource shortages. If you look at what OSPF does, it's exactly what RIP does. Namely, if you have new routing information but can't send it because you can't open the underlying data-links, you wait until you can. There's really no alternative. Anyway, the "demand circuit support for OSPF" will be on the agenda for the OSPF WG in San Jose, and we can talk about it there if you still have concerns. 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 Fri Nov 18 06:15:46 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20100; Fri, 18 Nov 94 06:15:46 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20088; Fri, 18 Nov 94 06:15:24 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA29744; Fri, 18 Nov 1994 06:09:41 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA20741; Fri, 18 Nov 94 06:10:33 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-16.dialip.mich.net [35.1.48.217]) by merit.edu (8.6.9/merit-2.0) with SMTP id JAA00163 for ; Fri, 18 Nov 1994 09:10:30 -0500 Date: Fri, 18 Nov 94 13:34:23 GMT From: "William Allen Simpson" Message-Id: <3476.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Service Location and Discovery for IPnG Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: veizades@ftp.com (John Veizades) > I have submitted the current document which describes service location into > the internet drafts directory as "draft-veizades-ipng-srvloc-00.txt". > > This document describes a protocol for the discovery of services on a WAN. > It is based on a datagram exchange protocol. The version described is for > use over an IPv6 UDP. This protocol is also designed for use over other > datagram protocols like IPv4 UDP and AppleTalk's DDP. > I was disappointed in the draft. I had hoped for a new version which was useful for IPv6 location of services such as the address configuration and DNS. This is still far too related to AppleTalk, which has a language dependent "dialog" to search for servers. We really can't have a "dialog" in searching for initialization servers. It doesn't use IPv6 authentication. Instead, it has it's own. I had also hoped that there would be true support for multicast groups. Instead, there is only _one_ multicast address, used by all servers. Kind of like a substitute for broadcast, but nothing more. What I am looking for is a scoped multicast for each "Primary Attribute". In fact, we really don't need primary attributes, which are assigned by IANA. We need _multicast_ groups assigned by IANA. Same thing, only uses the internet layer for delivery, instead of bothering every server for every location request. The secondary attributes concept seems more sound, for times when there is a dialog. But why have language dependent text strings? A simple list of attributes would be fine. The text strings would be in the implementation that makes the requests. The emphasis on Unicode seems a bit of a waste of time. Again, AppleTalk related. 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 Nov 18 06:15:48 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20101; Fri, 18 Nov 94 06:15:48 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20093; Fri, 18 Nov 94 06:15:25 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA29747; Fri, 18 Nov 1994 06:09:42 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA20749; Fri, 18 Nov 94 06:10:35 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm012-16.dialip.mich.net [35.1.48.217]) by merit.edu (8.6.9/merit-2.0) with SMTP id JAA00169 for ; Fri, 18 Nov 1994 09:10:33 -0500 Date: Fri, 18 Nov 94 13:51:52 GMT From: "William Allen Simpson" Message-Id: <3477.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Comments on discov-formats-01.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I've had a couple of nits found in the formats, which shows that folks are reading them. Thanks Dan McDonald and Chuck Desostoa. Anybody else? I'd like comments before I put the -processing draft to bed this weekend. Do people like the field orders? Alignment? Anything else (other than "I don't support use of ICMP")? 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 Nov 18 07:28:37 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20147; Fri, 18 Nov 94 07:28:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20141; Fri, 18 Nov 94 07:28:29 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA02770; Fri, 18 Nov 1994 07:22:46 -0800 Received: from mailhost.wco.ftp.com (wco.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA00823; Fri, 18 Nov 94 07:23:36 PST Message-Id: <9411181519.AA10883@mailhost.wco.ftp.com> Received: from [128.127.202.230] (vida202.wco.ftp.com) by mailhost.wco.ftp.com; Fri, 18 Nov 94 07:19:15 PST X-Sender: veizades@128.127.203.200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Nov 1994 08:42:50 -0800 To: ipng@sunroof.Eng.Sun.COM From: veizades@ftp.com (John Veizades) Subject: Re: (IPng) Service Location and Discovery for IPnG Cc: bill.simpson@um.cc.umich.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At 1:34 PM 11/18/94 +0000, William Allen Simpson wrote: >> From: veizades@ftp.com (John Veizades) >> I have submitted the current document which describes service location into >> the internet drafts directory as "draft-veizades-ipng-srvloc-00.txt". >> >> This document describes a protocol for the discovery of services on a WAN. >> It is based on a datagram exchange protocol. The version described is for >> use over an IPv6 UDP. This protocol is also designed for use over other >> datagram protocols like IPv4 UDP and AppleTalk's DDP. >> >I was disappointed in the draft. I had hoped for a new version which >was useful for IPv6 location of services such as the address >configuration and DNS. > >This is still far too related to AppleTalk, which has a language >dependent "dialog" to search for servers. > >We really can't have a "dialog" in searching for initialization servers. > The text search mechanism allow this to be used for discovery of servers by humans but the attribute grammer can also be used by programs for the location of specific services that meet a broad set of needs (DNS, time, etc). To do this just use the distinguished attribute of the service without any of the rest of the predicate stuff. This has little to do with AppleTalk but is a responce to many of the problems that the Appletalk discovery protocols have. The aim of this protocol was to make the selection and discovery of services as easy or easier than it is in several workgroup networking protocols but to deal with this issues of scaling and extensibility. >It doesn't use IPv6 authentication. Instead, it has it's own. > This is designed for use over IPv4 which does not hve a well define authentication mechnaism and why change a the protocol so that it becomes IPv6 specific. The authentication mechanism is also optional so that the fields can be left blank if no auth mechanism is needed or if it superceeded by some other mechanism. >I had also hoped that there would be true support for multicast groups. >Instead, there is only _one_ multicast address, used by all servers. >Kind of like a substitute for broadcast, but nothing more. > Come to the WG and discuss it. > >The secondary attributes concept seems more sound, for times when there >is a dialog. But why have language dependent text strings? A simple >list of attributes would be fine. The text strings would be in the >implementation that makes the requests. > Again this is a protocol to be used by humans as well as by computers the text stings allow system to learn about attributes that they do not know about since they may be site specific. The rational for this was arrived to and agreed on quite a while ago and if you need the backround talk to me in San Jose. >The emphasis on Unicode seems a bit of a waste of time. Again, >AppleTalk related. > Is this an English speaking bias coming up here? This is a protocol for use with nonroman languages and Unicode seems the only way to represent these languages. 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 Fri Nov 18 08:32:31 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20225; Fri, 18 Nov 94 08:32:31 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20219; Fri, 18 Nov 94 08:32:19 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA06626; Fri, 18 Nov 1994 08:26:35 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA12401; Fri, 18 Nov 94 08:27:28 PST Received: from relay.imsi.com by wintermute.imsi.com id LAA00273 for ; Fri, 18 Nov 1994 11:27:21 -0500 Received: from snark.imsi.com by relay.imsi.com id LAA06500 for ; Fri, 18 Nov 1994 11:27:20 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA11024; Fri, 18 Nov 94 11:27:20 EST Message-Id: <9411181627.AA11024@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Service Location and Discovery for IPnG In-Reply-To: Your message of "Fri, 18 Nov 1994 08:42:50 PST." <9411181519.AA10883@mailhost.wco.ftp.com> X-Reposting-Policy: redistribute only with permission Date: Fri, 18 Nov 1994 11:27:19 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John Veizades says: > >It doesn't use IPv6 authentication. Instead, it has it's own. > > > This is designed for use over IPv4 which does not hve a well define > authentication mechnaism and why change a the protocol so that it becomes > IPv6 specific. The IPv4 authentication mechanism being discussed by the IPSEC group will be a mechanical transformation of the IPv6 one. People looking for portable authentication mechanism in their protocols should probably start thinking in those terms. 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 Nov 18 12:29:17 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20406; Fri, 18 Nov 94 12:29:17 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA20400; Fri, 18 Nov 94 12:29:09 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA27559; Fri, 18 Nov 1994 12:23:25 -0800 Received: from ftp.com (wd40.ftp.com) by Sun.COM (sun-barr.Sun.COM) id AA02703; Fri, 18 Nov 94 12:24:15 PST Received: from ftp.com by ftp.com ; Wed, 16 Nov 1994 18:16:20 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 16 Nov 1994 18:16:20 -0500 Received: from solensky.mccoy.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA11417; Wed, 16 Nov 94 18:15:58 EST Date: Wed, 16 Nov 94 18:15:58 EST Message-Id: <9411162315.AA11417@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Wed Nov 16 18:15:48 1994] Originating-Client: mccoy.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: iialan@iifeak.swan.ac.uk (Alan Cox) > > > How about using '-' as the separator and '=' to denote the zero-suppressed > > fields? > > = is bad > > too many OS's use things like > > NAMESERVER=1.2.3.4 The Unix shells sh, csh, ksh and bash didn't have any problem setting environment variables in this manner: > NAMESERVER==ffff-123.45.67.89 > echo $NAMESERVER NAMESERVER = =ffff-123.45.67.89 The 'COMMAND.COM' interpreter is giving me grief but I'd think that DOS would usually specify this sort of thing within configuration files rather than AUTOEXEC.BAT -- the first '=' acts as the end of the token with everything else being the value. My guess is also that most GUI's would would have the user specify only the value field within a box rather than as "variable=value". -- Frank ------------------------------------------------------------------------------ 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 Nov 19 17:21:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21016; Sat, 19 Nov 94 17:21:38 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21010; Sat, 19 Nov 94 17:21:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA14454; Sat, 19 Nov 1994 17:15:44 -0800 Received: from kiwi.SDSU.Edu by Sun.COM (sun-barr.Sun.COM) id AA04630; Sat, 19 Nov 94 17:16:39 PST Received: by kiwi.SDSU.Edu (4.1/SDSU-Complex) id AA04942 for delivery to ipng@sunroof.eng.sun.com; Sat, 19 Nov 94 17:16:35 PST Date: Sat, 19 Nov 94 17:16:35 PST From: Andrew@kiwi.sdsu.edu (Andrew Scherpbier) Message-Id: <9411200116.AA04942@kiwi.SDSU.Edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I think we overlooked something..... > > IPv4's use of "." as a common sub-field separator within both names and > addresses permitted certain simplifications in application parsers. While > clearly most applications don't use this, it sort of scares me that the WWW > problem was noticed so late. How many other are lurking? > > --MM-- What about Xwindows display addresses... They are in the form location:display.screen Since X11 already uses both ':' and '.' in its screen specification there could be problems using ':' in the location field. (especially if both ':' AND '.' are used in this field...) --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 Mon Nov 21 09:57:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21682; Mon, 21 Nov 94 09:57:53 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21676; Mon, 21 Nov 94 09:57:42 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA18362; Mon, 21 Nov 1994 09:52:52 -0800 Date: Mon, 21 Nov 1994 09:52:52 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411211752.JAA18362@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Cc: hinden@jurassic Subject: (IPng) IPng Web Pages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have installed a set of web pages for IPng. The URL is: http://playground.sun.com/pub/ipng/html/ipng-main.html Please take a look and send me comments/corrections. 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 Nov 22 16:51:06 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22989; Tue, 22 Nov 94 16:51:06 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22983; Tue, 22 Nov 94 16:50:58 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA10646; Tue, 22 Nov 1994 16:45:04 -0800 Received: from netcom8.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA13492; Tue, 22 Nov 94 16:45:51 PST Received: by netcom8.netcom.com (8.6.9/Netcom) id QAA13530; Tue, 22 Nov 1994 16:46:04 -0800 Date: Tue, 22 Nov 1994 16:46:04 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199411230046.QAA13530@netcom8.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) The Blues Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hey Frank, Hows it going? Are you still planning come out to the IETF next month? If you are and are still interested in seeing some blues let me know and I will see whats cooking. There is JJ's Blues in downtown which is a lot like Jonny D's and its only 2 1/2 blocks away from the Fairmont. Anyways, had fun the rest of my stay in Boston after the meeting. Looking forward to spending more time there in the Spring at the next, after the prestn, IETF. -C-ya Rich ------------------------------------------------------------------------------ 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 Nov 22 17:47:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23062; Tue, 22 Nov 94 17:47:21 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23056; Tue, 22 Nov 94 17:47:14 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA17085; Tue, 22 Nov 1994 17:41:19 -0800 Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA28991; Tue, 22 Nov 94 12:28:06 PST Received: from ftp.com by ftp.com ; Mon, 21 Nov 1994 15:43:28 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 21 Nov 1994 15:43:28 -0500 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01418; Mon, 21 Nov 94 15:42:59 EST Date: Mon, 21 Nov 94 15:42:59 EST Message-Id: <9411212042.AA01418@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Mon Nov 21 14:45:50 1994] Originating-Client: fenway.ftp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Fri, 18 Nov 1994 09:33:48 +0100 > From: Christian Huitema > > There certainly is a case for only using those characters which are allowed > by the rfc-821 syntax, i.e. letters, numbers, hyphens and dots... The only > proposal which means this requirement is to use the hyphen as separation > between 4-nibbles groups and double dots for ellipsis. I'd prefer doubling up on the same character when doing zero suppression, so I'd rather see '--' than '..' and hope that the people doing the typesetting do the right thing. Would it make sense to have the character following the digits imply the radix? For example, "12." is twelve while "12-" is eighteen. The ending byte would use the same radix as the penultimate. -- Frank ------------------------------------------------------------------------------ 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 Nov 22 18:35:32 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23102; Tue, 22 Nov 94 18:35:32 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23096; Tue, 22 Nov 94 18:35:23 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA20363; Tue, 22 Nov 1994 18:29:28 -0800 Received: from vulcan.inlink.com by Sun.COM (sun-barr.Sun.COM) id AB27682; Tue, 22 Nov 94 18:30:24 PST Received: (from jbaltzer@localhost) by vulcan.inlink.com (8.6.9/8.6.9) id UAA26016 for ipng@sunroof.Eng.Sun.COM; Tue, 22 Nov 1994 20:32:08 -0600 From: John Baltzer Message-Id: <199411230232.UAA26016@vulcan.inlink.com> Subject: (IPng) WWW home page To: ipng@sunroof.Eng.Sun.COM Date: Tue, 22 Nov 1994 20:32:08 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thanks for putting up the WWW home page on IPng. The information contained therein emphasizes the importance of maintaining backwards compatibility with IPv4. A number of articles have appeared in publications such as PC Week and Data Communications in the last couple of months which claim that IPv6 is NOT backwards compatible with IPv4. The authors of these articles claim that IPv6 is really a completely new protocol and that interoperability with the existing hardware and software will be sorely lacking. Is there any substance to these claims, or is IPv6 backwards compatible with IPv4 as intended? ------------------------------------------------------------------------------ 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 Nov 22 19:35:12 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23149; Tue, 22 Nov 94 19:35:12 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23143; Tue, 22 Nov 94 19:35:05 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08866; Tue, 22 Nov 94 19:30:45 PST Received: from clix.aarnet.edu.au by Sun.COM (sun-barr.Sun.COM) id AA03353; Tue, 22 Nov 94 19:30:04 PST X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 23 Nov 1994 13:18:43 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Wed, 23 Nov 1994 12:45:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Wed, 23 Nov 1994 13:48:52 +1000 Date: Wed, 23 Nov 1994 13:48:52 +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 Nov 23 13:48:51 1994] X400-Content-Type: P2-1984 (2) Content-Identifier: 514813231194 Alternate-Recipient: Allowed From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Message-Id: <514813231194*/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) IPv6 address representation 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.Eng.Sun.COM/O=AARN/ADMD=TELEMEMO/PRMD=OZ.AU/C=AU at DOF-X400 Date: 11/22/94 6:42AM To: Jeff Latimer at DOF-ITB Subject: Re: (IPng) IPv6 address representation ------------------------------------------------------------------------------- ------------------------------ Start of body part 2 >Would it make sense to have the character following the digits imply >the radix? For example, "12." is twelve while "12-" is eighteen. >The ending byte would use the same radix as the penultimate. In a lot of ways simplicity is best. Being able to describe something as decimal that is essentially hex or hex that is essentially decimal just leads to confusion later when trying to work out why there is a problem. Personally, I would prefer a hex form and be done with it. 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 Nov 23 07:44:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23394; Wed, 23 Nov 94 07:44:08 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23388; Wed, 23 Nov 94 07:44:00 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05608; Wed, 23 Nov 94 07:39:41 PST Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA05288; Wed, 23 Nov 94 07:39:02 PST Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.9/8.6.9) with ESMTP id QAA05649 for ; Wed, 23 Nov 1994 16:38:58 +0100 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.8/8.6.6) with ESMTP id QAA17835 for ; Wed, 23 Nov 1994 16:38:57 +0100 Message-Id: <199411231538.QAA17835@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng inverse domains Date: Wed, 23 Nov 1994 16:38:55 +0100 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I believe this discussion should be done in the IPng mailing-list and conclusion/final proposal posted to bind-workers mailing-list. Simple Internet Transition drafts say nothing about IPng inverse domains however we need to look at some details: - IPv4-mapped IPv6 addresses must not have an inverse domains because there are no AAAA associated records and they are in fact IPv4 addresses. Inverse resolution (i.e. get names from addresses) for an IPv4-mapped address must be translated to inverse resolution for the mapped IPv4 address. I believe it must be done by resolver libraries. - the same kind of arguments can be used for IPv4-compatible IPv6 addresses. Magically translating an IPv4-compatible address into the corresponding IPv4 address avoids the administration of some inverse domains but violates the "one address RR-one PTR RR" safety rule. It is a clear win today but can be annoying when almost all the Internet nodes will be IPv6 nodes. - DNS tools (nslookup, dig, ...) should magically reverse input addresses when PTR RR are asked. It is done today by nslookup: > % nslookup -type=ptr 192.9.9.1 > ... > 1.9.9.192.in-addr.arpa name = Sun.COM and by dig ("-x" option). Richard Colella's NSAP support for nslookup has it (VERY useful): > % nslookup -type=ptr 47.0005.8000.5A00.0000.0001.E137.EEEE.EE00.0085.00 > ... > "47.0005.8000.5a00.0000.0001.e137.eeee.ee00.0085.00".nsap.tuba.ncsl.nist.gov name = cursive.tuba.ncsl.nist.gov We definitively need this for IPv6 addresses ! - I propose to extend this to prefixes. I know two solutions, the first one is to use not-ambiguous truncated addresses and the second is to specify the number bits of prefixes a` la CIDR "123:4:0::4567:89ab/101" I prefer the second solution with an as general as possible format. For instance for the input address/N: 1- the textual address is translated (ascii2addr) to the binary address ADDR 2- ADDR is masked (bitwise and) with MASK (N one and 128-N zero bits) 3- the (N+3)/4 first nibbles are selected as the binary prefix PREFIX 4- the PREFIX is translated into the hexadecimal string HEX 5- HEX is reversed, a character "." is inserted after each digit and ip6.int. is appended. Francis.Dupont@inria.fr ------------------------------------------------------------------------------ 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 Nov 23 08:39:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23439; Wed, 23 Nov 94 08:39:27 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23433; Wed, 23 Nov 94 08:39:19 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10814; Wed, 23 Nov 94 08:35:00 PST Received: from ftp.com by Sun.COM (sun-barr.Sun.COM) id AA16239; Wed, 23 Nov 94 08:34:22 PST Received: from ftp.com by ftp.com ; Wed, 23 Nov 1994 11:34:21 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 23 Nov 1994 11:34:21 -0500 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA23293; Wed, 23 Nov 94 11:29:56 EST Date: Wed, 23 Nov 94 11:29:56 EST Message-Id: <9411231629.AA23293@mailserv-D.ftp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) IPv6 address representation From: solensky@ftp.com (Frank T Solensky) Repository: mailserv-D.ftp.com, [message accepted at Wed Nov 23 11:29:55 1994] Originating-Client: fenway.ftp.com Content-Length: 764 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au > >Would it make sense to have the character following the digits imply > >the radix? > > In a lot of ways simplicity is best. Being able to describe something > as decimal that is essentially hex or hex that is essentially decimal > just leads to confusion later when trying to work out why there is a > problem. Personally, I would prefer a hex form and be done with it. Good point, but the IPv4-capable IPv6 address still should be easy to recognize. Do we have rough consensus around "--ffff-123.45.67.89"? The leading hyphen, it seems, would only appear when one is zero-suppressing the left side. Discovering the second hyphen helps avoid mistaking it as a command line option. -- Frank ------------------------------------------------------------------------------ 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 Nov 23 10:10:10 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23478; Wed, 23 Nov 94 10:10:10 PST Received: from Eng.Sun.COM (zigzag) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23472; Wed, 23 Nov 94 10:10:02 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA24592; Wed, 23 Nov 94 10:05:43 PST Received: from alink-gw.apple.com by Sun.COM (sun-barr.Sun.COM) id AB03031; Wed, 23 Nov 94 10:04:37 PST Received: from federal-excess.apple.com by alink-gw.apple.com with SMTP (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA08907; Wed, 23 Nov 94 10:04:23 -0800 for ipng@sunroof.eng.sun.com Received: from lilith.lansys.apple.com by federal-excess.apple.com (5.0/1-Nov-1994-eef) id AA28796; Wed, 23 Nov 1994 10:03:14 +0800 for ipng@sunroof.eng.sun.com Received: (justin@localhost) by lilith.lansys.apple.com (8.6.9/A/UX 3.1) id KAA06336; Wed, 23 Nov 1994 10:04:28 -0800 Date: Wed, 23 Nov 1994 10:04:28 -0800 From: "Justin C. Walker" Message-Id: <199411231804.KAA06336@lilith.lansys.apple.com> To: ipng@sunroof.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Frank T Solensky's message of Wed, 23 Nov 94 11:29:56 EST <9411231629.AA23293@mailserv-D.ftp.com> Subject: (IPng) IPv6 address representation Content-Length: 942 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> Good point, but the IPv4-capable IPv6 address still should be easy to >> recognize. >> >> Do we have rough consensus around "--ffff-123.45.67.89"? The leading >> hyphen, it seems, would only appear when one is zero-suppressing the >> left side. Discovering the second hyphen helps avoid mistaking it as >> a command line option. I don't have a good alternative, but I think the "--" could confound any number of "command line parsers" that don't do a good job of discriminating between options and other things (ever try "rm"ing a file with a leading "-" in its name?). Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | They sentenced me to 20 years Apple Business Systems | of boredom Apple Computer, Inc. | For trying to change the system 10500 North De Anza Blvd | from within Cupertino, CA 95014 | LC *---------------------------------------*------------------------------------* ------------------------------------------------------------------------------ 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 Nov 23 12:22:15 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23573; Wed, 23 Nov 94 12:22:15 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23567; Wed, 23 Nov 94 12:22:07 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id MAA16151; Wed, 23 Nov 1994 12:16:09 -0800 From: yakov@watson.ibm.com Received: from watson.ibm.com ([129.34.139.4]) by Sun.COM (sun-barr.Sun.COM) id AA29160; Wed, 23 Nov 94 12:15:26 PST Message-Id: <9411232015.AA29160@Sun.COM> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0241; Wed, 23 Nov 94 15:14:02 EST Date: Wed, 23 Nov 94 15:13:33 EST To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) FYI Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, Appended is the announcement about the I-D that Peter Lothberg and myself volunteered to write at the last IETF. Yakov ****** The following is a COPY ***************************** Received: from IETF.nri.reston.VA.US by watson.ibm.com (IBM VM SMTP V2R3) with TCP; Wed, 23 Nov 94 14:53:28 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04870; 23 Nov 94 10:53 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04848; 23 Nov 94 10:53 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-rekhter-IPv6-address-format-00.txt Date: Wed, 23 Nov 94 10:53:00 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9411231053.aa04848@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Preferred Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg Filename : draft-rekhter-IPv6-address-format-00.txt Pages : 10 Date : 11/22/1994 This document defines a preferred IPv6 unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 address allocation architecture [1]. The format defined in this document doesn't preclude the use of other of other address formats. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rekhter-IPv6-address-format-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rekhter-IPv6-address-format-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rekhter-IPv6-address-format-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: <19941122141030.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-rekhter-IPv6-address-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rekhter-IPv6-address-format-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941122141030.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 Thu Nov 24 14:19:55 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24128; Thu, 24 Nov 94 14:19:55 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24122; Thu, 24 Nov 94 14:19:48 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA01280; Thu, 24 Nov 1994 14:13:49 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA26750; Thu, 24 Nov 94 14:14:42 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA00421; Fri, 25 Nov 1994 09:14:29 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA13201; Fri, 25 Nov 94 10:12:08 +1100 Message-Id: <9411242312.AA13201@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Fri, 25 Nov 94 09:22:14 AUS Date: Fri, 25 Nov 94 08:07:13 AUS From: Alan.Lloyd@datacraft.com.au Subject: (IPng) re: Re: (nosi) Nosi BOF agenda (fwd) To: nosi@sunroof2.Eng.Sun.COM Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM brian, re the requirements, I thought that was already understood from the drafts already in place. The big one is to harmonise OSI (CLNP-NSAPs) and IP as best as possible. I believe this is a request related to the IETF/ISO MOU. The first action for this to occur is to harmonise the addressing structures as best as possible. Ie Carry NSAPs in IP6 and have IP6 Internet addresses carried in CLNP prefixed by an ICD for the ISOC. The next stage which is critical is to get interworking of the address administration mechanisms (ie the NICs and the ISO/ITU procedures). Hence the draft i put in. The final stage for addressing is to have logical alignment where possible for the routing semantics and hierarchy. The work for the IETF is to agree that this is the approach to be taken and the mechanisms such as Address Extensions Options in IP6 are provided. plus getting ISOC and NSAP ICD. The next phase is to determine the issues associated with the Internet carrying NSAPs as addresses and any affects on the other protocols eg Discovery, Mobility, ARPs ICMPs and OSPFs, etc. The higher level issues can then be addressed ie extensions to X.500 Object classes to contain the attributes for IP6 data forms ie IP6 addresses, Flow Ids, Services. This will be a fairly trivial task as it is one of just data definition. Finally the management issues should be reviewed as no doubt the increased complexity of the network functions, transition requirements of IP6 will increase the mib size and managed object count within systems. So from a point of management I think that "naming" for managed objects will have to be dealt with and as CMIP and X.500 use the same name form and and these can be represented as Object Ids in SNMP, the OSI/IP naming and addressing integration issues will extend into these areas. This last one is probably seeen to be complex so I am quite prepared to chalk and talk on this one for hours ( I also respond to shouts like "Alan please shut up!) However, the bigger picture issues for OSI/IP addressing / naming integration should be "exposed" so we can get a handle or agreement on what is relevant and can be progressed.. Regards Alan@Oz PS I have copied the ipng list because I think these issues affect a number of the IPNG developmenmts and others may wish add comments or participate. ------------------------------------------------------------------------------ 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 Nov 24 23:22:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24189; Thu, 24 Nov 94 23:22:54 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24183; Thu, 24 Nov 94 23:22:46 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA07358; Thu, 24 Nov 1994 23:16:47 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA17361; Thu, 24 Nov 94 23:17:03 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA19237; Fri, 25 Nov 1994 18:15:52 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA14207; Fri, 25 Nov 94 19:12:24 +1100 Message-Id: <9411250812.AA14207@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Fri, 25 Nov 94 18:22:38 AUS Date: Fri, 25 Nov 94 17:24:47 AUS From: Alan.Lloyd@datacraft.com.au Subject: (IPng) comments on the SLP To: srvloc@ftp.com Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Re the SLP. general comments first. Terms and Definitions. The ones used like UA, XID DA already have industry wide understanding. eg UA is the User Agent in X.400. XID is the HDLC frame for exchanging identification (see SDLC/SNA and LLC) Scope = used by CMIP and X.500 for scoping the responses to requests. Distinguished Attribute. used by X.500 to identify the attribute which distinguishes the directory entry from other directory entries (ie its name attribute). General. There has been considerable work on this resource discovery with X.500 directories and X.900 Open Distributed Processing - Trader. The Model. It would be better to to describe a model with three functional elements namely a Service Client, a Service Agent and a Service Directory Agent The client seeks services or knowledge of services. The Service Agent provides services and knowledge of those services. The Directory Agent provides knowledge of Services. The Operations. These can be better represented using the discovery model and X.500 operations names and semantics ie. Discovery: Announce (Service Agent or Directory Agent) Solicit (Client for Service Agent, Service Agent for Directory Agent, Directory Agent for Service Agent) X.500 operation lookalikes: List (from client on ServiceA (SA) or DirectoryA (DA) for the services supported) (X.500 List) (can be filtered on service types) Read (from client on SA or DA) for the specific service attributes/properties. (can be selective on specific attributes) (X.500 Read) Register service (SA to DA) (X.500 Add) De Register service (SA to DA (X.500 Delete) Modify service (SA to DA) (X.500 Modify) etc. Why I put etc is that I cannot see why any other or more complex services are needed for an SLP. but please advise. SCOPE My preference the term is changed to Service Domain and identifed (with an ID) so that clusters of service users and service agents and directory agents can be grouped into domains. Protocol. not good I think strings in things have semantic and extensibility problems therefore cause scale and interoperability problems. Best use an Object Identifier and a related value. The Oid being universally registered and recognised (like MIB OIDs). the value can have string syntax. XID should be invoke ID or Operation Sequence Number (OSN). Format for a service definition. Is it possible to declare this as an object eg Service Object = Class (oid) Must Contain Attributes eg Service Name, Service Type, Version. May contain Attributes eg Description Other Parameters, etc The actions like service binding and use are naturally beyond the scope of this function/ 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 Sun Nov 27 06:28:20 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24918; Sun, 27 Nov 94 06:28:20 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24912; Sun, 27 Nov 94 06:28:06 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA15011; Sun, 27 Nov 1994 06:22:01 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA12867; Sun, 27 Nov 94 06:23:04 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-27.dialip.mich.net [35.1.48.108]) by merit.edu (8.6.9/merit-2.0) with SMTP id JAA22994 for ; Sun, 27 Nov 1994 09:23:02 -0500 Date: Sun, 27 Nov 94 13:54:56 GMT From: "William Allen Simpson" Message-Id: <3537.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) rekhter-IPv6-address-format-00.txt Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I have read this draft this morning, and I am appalled! This is _not_ at _all_ what we have been discussing for the past 2+ years! It has fixed field widths. It has static administrative registries. It does not support changing topologies. It does not support dynamic allocation of addresses. It does not support the Tsuchiya nee Francis RFC-1219 allocation algorithm -- assigning subscribers bitwise from the left. Count me as utterly opposed to this 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 Sun Nov 27 19:52:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25025; Sun, 27 Nov 94 19:52:16 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25019; Sun, 27 Nov 94 19:52:09 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA25735; Sun, 27 Nov 1994 19:46:02 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA07866; Sun, 27 Nov 94 19:46:58 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21626; Mon, 28 Nov 1994 14:46:53 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) What's the right way to say "no next header" Date: Mon, 28 Nov 1994 14:46:50 +1100 Message-Id: <487.785994410@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM If I wanted to send an IP6 packet without any TCP, UDP, ICMP, or similar, data, just, say, end to end options, or something, which may be useful for sopme purpose or other in the futuew, what do I stick in the next header field? The length from the packet header will indicate that there's nothing after the last processed header, but just sticking in a random "next header" value and relying on the length field seems wrong to me. Alternatively, can someone say that its illegal to not have one of the transport level protocols in every IP6 packet, and will be for all (relevant) time? 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 Sun Nov 27 21:47:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25050; Sun, 27 Nov 94 21:47:52 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25044; Sun, 27 Nov 94 21:47:44 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA28458; Sun, 27 Nov 1994 21:41:36 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA13805; Sun, 27 Nov 94 21:42:42 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14650(7)>; Sun, 27 Nov 1994 21:42:29 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Sun, 27 Nov 1994 21:42:16 -0800 To: Robert Elz Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) What's the right way to say "no next header" In-Reply-To: kre's message of Sun, 27 Nov 94 19:46:50 -0800. <487.785994410@munnari.OZ.AU> Date: Sun, 27 Nov 1994 21:42:10 PST From: Steve Deering Message-Id: <94Nov27.214216pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > If I wanted to send an IP6 packet without any TCP, UDP, ICMP, > or similar, data, just, say, end to end options, or something, > which may be useful for sopme purpose or other in the futuew, > what do I stick in the next header field? Oh yeah, I remember this being brought up before (was it by you, kre, or someone else?). I think allocating a "no next header" value is a fine idea. As you said, the payload length value will indicate the absence of anything after the current header, but an explicit value to say that no next header is present would assure that no error message got sent or logged in that case. If no one objects, I'll ask IANA for an assigned value. 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 Sun Nov 27 22:03:21 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25070; Sun, 27 Nov 94 22:03:21 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25064; Sun, 27 Nov 94 22:03:13 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA28749; Sun, 27 Nov 1994 21:57:05 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU by Sun.COM (sun-barr.Sun.COM) id AA14419; Sun, 27 Nov 94 21:58:11 PST Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa17126; 28 Nov 94 0:56:57 EST To: ipng@sunroof.Eng.Sun.COM Cc: Robert Elz , deering@parc.xerox.com In-Reply-To: Your message of "Sun, 27 Nov 94 21:42:10 PST" <94Nov27.214216pst.12173@skylark.parc.xerox.com> From: Dave Johnson Subject: Re: (IPng) What's the right way to say "no next header" Date: Mon, 28 Nov 94 00:56:12 EST Message-Id: <17124.786002172@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> If I wanted to send an IP6 packet without any TCP, UDP, ICMP, >> or similar, data, just, say, end to end options, or something, >> which may be useful for sopme purpose or other in the futuew, >> what do I stick in the next header field? > >Oh yeah, I remember this being brought up before (was it by you, kre, or >someone else?). I think allocating a "no next header" value is a fine idea. > >If no one objects, I'll ask IANA for an assigned value. Don't we already basically have one? Since we are using the IP protocol number space, and since protocol number 0 is "reserved", wouldn't 0 make a good value for this? Dave ------------------------------------------------------------------------------ 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 Nov 27 22:25:23 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25095; Sun, 27 Nov 94 22:25:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25089; Sun, 27 Nov 94 22:25:15 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id WAA29253; Sun, 27 Nov 1994 22:19:07 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA15716; Sun, 27 Nov 94 22:19:59 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27394; Mon, 28 Nov 1994 17:18:37 +1100 (from kre@munnari.OZ.AU) To: Dave Johnson Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) What's the right way to say "no next header" In-Reply-To: Your message of "Mon, 28 Nov 1994 00:56:12 EST." <17124.786002172@CHIMAY.MACH.CS.CMU.EDU> Date: Mon, 28 Nov 1994 17:18:34 +1100 Message-Id: <541.786003514@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Date: Mon, 28 Nov 94 00:56:12 EST From: Dave Johnson Message-ID: <17124.786002172@CHIMAY.MACH.CS.CMU.EDU> Since we are using the IP protocol number space, and since protocol number 0 is "reserved", wouldn't 0 make a good value for this? For some bizarre reason, 0 was taken for hop by hop options. 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 Sun Nov 27 22:39:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25107; Sun, 27 Nov 94 22:39:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25101; Sun, 27 Nov 94 22:38:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id WAA29528; Sun, 27 Nov 1994 22:32:48 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU by Sun.COM (sun-barr.Sun.COM) id AA16446; Sun, 27 Nov 94 22:33:51 PST Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa17207; 28 Nov 94 1:33:09 EST To: Robert Elz Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: Your message of "Mon, 28 Nov 94 17:18:34 +1100" <541.786003514@munnari.OZ.AU> From: Dave Johnson Subject: Re: (IPng) What's the right way to say "no next header" Date: Mon, 28 Nov 94 01:33:07 EST Message-Id: <17205.786004387@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Date: Mon, 28 Nov 94 00:56:12 EST > From: Dave Johnson > Message-ID: <17124.786002172@CHIMAY.MACH.CS.CMU.EDU> > > Since we are using the IP protocol number space, and since > protocol number 0 is "reserved", wouldn't 0 make a good value for this? > >For some bizarre reason, 0 was taken for hop by hop options. > >kre Oh yea.. I forgot that was using 0. Protocol number 255 is also currently reserved, I guess. It still seems more logical to use 0 for "no next header", but maybe it's too late for that. Dave ------------------------------------------------------------------------------ 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 Nov 27 23:10:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25135; Sun, 27 Nov 94 23:10:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25129; Sun, 27 Nov 94 23:10:11 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA00111; Sun, 27 Nov 1994 23:04:04 -0800 Received: from netcom2.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA17892; Sun, 27 Nov 94 23:05:08 PST Received: by netcom2.netcom.com (8.6.9/Netcom) id XAA23407; Sun, 27 Nov 1994 23:04:29 -0800 Date: Sun, 27 Nov 1994 23:04:29 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199411280704.XAA23407@netcom2.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) What's the right way to say "no next header" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Oh yea.. I forgot that was using 0. Protocol number 255 is also >currently reserved, I guess. It still seems more logical to use >0 for "no next header", but maybe it's too late for that. Nothing is cast in concrete at this point, thus I would hope we could change it to make sense. -rich ------------------------------------------------------------------------------ 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 Nov 28 02:01:52 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25205; Mon, 28 Nov 94 02:01:52 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25199; Mon, 28 Nov 94 02:01:43 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id BAA02798; Mon, 28 Nov 1994 01:55:36 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA00695; Mon, 28 Nov 94 01:56:40 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) What's the right way to say "no next header" To: ipng@sunroof.Eng.Sun.COM Date: Mon, 28 Nov 1994 09:57:09 +0100 (GMT) In-Reply-To: <17205.786004387@CHIMAY.MACH.CS.CMU.EDU> from "Dave Johnson" at Nov 28, 94 01:33:07 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Oh yea.. I forgot that was using 0. Protocol number 255 is also > currently reserved, I guess. It still seems more logical to use > 0 for "no next header", but maybe it's too late for that. 255 is most peoples definition of 'IPPROTO_RAW' so I guess it fits rather well. 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 Mon Nov 28 04:50:08 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25312; Mon, 28 Nov 94 04:50:08 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25306; Mon, 28 Nov 94 04:49:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id EAA05385; Mon, 28 Nov 1994 04:43:46 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA13330; Mon, 28 Nov 94 04:44:51 PST Received: from relay.imsi.com by wintermute.imsi.com id HAA16854 for ; Mon, 28 Nov 1994 07:44:08 -0500 Received: from snark.imsi.com by relay.imsi.com id HAA03765 for ; Mon, 28 Nov 1994 07:44:07 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA11558; Mon, 28 Nov 94 07:44:07 EST Message-Id: <9411281244.AA11558@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) What's the right way to say "no next header" In-Reply-To: Your message of "Mon, 28 Nov 1994 17:18:34 +1100." <541.786003514@munnari.OZ.AU> X-Reposting-Policy: redistribute only with permission Date: Mon, 28 Nov 1994 07:44:06 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I must confess that the application of sending a header without a payload somewhat escapes me. This isn't something people do in IPv4. What is the envisioned application in IPng? .pm Robert Elz says: > Since we are using the IP protocol number space, and since > protocol number 0 is "reserved", wouldn't 0 make a good value for this? > > For some bizarre reason, 0 was taken for hop by hop options. ------------------------------------------------------------------------------ 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 Nov 28 05:50:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25329; Mon, 28 Nov 94 05:50:25 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25323; Mon, 28 Nov 94 05:50:17 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA06649; Mon, 28 Nov 1994 05:44:08 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU by Sun.COM (sun-barr.Sun.COM) id AA18103; Mon, 28 Nov 94 05:45:13 PST Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa17550; 28 Nov 94 8:45:00 EST To: ipng@sunroof.Eng.Sun.COM Cc: "Perry E. Metzger" In-Reply-To: Your message of "Mon, 28 Nov 94 07:44:06 EST" <9411281244.AA11558@snark.imsi.com> From: Dave Johnson Subject: Re: (IPng) What's the right way to say "no next header" Date: Mon, 28 Nov 94 08:44:58 EST Message-Id: <17548.786030298@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >I must confess that the application of sending a header without a >payload somewhat escapes me. This isn't something people do in >IPv4. What is the envisioned application in IPng? > >.pm One very useful application of this in general is the ability to piggyback some information on any packet, with the ability to send this information by itself if no existing packet is forthcoming on which to piggyback it. This can be done by defining an extension header to carry the information, but sometimes sending this header with no payload. Charlie Perkins, Andrew Myles, and I have suggested a specific use of this in supporting mobility in IPng. Define an extension header (or an option in the end-to-end options) in which a mobile node can send an update of its location to any correspondent node. After registering in a new location, the mobile node can piggyback this information on any regular data packet carrying a payload that it needs to send to some correspondent node. If it has no regular data to send to this correspondent, it can send the location update by itself, with no payload. In this case, it would set the Next Header field in this new extension header (or in the end-to-end options header) to "no next header". In fact, there's nothing magic about the existing transport-level protocols like TCP, etc., except that they have no Next Header field in their headers. They really just carry a "blob of information" end-to-end. One could imagine a single IPng packet carrying many new transport-level protocols from the sending node to the destination node, all chained together through Next Header fields, with the last one set to "no next header". The existing transport-level protocols just don't need the "no next header" setting, and thus there can only be one of them per packet, at the end. Dave ------------------------------------------------------------------------------ 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 Nov 28 06:09:26 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25353; Mon, 28 Nov 94 06:09:26 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25347; Mon, 28 Nov 94 06:09:18 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA07146; Mon, 28 Nov 1994 06:03:09 -0800 Received: from iifeak.swan.ac.uk by Sun.COM (sun-barr.Sun.COM) id AA19809; Mon, 28 Nov 94 06:02:08 PST Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: (IPng) What's the right way to say "no next header" To: ipng@sunroof.Eng.Sun.COM Date: Mon, 28 Nov 1994 14:02:29 +0100 (GMT) In-Reply-To: <17548.786030298@CHIMAY.MACH.CS.CMU.EDU> from "Dave Johnson" at Nov 28, 94 08:44:58 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > In fact, there's nothing magic about the existing transport-level > protocols like TCP, etc., except that they have no Next Header field > in their headers. They really just carry a "blob of information" > end-to-end. One could imagine a single IPng packet carrying many > new transport-level protocols from the sending node to the destination > node, all chained together through Next Header fields, with the last > one set to "no next header". The existing transport-level protocols > just don't need the "no next header" setting, and thus there can only > be one of them per packet, at the end. This sounds like it has exciting possibilities for accumulating tcp frames between a host and a terminal server. 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 Mon Nov 28 06:43:29 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25366; Mon, 28 Nov 94 06:43:29 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25360; Mon, 28 Nov 94 06:43:22 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA08121; Mon, 28 Nov 1994 06:37:15 -0800 Received: from CHIMAY.MACH.CS.CMU.EDU by Sun.COM (sun-barr.Sun.COM) id AA23782; Mon, 28 Nov 94 06:38:19 PST Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa17609; 28 Nov 94 9:37:09 EST To: ipng@sunroof.Eng.Sun.COM Cc: Alan Cox In-Reply-To: Your message of "Mon, 28 Nov 94 14:02:29 +0100" From: Dave Johnson Subject: Re: (IPng) What's the right way to say "no next header" Date: Mon, 28 Nov 94 09:36:58 EST Message-Id: <17607.786033418@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> In fact, there's nothing magic about the existing transport-level >> protocols like TCP, etc., except that they have no Next Header field >> in their headers. They really just carry a "blob of information" >> end-to-end. One could imagine a single IPng packet carrying many >> new transport-level protocols from the sending node to the destination >> node, all chained together through Next Header fields, with the last >> one set to "no next header". The existing transport-level protocols >> just don't need the "no next header" setting, and thus there can only >> be one of them per packet, at the end. > >This sounds like it has exciting possibilities for accumulating tcp frames >between a host and a terminal server. > >Alan Exactly one of the uses I had in mind. You could in general accumulate any number of transport-level payloads whose only relationship is that they are going from the same source node to the same destination node. When the packet gets to the destination, you just call each of the protocol modules in turn, and can thus amortize the per packet overhead over all of these transport-level payloads. Dave ------------------------------------------------------------------------------ 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 Nov 28 07:50:18 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25425; Mon, 28 Nov 94 07:50:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25419; Mon, 28 Nov 94 07:50:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA11002; Mon, 28 Nov 1994 07:44:02 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA03975; Mon, 28 Nov 94 07:45:07 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14845(7)>; Mon, 28 Nov 1994 07:44:56 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Mon, 28 Nov 1994 07:44:48 -0800 To: Robert Elz Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: Re: (IPng) What's the right way to say "no next header" In-Reply-To: kre's message of Sun, 27 Nov 94 22:18:34 -0800. <541.786003514@munnari.OZ.AU> Date: Mon, 28 Nov 1994 07:44:34 PST From: Steve Deering Message-Id: <94Nov28.074448pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM kre, > For some bizarre reason, 0 was taken for hop by hop options. The value 0 was chosen for that purpose because testing for zero is sometimes faster (fewer memory refs), and never slower, than testing for any other constant. The performance of this test is significant because a router must explicitly check each packet for the presence of a hop-by-hop header, in its main forwarding loop. It is the only next-header value that has that requirement. (It is in that sense that the next-header value for hop-by-hop header is "special", to belatedly answer one of your earlier questions.) 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 Nov 28 13:40:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25672; Mon, 28 Nov 94 13:40:38 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25666; Mon, 28 Nov 94 13:40:30 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA14502; Mon, 28 Nov 1994 13:34:21 -0800 From: conta@zk3.dec.com Received: from decvax.dec.com (decvax.zk3.dec.com) by Sun.COM (sun-barr.Sun.COM) id AA13212; Mon, 28 Nov 94 13:35:04 PST Received: from flambe.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA09846; Mon, 28 Nov 1994 16:34:42 -0500 Received: from brigit.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA14205; Mon, 28 Nov 1994 16:33:06 -0500 Received: from localhost by brigit.zk3.dec.com; (5.65/1.1.8.2/19Sep94-0246PM) id AA27515; Mon, 28 Nov 1994 16:09:26 -0500 Message-Id: <9411282109.AA27515@brigit.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: kre@munnari.oz.au, deering@parc.xerox.com, conta@zk3.dec.com Subject: Re: (IPng) What's the right way to say "no next header" In-Reply-To: Your message of "Sun, 27 Nov 94 21:42:10 PST." <94Nov27.214216pst.12173@skylark.parc.xerox.com> Date: Mon, 28 Nov 94 16:09:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM From: Steve Deering > If I wanted to send an IP6 packet without any TCP, UDP, ICMP, > or similar, data, just, say, end to end options, or something, > which may be useful for sopme purpose or other in the futuew, > what do I stick in the next header field? Oh yeah, I remember this being brought up before (was it by you, kre, or someone else?). I think allocating a "no next header" value is a fine idea. As you said, the payload length value will indicate the absence of anything after the current header, but an explicit value to say that no next header is present would assure that no error message got sent or logged in that case. If no one objects, I'll ask IANA for an assigned value. Steve Two things pop up in my mind: 1. As a matter of principle I would rather see ICMP being used for carrying IP control information of any sort, rather than hop-by-hop, or end-to-end extension headers. Therefore I see a packet with IP only headers as an incomplete packet. 2. I think there is a potential to over-load the "next-header" field. We use the "next-header" for both transport headers, and IP extension headers. This presents a greater danger to exhaust the one byte possible values than in IPv4 - I can see a number of NG protocols emerging, while the traditional ones are still in use, and getting back the old numbers is not going to be easy. Since apparently we need just a "terminator header", we could chose from several more options, besides the "next-header": - use ICMP, with a new type: NO-OP, or "Terminate processing here", or "end of header processing". - define a "terminator" end-to-end option header. Architecturally I think ICMP would fit just fine - IMHO - so it is my preference. 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 Nov 28 18:07:05 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26045; Mon, 28 Nov 94 18:07:05 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26039; Mon, 28 Nov 94 18:06:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA10212; Mon, 28 Nov 1994 18:00:44 -0800 Received: from newdev.harvard.edu by Sun.COM (sun-barr.Sun.COM) id AA03857; Mon, 28 Nov 94 18:01:42 PST Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id VAA09073; Mon, 28 Nov 1994 21:03:23 -0500 (EST) Date: Mon, 28 Nov 1994 21:03:23 -0500 (EST) From: Scott Bradner Message-Id: <199411290203.VAA09073@newdev.harvard.edu> To: bill.simpson@um.cc.umich.edu Subject: (IPng) Re: THE question Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > You haven't publically answered my publically raised question: > > > From: Scott Bradner > > It should be noted that the referenced requirements draft was not on > > the list of documents referred to the ipng working group in the ipng > > AD's recommendation. > > > Then, either: > > 1) the AD's recommendation is incomplete, or > > 2) the AD made a formal decision not to include Neighbor Discovery. > > Please clarify. > > Bill.Simpson@um.cc.umich.edu Bill, The list of documents referenced in the recommendation was developed in consultation with a number of people including the SIPP working group chairs. The Neighbor Discovery document was not one of those that was suggested that Allison and I include in our recommendation. It, along with many other documents, was discussed before the list was finalized. So I guess that 2) is the closest answer. Scott (at over 50 pages, some people have claimed that the recommendation is a bit over complete. :-) ) ------------------------------------------------------------------------------ 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 Nov 28 19:12:13 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26074; Mon, 28 Nov 94 19:12:13 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26068; Mon, 28 Nov 94 19:12:05 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA13266; Mon, 28 Nov 1994 19:05:56 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA10303; Mon, 28 Nov 94 19:06:14 PST Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10870; Tue, 29 Nov 1994 14:06:05 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Re: THE question In-Reply-To: Your message of "Mon, 28 Nov 1994 21:03:23 CDT." <199411290203.VAA09073@newdev.harvard.edu> Date: Tue, 29 Nov 1994 14:05:58 +1100 Message-Id: <649.786078358@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Then, either: > > 1) the AD's recommendation is incomplete, or > > 2) the AD made a formal decision not to include Neighbor Discovery. I meant to say this when this was first on the list, but didn't get around to it, so I will now. This question is woefully incomplete, and unfair, perhaps unless by "not to include Neighbor Discovery" was meant, "not to include that particular Neighbour Discovery requirements draft document", in which case it should really have said that. As it stands however, ignoring one particular draft requirements document doesn't mean that the concept itself should be ignored. When we get to the day that internet drafts must be accepted as they are, or the whole discussion ignored, then it will be time for the IETF to close up shop. Neighbour discovery as a concept is just fine, indeed, necessary. The draft requirements doc in question has no status whatever however until the IETF chooses to give it some. The same applies to all drafts. 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 Tue Nov 29 10:01:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26412; Tue, 29 Nov 94 10:01:51 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26406; Tue, 29 Nov 94 10:01:43 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA16370; Tue, 29 Nov 1994 09:55:32 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA10991; Tue, 29 Nov 94 09:56:20 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15174 for ipng@sunroof.eng.sun.com; Tue, 29 Nov 94 12:14:12 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA01689; Tue, 29 Nov 1994 09:12:30 -0800 Message-Id: <199411291712.JAA01689@aland.bbn.com> To: end2end-interest@isi.edu, ipng@sunroof.Eng.Sun.COM, flows@research.att.com To: int-serv@isi.edu Subject: (IPng) mechanisms for managing the flow ID field in IPv6 From: Craig Partridge Date: Tue, 29 Nov 94 09:12:15 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi folks: Attached is a draft of an RFC that I propose to send to the RFC editor in two weeks. It summarizes recent discussions in the End-to-End Research Group about how to manage the Flow ID field and has some suggestions for refining the language in the IPv6 specificiation. I'm still waiting for a few comments to filter back, but I've gotten several comments already and think this is ready for wider circulation. Comments are welcomed. I apologize to those of you who get this message three or four times - I'm trying to hit the more important interested lists, namely the E2E list, the IPNG list (since this involves the IPNG spec), the Flows list (since this is a flows issue) and the INT SERV WG (since I propose to discuss this document at the INT SERV WG meeting next week). Craig *************************************************************************** End-To-End Research Group C. Partridge Request for Comments: DRAFT BBN Systems and Technologies December 1994 Using the Flow ID Field in IPv6 Status of this Memo At its most recent meeting, the End-to-End Research Group had a discussion about how the Flow ID field in IPv6 should be used. This memo attempts to distill that discussion into a set of suggestions and still unresolved issues that can be used as an input into the IPv6 process. Distribution of this memo is unlimited. Brief Description of the Flow ID The current draft of the IPv6 specification states that every IPv6 header contains a 28-bit Flow Label, which is composed of a 4-bit traffic class field followed by a 24-bit Flow ID field. The traffic class is a priority field and can be redefined by the flow. The Flow ID is a pseudo-random number between 1 and FFFFFF (hex) that is unique when combined with the source address. The zero Flow ID is reserved to say that no Flow ID is being used. The specification requires that a source must not reuse a Flow ID value until all state information for the previous use of the Flow ID has been flushed from all routers in the internet. The specification further requires that all datagrams with the same (non-zero) Flow ID must have the same Destination Address, Hop Options header, and Routing Header contents. The notion is that by simply looking up the Flow ID in a table, the router can decide how to route and forward the datagram without examining the rest of the header. Flow ID Issues The current specification leaves open a number of questions, which the End-to-End group discussed: 1. What should a router do if a datagram with a (non-zero) Flow ID arrives and the router has no state for that Flow ID? Partridge [Page 1] RFC DRAFT December 1994 2. How does an internet flush old Flow IDs? 3. Which datagrams should carry (non-zero) Flow IDs? This memo summarizes the group's attempts to answer these questions. What Does a Router Do With Flow IDs for Which It Has No State? If a datagram with a non-zero Flow ID arrives at a router and the router discovers it has no state information for that Flow ID, what is the correct thing for the router to do? There is an initial instinct to assume that this scenario only occurs in the case of an error, but this may not be the case. For instance, a router that crashes will lose its state, but may be able to recover that state after a brief period of operation. During the recovery period, the router will receive datagrams with Flow IDs it does not know, but this is arguably not an error, but rather a part of the recovery period. In any case, it is clear that usual IPv4 error handling, namely to drop the datagram and send an ICMP message, is inappropriate. We expect a large number of flows to be multicast, and it is easy to envision scenarios in which the flow's sender could be inundated with ICMP error messages if some portion of an internet unexpectedly starts receiving the flow's datagrams. Furthermore, it seems likely that in most cases, simply forwarding the datagram as one would a datagram with a zero Flow ID would give better service to the flow than dropping the datagram. (Note that because the flow may have redefined the meaning of the traffic class field, the datagram must be forwarded as if the traffic class field was also 0, even if the traffic class is non-zero). Of course, there will be situations in which routing the datagram as if its Flow ID were zero will cause the wrong result. An example is a router which has two paths to the datagram's destination, one via a high-bandwidth satellite link and the other via a low-bandwidth ter- restrial link. A high bandwidth flow obviously should be routed via the high-bandwidth link, but if the router loses the flow state, the router may route the traffic via the low-bandwidth link, with the potential for the flow's traffic to swamp the low-bandwidth link. It seems likely, however, these situations will be exceptions rather than the rule. So it seems reasonable to handle these situations using options that indicate that if the flow state is absent, the datagram needs special handling. (The options may be Hop-by-Hop or only handled at some routers, depending on the flow's needs). In summary, the group's view is that the default rule should be that Partridge [Page 2] RFC DRAFT December 1994 if a router receives a datagram with an unknown Flow ID, it treats the datagram as if the Flow ID and traffic class fields are zero. As part of forwarding, the router will examine any options and learn if the the datagram requires special handling. The options could include simply the information that the datagram is to be dropped if the Flow ID is unknown or could contain a brief summary of the flow state the router should have. There is clearly room here for experi- mentation with option design. Flushing Old Flow IDs The flow mechanism assumes that state associated with a given Flow ID is somehow deposited in routers, so they know how to handle datagrams that carry the Flow ID. A serious problem is how to flush Flow IDs that are no longer being used (stale Flow IDs) from the routers. Stale Flow IDs can happen a number of ways, even if we assume that the source always sends a message deleting a Flow ID when the source finishes using a Flow. An internet may have partioned since the flow was created. Or the deletion message may be discarded before reach- ing all routers. Furthermore, the source may crash before it can send out a Flow ID deletion message. The point here is that we can- not expect the source (or, for the same reasons, a third party) to clear out stale Flow IDs. Rather routers will have to find some mechanism to flush Flow IDs themselves. The obvious mechanism is to use a timer. Routers should discard Flow IDs whose state has not been refreshed within some period of time (say 2 minutes). At the same time, a source that crashes must observe a quiet time, during which it creates no flows, until it knows that all Flow IDs from its previous life must have expired. (Sources can avoid quiet time restrictions by keeping information about active Flow IDs in stable storage that survives crashes). This is precisely how TCP initial sequence numbers are managed and it seems the same mechanism should work well for Flow IDs. Exactly how the Flow ID and its state should be refreshed needs some study. There are two obvious options. The source could periodically send out a special refresh message (such as an RSVP Path message) to explicitly refresh the Flow ID and its state. Or, the router could treat every datagram that carries the Flow ID as an implicit refresh. The choice is between periodically handling a special update message and doing an extra computation on each datagram (namely noting in the Flow ID's entry that the Flow ID has been refreshed). Which Datagrams Should Carry (Non-Zero) Flow IDs? Interestingly, this is the problem on which the research group made Partridge [Page 3] RFC DRAFT December 1994 the least progress. There were some points of basic agreement. Small exchanges of data should have a zero Flow ID, because it is not worth creating a flow for a few datagrams. And real-time flows must obviously always have a Flow ID, since flows are the main reason Flow IDs were created. The issue is what to do with peers sending large amounts of best effort traffic (e.g., TCP connections). Some people want TCP connec- tions to use Flow IDs, others do not. The argument in favor of using Flow IDs on individual TCP connections is that even if the source does not request special service, a net- work provider's routers may be able to recognize a large amount of traffic and use the Flow ID field to establish a special route that gives the TCP connection better service (e.g., lower delay or bigger bandwidth). The argument against using Flow IDs in individual TCP connections is that it changes how we handling route caches in routers. Currently one can cache a route for a destination host, regardless of how many different sources are sending to that destination host. I.e., if five sources each have two TCP connections sending data to a server, one cache entry containing the route to the server handles all ten TCPs' traffic. Putting Flow IDs in each datagram changes the cache into a Flow ID cache, in which there is a cache entry for every TCP connection. So there's a potential for cache explosion. (One can alleviate this slightly by having the multiple Flow ID cache entries for the same destination point to the same routing entry, but there's still some cost). Observe that there is no easy compromise between these positions. One cannot, for instance, let the application decide whether to use a Flow ID. Those who want different Flow IDs for every TCP connection assume that they may optimize a route without the application's knowledge. And forcing all applications to use Flow IDs will force routing vendors to deal with the cache explosion issue, even if we later discover that we don't want to optimize individual TCP connec- tions. Recommendations Based on its discussion, the End-to-End Group suggests the following requirements on Flow IDs be added to the IPv6 specification. 1. When a router receives a datagram with an unknown Flow ID, the router forwards the datagram as if the Flow Label field was set to zero (i.e., both traffic class and Flow ID), unless the datagram options indicate different handling is required. Partridge [Page 4] RFC DRAFT December 1994 Note that the router is not expected to examine any options it would not examine on a datagram with a zero Flow Label. 2. Flow IDs should expire if not refreshed within some number of minutes (the exact number needs some more consideration) and flow sources should observe a quiet time equal to this inter- val after rebooting to avoid confusing Flow IDs (unless the source keeps track of Flow IDs across reboots). The exact refresh mechanism (periodic messages vs. implicit refreshes on each datagram) is still to be determined. The issue of which datagrams should have non-zero Flow IDs is still not decided. Acknowledgements I would like to acknowledge the assistance of the members of the End-To-End Research Group, chaired by Bob Braden, whose discussions produced this memo. I would also like to particularly thank Deborah Estrin for her help in putting this memo together. Partridge [Page 5] ------------------------------------------------------------------------------ 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 Nov 29 10:37:53 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26446; Tue, 29 Nov 94 10:37:53 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26440; Tue, 29 Nov 94 10:37:45 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA20312; Tue, 29 Nov 1994 10:31:34 -0800 Received: from hp.com by Sun.COM (sun-barr.Sun.COM) id AA18399; Tue, 29 Nov 94 10:32:33 PST Received: from hpinpcb.cup.hp.com (hpindus.cup.hp.com) by hp.com with SMTP (1.37.109.13/15.5+ECS 3.3) id AA201003934; Tue, 29 Nov 1994 10:32:14 -0800 Received: by hpinpcb.cup.hp.com (1.37.109.4/15.5+IOS 3.20+cup+OMrelay) id AA09903; Tue, 29 Nov 94 10:31:03 -0800 Date: Tue, 29 Nov 94 10:31:03 -0800 From: Chuck Desostoa Message-Id: <9411291831.AA09903@hpinpcb.cup.hp.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) What's the right way to say "no next header" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Exactly one of the uses I had in mind. You could in general accumulate > any number of transport-level payloads whose only relationship is that > they are going from the same source node to the same destination node. > When the packet gets to the destination, you just call each of the > protocol modules in turn, and can thus amortize the per packet overhead > over all of these transport-level payloads. > > Dave Same as rfc1692, no? Except there's more to it then just concatinating transport-level payloads, like determining what the appropriate concati- nation timer should be, max concat seg size, negotiating use of this behavior between nodes, etc. With the flexibility of IPv6 to do this maybe there should be a TMUXng that leverage this feature. (Assuming, of course, TMUX is being implemented.) chuckd ------------------------------------------------------------------------------ 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 Nov 29 10:51:25 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26459; Tue, 29 Nov 94 10:51:25 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26453; Tue, 29 Nov 94 10:51:18 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA21561; Tue, 29 Nov 1994 10:45:07 -0800 Received: from KARIBA.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA21067; Tue, 29 Nov 94 10:46:06 PST Message-Id: <9411291846.AA21067@Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of Tue, 29 Nov 94 09:12:15 -0800. <199411291712.JAA01689@aland.bbn.com> Date: Tue, 29 Nov 94 13:45:58 -0500 From: Isidro Castineyra Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Your second recommendation 2. Flow IDs should expire if not refreshed within some number of minutes (the exact number needs some more consideration) and flow sources should observe a quiet time equal to this inter- val after rebooting to avoid confusing Flow IDs (unless the source keeps track of Flow IDs across reboots). The exact refresh mechanism (periodic messages vs. implicit refreshes on each datagram) is still to be determined. seems to be one of many ways of guaranteeing uniquene Flow IDs. Why are you blessing it as one of your two recommendations? Isidro ------------------------------------------------------------------------------ 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 Nov 29 11:12:50 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26482; Tue, 29 Nov 94 11:12:50 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26476; Tue, 29 Nov 94 11:12:39 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id LAA13077; Tue, 29 Nov 1994 11:07:41 -0800 Date: Tue, 29 Nov 1994 11:07:41 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199411291907.LAA13077@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199411230232.UAA26016@vulcan.inlink.com> Subject: re: (IPng) WWW home page Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM John Baltzer writes: > Thanks for putting up the WWW home page on IPng. The information > contained therein emphasizes the importance of maintaining backwards > compatibility with IPv4. A number of articles have appeared in > publications such as PC Week and Data Communications in the last > couple of months which claim that IPv6 is NOT backwards compatible > with IPv4. The authors of these articles claim that IPv6 is really > a completely new protocol and that interoperability with the existing > hardware and software will be sorely lacking. > > Is there any substance to these claims, or is IPv6 backwards > compatible with IPv4 as intended? John, The articles are correct in a limited sense but wrong in the overall conclusion. IPv4 and IPv6 are, of course, different protocols. They have different header formats, different address sizes, and IPv6 has new features that are not in IPv4. In this sense IPv6 is a different protocol than IPv4 and does not interoperate directly. What the articles miss is that we are designing IPng so that IPv6 implementations will interoperate with IPv4 implementations. A number of techniques are used to do this (e.g., dual IP layers, encapsulation, translation, carrying IPv4 addresses in IPv6, etc.) with the goal of making an IPng implementation interoperate with both IPv4 and IPv6 implementations. From a user perspective IPv6 implementations are backward compatible with IPv4 implementations. The following Internet Drafts provide more detail on this: Title : Simple Internet Transition Overview Author(s) : R. Gilligan Filename : draft-gilligan-ipv6-sit-overview-01.txt Pages : 31 Date : 11/21/1994 Title : Transition Mechanisms for IPv6 Hosts and Routers Author(s) : R. Gilligan, E. Nordmark Filename : draft-gilligan-ipv6-trans-mech-00.txt Pages : 25 Date : 11/21/1994 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 Nov 29 11:17:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26495; Tue, 29 Nov 94 11:17:42 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26489; Tue, 29 Nov 94 11:17:34 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA24327; Tue, 29 Nov 1994 11:11:23 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA26039; Tue, 29 Nov 94 11:12:23 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06300 for ipng@sunroof.eng.sun.com; Tue, 29 Nov 94 14:12:18 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id LAA01892; Tue, 29 Nov 1994 11:10:39 -0800 Message-Id: <199411291910.LAA01892@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of Tue, 29 Nov 94 13:45:58 -0500. <9411291846.AA21067@Sun.COM> From: Craig Partridge Date: Tue, 29 Nov 94 11:10:38 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Your second recommendation .... seems to be one of many ways of guaranteeing uniquene Flow IDs. Why are you blessing it as one of your two recommendations? Hi Isidro: The idea is that yes there are several mechanisms. This one is simple, it is known to work, and the E2E group was comfortable with it, and so that's what the E2E recommended. If you want to come up with another scheme that's simple and works well and propose it as an alternative and have us talk about the tradeoffs, that's fine by me (and I think everyone else in E2E, though speaking for anyone in the E2E group is a dangerous business... :-)). Craig ------------------------------------------------------------------------------ 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 Nov 29 11:19:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26507; Tue, 29 Nov 94 11:19:16 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26501; Tue, 29 Nov 94 11:19:07 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA24493; Tue, 29 Nov 1994 11:12:55 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA26355; Tue, 29 Nov 94 11:13:55 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06472 for ipng@sunroof.eng.sun.com; Tue, 29 Nov 94 14:13:27 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id LAA01899; Tue, 29 Nov 1994 11:11:48 -0800 Message-Id: <199411291911.LAA01899@aland.bbn.com> To: int-serv@isi.edu, end2end-interest@isi.edu, flows@research.ftp.com To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Deering's comments on flow ID management From: Craig Partridge Date: Tue, 29 Nov 94 11:11:47 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi folks: Steve's comments on an earlier draft and my note to these lists crossed in the ether this morning. Steve suggested I forwarded his comments on to everyone. Craig E-mail: craig@aland.bbn.com or craig@bbn.com ------- Forwarded Message Received: from alpha.Xerox.COM by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15219 for popbbn; Tue, 29 Nov 94 12:14:27 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14577(2)>; Tue, 29 Nov 1994 09:13:47 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Tue, 29 Nov 1994 09:13:40 -0800 To: Craig Partridge Cc: deering@parc.xerox.com Subject: Re: rough draft of flow id management memo In-Reply-To: craig's message of Tue, 22 Nov 94 13:41:37 -0800. <199411222142.NAA01666@aland.bbn.com> Date: Tue, 29 Nov 1994 09:13:34 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Nov29.091340pst.12173@skylark.parc.xerox.com> Craig, Sorry this took so long -- so much to do and so little time and energy. > Please give me your comments soon, as I'd like to send this to the INT SERV > next week for discussion at IETF. (I assume I should also hit the > E2E-Interest list -- any others?). Please also send it to the ipng and sdrp lists, and maybe to Noel's flows list. > I'm treating this as ideas from the End-to-End Research Group and propose > to publish it as an informational RFC. (The RG so rarely produces things > I thought it would be nice, and is certainly consistent with the idea of > publishing white papers sent to the IPng process). Sounds fine to me. Suggest you get it out as an Internet Draft first, in case there is delay in the RFC-ification process. > The specification further requires that all datagrams with the same > (non-zero) Flow ID must have the same Destination Address, Hop > Options header, and Routing Header contents. Insert "and Source Address" before "must have". Change "Hop Options" to "Hop-by-Hop Options". > What Does a Router Do With Flow IDs for Which It Has No State? > > If a datagram with a non-zero Flow ID arrives at a router and the > router discovers it has no state information for that Flow ID, what > is the correct thing for the router to do? > > There is an initial instinct to assume that this scenario only occurs > in the case of an error, That would not be one's initial instinct if one read the spec. The spec says that routers are free to ignore the flow ID if they don't implement support for flows; clearly in that case packets may arrive with non-zero flow IDs and the absence of flow state would not be an error. The spec also talks about flows carrying their set-up information in options within the flow's data packets themselves, in which case it would be quite normal and non-erroneous for a packet with a non-zero flow ID to arrive and find no state yet (that state to be created when the packet's options are processed). > In any case, it is clear that usual IPv4 error handling, namely to > drop the datagram and send an ICMP message, is inappropriate. We > expect a large number of flows to be multicast, and it is easy to > envision scenarios in which the flow's sender could be innundated > with ICMP error messages if some portion of the internet unexpectedly > starts receiving the flow's datagrams. Since the previous paragraph pointed out that it is not erroneous to be missing state, there's no need to start talking about "IPv4 error handling" (which also makes one wonder why you are talking about IPv4 at all). Your multicast scenario is incorrect because there are overriding rules about not sending ICMP error messages in response to multicasts, which prevent the behavior you describe. "innundated" -> "inundated" > In summary, the group's view is that the default rule should be that > if a router receives a datagram with an unknown Flow ID, it treats > the datagram as if the Flow ID and traffic class fields are zero. As > part of forwarding, the router will examine any options... More precisely, the router will examine any hop-by-hop options present in the packet (and, possibly, additional extension headers if the packet were explicitly addressed to the router). > The options could include > simply the information that the datagram is to be dropped if the Flow > ID is unknown or could contain a brief summary of the flow state the > router should have. A "brief summary"? What use would that be? If the option includes more than just error-handling instructions, shouldn't it include all the information necessary to (re)establish the state? > State Flow IDs can happen a number of ways, ... "State" -> "Stale" > ...flow was created. Or the deletion message may be discarded before > reaching all routers. "discarded" -> "lost" > ...The point here is that we > cannot expect the source (or, for the same reasons, a third party) to > clear out old Flow IDs. Rather routers will have to find some > mechanism to flush Flow IDs themselves. Insert "always" before "to clear out". Insert a comma after "Rather". > The obvious mechanism is to use a timer. Routers should discard Flow > IDs whose state has not been refreshed within some period of time > (say 2 minutes). At the same time, a source that crashes must > observe a quiet time,... Note that this applies only to sources that are unable to remember their flows across crashes, e.g., in stable storage. > Exactly how the Flow ID and its state should be refreshed needs some > study. There are two obvious options. The source could periodically > send out a special refresh message (such as an RSVP Path message) to > explicitly refresh the Flow ID and its state. Or, the router could > treat every datagram that carries the Flow ID as an implicit refresh. There is at least one more alternative: explicit refreshing info could be piggybacked (i.e., carried as an option) on some or all of the flow's data packets. > ...And real-time flows must > obviously always have a Flow ID, since flows are the reason Flow IDs > were created. Wrong. *Explicitly set up flows* or *flows with reserved resources* must obviously always have a flow ID. We may well decide to continue handling some/most real-time traffic as unreserved, non-setup datagrams, as we do now. In other words flowness and real-timeness are orthogonal. > ...Some people > want TCP connections to use Flow IDs, others do not. Insert "all" before "TCP connections". > The argument in favor of using Flow IDs on individual TCP connections > is that even if the source does not request special service, a net- > work provider's routers may be able to recognize a large amount of > traffic and use the Flow ID field to establish a special route that > gives the TCP connection more bandwidth or lower delay. This seems a very poorly thought-out argument to me. Since flow IDs are random, and therefore unpredictable by the providers, and since TCP connections come and go quite quickly (especially since Web traffic started to dominate), it seems impractical and of marginal value to do what you suggest here. More likely would be re-routing all TCP connections between a pair of nodes (or clusters) -- the flow ID wouldn't help at all for that. The only credible argument I have heard for labelling every TCP connection with a unique flow ID is for efficient demux at the receiver. And I don't know how much of a performance improvement that would buy, given that folks have already implemented zero-copy TCPs under IPv4, which does not have flow IDs. It has also been suggested that labelling every TCP connection with a unique flow ID would somehow facilitate header compression, but as you saw in the e2e meeting, I go ballistic at that suggestion. :-) > Putting Flow IDs in each datagram changes the cache into a > Flow ID cache, in which there's a cache entry for every TCP connec- > tion. So there's a potential for cache explosion. The amount of explosion will depend on the "working set" of active flows, presumably. That *might* not be so bad -- should look at the various recent TCP trafric sttudies. > 2. Flow IDs should expire if not refreshed within some number of > minutes (the exact number needs some more consideration) and flow > sources should observe a quiet time equal to this interval after > rebooting to avoid confusing Flow IDs. Again, include caveat about sources that can remember flows across reboots. Did you get a chance to talk to Van about the costs/benefits of flow IDs for all non-reserved TCP connections? Steve ------- 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 Tue Nov 29 11:32:39 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26540; Tue, 29 Nov 94 11:32:39 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26534; Tue, 29 Nov 94 11:32:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA25913; Tue, 29 Nov 1994 11:26:20 -0800 Received: from netcom17.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA28837; Tue, 29 Nov 94 11:26:58 PST Received: by netcom17.netcom.com (8.6.9/Netcom) id LAA20180; Tue, 29 Nov 1994 11:10:43 -0800 Date: Tue, 29 Nov 1994 11:10:43 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199411291910.LAA20180@netcom17.netcom.com> To: end2end-interest@isi.edu, ipng@sunroof.Eng.Sun.COM Subject: R: (IPng) mechanisms for managing the flow ID field in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here are a couple of comments in the draft RFC. I found it useful. >What Does a Router Do With Flow IDs for Which It Has No State? It seems the proposed solution is a balk. It really says once you lose the state the flow ID will not be recovered, at least systematically. This seems like a shame to create 75% of a mechanism without having some solution to the other 25%. I realize that I have not been involved in this problem to the level that you all have but I would suggest 2 things. 1. If there are mechanisms that you discussed as proposed solutions to this but ruled out they should be included in this RFC so we can understand the whole rationale. 2. I will attempt a few suggestions, in an attempt that I can get educated as to why the solution picked is the correct one. Solution (attempt): a) A router receives a packet with a Flow but has no state for it. b) sends the packet as if there is no flow but does one of the following: i) mark a bit in the Flow ID which says somebody on the flow has lost state (issue- security??) ii) encapsulate packet saying Flow ID has been lost (issue- Path-MTU) c) destination receives the packet and notices that Flow ID State has been lost. i) destination has data to send back to source so it can set a bit or somehow tell the source that the Flow ID needs to be reset. ii) its a one way flow and no data needs to be sent from the destination back to the source so a special message is sent saying the Flow ID needs to be reset. d) the source gets indication that the Flow ID needs to be reset and can take the proper action, whatever that is deemed to be. The RFC stated that just acting like there is no flow should be acceptable in most cases may not be correct. There may be some cases where flows are set up to avoid what would happen if there were no flows and so I would hope this problem could be solved. Anyways, comments are welcomed. >Flushing Old Flow IDs There was a comment regarding no source should send out any new flows for 2 minutes or so after rebooting. This seems like a long time. I think the time can be shortened for some stations by taking a couple of bits from the Flow ID and designating them as an incarnation field. Lets say the field is 3 bits, this gives me 8 incarnations before repeating. Everytime I reboot I increment the incarnation (assuming that I used a FLow with the previous incarnation). This gives a station the ability to start new Flows right after booting. This is just an idea, not sure how important it really is to start sending new Flows right after booting. -rich ------------------------------------------------------------------------------ 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 Nov 29 13:57:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26683; Tue, 29 Nov 94 13:57:59 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26677; Tue, 29 Nov 94 13:57:51 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA08979; Tue, 29 Nov 1994 13:51:38 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA25869; Tue, 29 Nov 94 13:52:25 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA28706 for ipng@sunroof.eng.sun.com; Tue, 29 Nov 94 16:23:01 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id NAA02053; Tue, 29 Nov 1994 13:21:18 -0800 Message-Id: <199411292121.NAA02053@aland.bbn.com> To: kck@netcom.com Cc: ipng@sunroof.Eng.Sun.COM Cc: end2end-interest@isi.edu Subject: Re: R: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of Tue, 29 Nov 94 11:10:43 -0800. <199411291910.LAA20180@netcom17.netcom.com> From: Craig Partridge Date: Tue, 29 Nov 94 13:21:10 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Richard: Glad you found the draft useful. I don't think there's any significant piece of the discussion that isn't reflected in some way the RFC, but I'll try to think about that issue as I revise it. As I read your note, it appears to be asking two basic questions (correct me if I'm wrong here): 1. Do we really believe that the normal best case approach to recovery is just to forward the datagram? 2. What's wrong with an approach where the router signals to the receiver that it lacks state? Let me try to answer each in turn: 1. Yes, the concensus of the meeting seemed to be that, in *most* (not all) cases, if you forwarded the datagram, you'd be doing better than if you had not forwarded it. Part of this concensus came from the belief that in many cases, examining the options in the datagram might tell you enough to make a good guess about how to handle the datagram. 2. There's nothing wrong with routers signalling to the receiver. The only thing the memo implies is that if one wants to do this, one has to define an option (say the "Flow ID Recovery Option") that has the necessary signalling bits in it. Does this sound reasonable to you? Craig ------------------------------------------------------------------------------ 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 Nov 29 14:07:51 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26698; Tue, 29 Nov 94 14:07:51 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26692; Tue, 29 Nov 94 14:07:43 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA10192; Tue, 29 Nov 1994 14:01:31 -0800 Received: from KARIBA.BBN.COM by Sun.COM (sun-barr.Sun.COM) id AA28060; Tue, 29 Nov 94 14:02:38 PST Message-Id: <9411292202.AA28060@Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of Tue, 29 Nov 94 11:10:38 -0800. <199411291910.LAA01892@aland.bbn.com> Date: Tue, 29 Nov 94 17:02:27 -0500 From: Isidro Castineyra Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, Sorry, I was not clear. Let me try again. I like the first part: 2. Flow IDs should expire if not refreshed within some number of minutes (the exact number needs some more consideration). The next part is confusing; it can be read as mandating a specific mechanism to avoid duplicate Flow IDs. and flow sources should observe a quiet time equal to this ^^^^^^ interval after rebooting to avoid confusing Flow IDs (unless the source keeps track of Flow IDs across reboots). I would prefer making this read more like a suggestion. For example Flow IDs expiring make possible a simple mechanism to guarantee unique Flow IDs: after rebooting, sources can observe a quiet time equal to the time-out interval. Other mechanisms are possible. The exact mechanism(s) a source uses to guarantee unique Flow IDs is "out of scope," I believe. Isidro >>Hi Isidro: >> >> The idea is that yes there are several mechanisms. This one is >>simple, it is known to work, and the E2E group was comfortable with it, >>and so that's what the E2E recommended. >> From owner-ipng Tue Nov 29 14:08:27 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26710; Tue, 29 Nov 94 14:08:27 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26704; Tue, 29 Nov 94 14:08:14 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA10261; Tue, 29 Nov 1994 14:02:02 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA28134; Tue, 29 Nov 94 14:02:55 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09384; 29 Nov 94 15:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-simpson-ipv6-discov-process-01.txt Date: Tue, 29 Nov 94 15:19:02 -0500 Message-Id: <9411291519.aa09384@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 : IPv6 Neighbor Discovery -- Processing Author(s) : W. Simpson Filename : draft-simpson-ipv6-discov-process-01.txt Pages : 46 Date : 11/28/1994 This document discusses the implementation 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 a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-ipv6-discov-process-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-ipv6-discov-process-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-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: <19941128120607.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-discov-process-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-discov-process-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941128120607.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 Nov 29 14:25:02 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26757; Tue, 29 Nov 94 14:25:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26751; Tue, 29 Nov 94 14:24:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA11954; Tue, 29 Nov 1994 14:18:41 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA01205; Tue, 29 Nov 94 14:19:25 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA20630; Wed, 30 Nov 1994 09:19:16 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA22512; Wed, 30 Nov 94 10:17:04 +1100 Message-Id: <9411292317.AA22512@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Wed, 30 Nov 94 09:29:01 AUS Date: Wed, 30 Nov 94 09:18:38 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: R: (IPng) mechanisms for managing the flow ID field in IPv6 To: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Re Flows. this may be a negative note on flows but it seems the benefit of this Flow Id stuff is totally buried by the complexity of its implementation. Given that flow ids have to be managed across the total Internet from source to destination for all hosts for all their own flow ids, I just cannot see how this will work reliably. I made comments on flow ids early on saying that flow / QOS should be defined in a global way (like "real time", "bulk", etc) as per TOS and Tclass, BUT is processed in the local context. This totally minimises all the management issues within the network and reduces the complexity within the hosts. Also this QOS issue will affect the migration / integration of IP4 and IP6 networks so I believe that minimal changes in concepts, mechanisms and management (of the mechanisms) is the best way to go. And to be open about this, what is the basic requirement? Is it just to process some IP packets which are queued ahead of others - consistently.? 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 Nov 29 14:34:56 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26784; Tue, 29 Nov 94 14:34:56 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26766; Tue, 29 Nov 94 14:34:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA12698; Tue, 29 Nov 1994 14:28:18 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA02890; Tue, 29 Nov 94 14:29:24 PST Received: from LapTop.Simpson.DialUp.Mich.Net (pm036-13.dialip.mich.net [141.211.7.55]) by merit.edu (8.6.9/merit-2.0) with SMTP id RAA02875 for ; Tue, 29 Nov 1994 17:29:21 -0500 Date: Tue, 29 Nov 94 04:15:41 GMT From: "William Allen Simpson" Message-Id: <1227.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) packs Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Just read the pack draft. As far as I can tell, they are identical to Clusters. I don't understand why it is a separate draft. Bob Hinden should take the text, and incorporate it word for word in the address draft (giving acknowlegement for the textual contribution, of course). 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 Nov 29 17:02:01 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26912; Tue, 29 Nov 94 17:02:01 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26906; Tue, 29 Nov 94 17:01:49 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA26698; Tue, 29 Nov 1994 16:55:37 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA27752; Tue, 29 Nov 94 16:56:30 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09456; 29 Nov 94 15:19 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-simpson-ipv6-mobility-00.txt Date: Tue, 29 Nov 94 15:19:31 -0500 Message-Id: <9411291519.aa09456@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 Mobility Support Author(s) : W. Simpson Filename : draft-simpson-ipv6-mobility-00.txt Pages : 27 Date : 11/28/1994 This document specifies protocol enhancements that allow transparent routing of IPv6 datagrams to Mobile Nodes in the Internet. The Mobile Node is always identified by its Home-Address, regardless of its current point of attachment to the Internet. While situated away from its home, a Mobile Node is also associated with a Care-Of-Address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the Care-Of-Address with a Home Agent. The Home Agent sends traffic destined for the Mobile Node through a tunnel to the Care-Of-Address. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-ipv6-mobility-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-ipv6-mobility-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-mobility-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: <19941128142331.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-mobility-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-mobility-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941128142331.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 Nov 29 19:48:40 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26950; Tue, 29 Nov 94 19:48:40 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26944; Tue, 29 Nov 94 19:48:30 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA09779; Tue, 29 Nov 1994 19:42:18 -0800 Received: from netcom12.netcom.com by Sun.COM (sun-barr.Sun.COM) id AA21548; Tue, 29 Nov 94 19:43:25 PST Received: by netcom12.netcom.com (8.6.9/Netcom) id TAA14837; Tue, 29 Nov 1994 19:27:18 -0800 Date: Tue, 29 Nov 1994 19:27:18 -0800 From: kck@netcom.com (Richard Fox) Message-Id: <199411300327.TAA14837@netcom12.netcom.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: R: (IPng) mechanisms for managing the flow ID field in IPv6 Cc: end2end-interest@isi.edu Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > 1. Yes, the concensus of the meeting seemed to be that, in *most* (not >all) cases, if you forwarded the datagram, you'd be doing better than >if you had not forwarded it. I have no problem with this. An attempt to deliver the packets is a good thing. >2. There's nothing wrong with routers signalling to the receiver. The >only thing the memo implies is that if one wants to do this, one has >to define an option (say the "Flow ID Recovery Option") that has >the necessary signalling bits in it. I think this is a reasonable thing to strive for. This will allow situations that cause number 1 to do bad things to hopefully recover gracefully. I guess what I was asking or hoping to see is this mechanism defined in the information RFC, or at least strongly suggested (since it is only an informational RFC). Since there was no discussion regarding this option it implies that the the E2E group had made a proposal with no fix for a real problem. It would be my goal to add a ral fix at some point time into the RFC. >Does this sound reasonable to you? Sounds like things are moving in the right direction. >Craig --rich ------------------------------------------------------------------------------ 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 Nov 30 02:06:42 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27043; Wed, 30 Nov 94 02:06:42 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27037; Wed, 30 Nov 94 02:06:34 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA20553; Wed, 30 Nov 1994 02:00:22 -0800 Received: from dworkin.wustl.edu by Sun.COM (sun-barr.Sun.COM) id AA23760; Wed, 30 Nov 94 02:01:28 PST Received: (from zubin@localhost) by dworkin.wustl.edu (8.6.8.1/8.6.6.yuck) id DAA22088; Wed, 30 Nov 1994 03:39:13 -0600 From: Zubin Dittia Message-Id: <199411300939.DAA22088@dworkin.wustl.edu> Subject: (IPng) Re: Deering's comments on flow ID management To: craig@aland.bbn.com (Craig Partridge) Date: Wed, 30 Nov 1994 03:39:12 -0600 (CST) Cc: int-serv@ISI.EDU, end2end-interest@ISI.EDU, flows@research.ftp.com, ipng@sunroof.Eng.Sun.COM In-Reply-To: <199411291911.LAA01899@aland.bbn.com> from "Craig Partridge" at Nov 29, 94 11:11:47 am Organization: Washington University in St. Louis Phone: (314)-935-4163 (off), (314)-962-4176 (res) X-Z: I will not be pushed, filed, stamped, indexed, briefed, debriefed, X-Z: or numbered. My life is my own. X-Mailer: ELM [version 2.4 PL23] 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 > The only credible argument I have heard for labelling every TCP connection > with a unique flow ID is for efficient demux at the receiver. And I don't > know how much of a performance improvement that would buy, given that folks > have already implemented zero-copy TCPs under IPv4, which does not have > flow IDs. Setting the Flow Label to zero for packets not belonging to a flow seems wasteful; it would be nice if there were some way to differentiate between "network" flows (i.e., flows that need to be regarded as flows by both routers and end-points), and "end-flows" (i.e., flows that are regarded as flows only by the end-points, and not by the routers). If this could be done (perhaps by means of a bit in either the Flow ID or the TClass fields), then we can get the advantage of efficient demuxing at the receiver, without the drawback of cache explosion in the routers. That would argue for letting every TCP connection have its own Flow ID. Regarding the usefulness of interpreting flow IDs in the end-host's network adapter, the potential is always there, and goes beyond just achieving zero-copies. For example, the flow ID field could be used by a network adapter to know where to look in the packet for specific information that can be interpreted by the adapter. This would allow, for example, the source of a flow to control when an interrupt is issued by the network adapter on the destination host; such a feature can be immensely useful in reducing the number of interrupts that are issued. Another example is with distributed shared memory, where the flow ID could be used to find where the data resides in the packet, and to DMA that data directly to its destination address in the host's memory. -Zubin. ------------------------------------------------------------------------------ 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 Nov 30 02:17:54 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27056; Wed, 30 Nov 94 02:17:54 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27050; Wed, 30 Nov 94 02:17:46 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA20765; Wed, 30 Nov 1994 02:11:34 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA24497; Wed, 30 Nov 94 02:12:38 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA07264; Wed, 30 Nov 1994 15:50:46 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA22732; Wed, 30 Nov 94 12:17:30 +1100 Message-Id: <9411300117.AA22732@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Wed, 30 Nov 94 11:29:29 AUS Date: Wed, 30 Nov 94 10:51:31 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: (IPng) WWW home page To: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM my thoughts on the migration issues. The points stated that IP6 is compatible with IP4 because of tunnelling, dual stacks, address mapping, etc and that this will be provided through upgrades, etc. Is like saying the mechanism is there to permit all the parts on a jumbo jet to be replaced through an upgrade process in the hangar. The unfortunate issue to me is that all the IP networks are operational and their addresses in many cases are applied incorrectly with respect to their location/ region. eg use private A, and B class addresses, there are duplicate address networks, there are multiple product sources and have random connectivity and network reachability. There is also a cost issue and service outage issue. I believe the real issue with IP4-6 is an operational one in that how does one upgrade an operational network with 100m nodes on it. Referencing this to the jumbo notion above, I see the problem as how does one upgrade Boeings fleet while it is still in the air. Perhaps this statement may be dramatic, but preference to approaching the transition and infact IP6 is to see what the operational issues are of the Internet and IP. eg addressing, management, accounting and security plus some form of QOS mechanism. The upgrade and the new IP design should therefore be: eg. addressing. what is the best way of Operationally upgrading the addressing scheme, and this must be performed through regional allocation of addressing space and those regions provide gateways at strategic points in the network so that each region can plan and perform its own address and IP upgrades whilst maintaining an operational internet, etc ( This issue is to big to detail in a post so can be discussed at SJ.) So bottom lines again. I am uncomfortable developing protocols to solve a scaling (addressing) and operational problem (security, accounting, mobility) on the scale it is without understanding the methodology and approach to managing the address administration of IP4 to IP6 and the issues of overall network management design for the network functions needed. Being remote from the IETF process though - at this point in time, perhaps these concerns are unjustified. If people are interested in chalking and talking on this at SJ, please contact me. Some food for thought. We had the notion of using NSAPs (ICD or DCC forms) at the core of the IP networks (an IP+) with IP subnets on the edge. Thus the network from an addressing point would be E.164 switched ISDN carrier numbering plans which map/support ISO NSAPs - ICD, DCC and even E164 forms - these provide the global address forms as needed and then map this to IP subnets on the edge. Getting the IP6 address forms to relate to NSAP forms make a lot of problems go away WRT the admin and address and network design and migration issues and better mapping to switched network services. Please do not flame me on this one, because operationally it is being seen to be a good approach. 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 Nov 30 06:34:16 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27187; Wed, 30 Nov 94 06:34:16 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27181; Wed, 30 Nov 94 06:34:09 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA26859; Wed, 30 Nov 1994 06:27:55 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA17373; Wed, 30 Nov 94 06:28:52 PST Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA05843 for ipng@sunroof2.eng.sun.com; Wed, 30 Nov 94 09:28:35 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id GAA02613; Wed, 30 Nov 1994 06:26:52 -0800 Message-Id: <199411301426.GAA02613@aland.bbn.com> To: Alan.Lloyd@datacraft.com.au To: ipng@sunroof2.Eng.Sun.COM Subject: re: R: (IPng) mechanisms for managing the flow ID field in IPv6 From: Craig Partridge Date: Wed, 30 Nov 94 06:26:45 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > this may be a negative note on flows but it seems the benefit of this Flow Id > stuff is totally buried by the complexity of its implementation. Given that > flow ids have to be managed across the total Internet from source to > destination for all hosts for all their own flow ids, I just cannot see how > this will work reliably. Alan: Thanks for your note. I'm racing out the door to a day long meeting today but let me try to quick reply to two points. First, about Flow IDs. Managing Flow IDs is trivial -- uniqueness is guaranteed by combination of source address + flow ID. There's no complexity here except to guard against reuse. One of the points of the memo I sent around was to point out that the reuse problem is straightforward. Second, regarding QoS. The notion of Flows responds to the discovery that for real-time services, simple QoS doesn't express a wide enough range of performance characteristics -- that there's a lot of information you want to give the network about your needs, so individual nodes can tune their queueing to the application's needs. (This is all straightforward stuff -- there's been a lot published on how to do this over the past 5 years -- see, for instance, chapters 11-13 of my book, Gigabit Networking [and apologies for the plug - if I had longer, I'd try to create a reading list]). Hope this is useful! Craig ------------------------------------------------------------------------------ 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 Nov 30 10:15:38 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27435; Wed, 30 Nov 94 10:15:38 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27154; Wed, 30 Nov 94 06:00:37 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id FAA25431; Wed, 30 Nov 1994 05:54:24 -0800 Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM) id AA13722; Wed, 30 Nov 94 05:55:31 PST Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA00724; Wed, 30 Nov 94 08:46:30 EST Received: from maggie.wellfleet by wellfleet (4.1/SMI-4.1) id AA26961; Wed, 30 Nov 94 08:46:53 EST Date: Wed, 30 Nov 94 08:46:52 EST From: jkrawczy@pobox.wellfleet.com (John Krawczyk) Message-Id: <9411301346.AA26961@wellfleet> Received: by maggie.wellfleet (4.1/SMI-4.1) id AA01447; Wed, 30 Nov 94 08:55:08 EST To: ipng@sunroof.Eng.Sun.COM Subject: re: R: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: <9411292317.AA22512@cms.datacraft.com.au> References: <9411292317.AA22512@cms.datacraft.com.au> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Re Flows. Alan, I'd suggest that, if you haven't done so, you should check out the work of the int-serv and rsvp working groups to see why this approach is being taken rather than just tagging packets in a global way (and check out the "flows" and "nimrod" archives too). -jj ------------------------------------------------------------------------------ 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 Nov 30 10:50:49 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27499; Wed, 30 Nov 94 10:50:49 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27493; Wed, 30 Nov 94 10:50:36 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA16366; Wed, 30 Nov 1994 10:44:23 -0800 Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA03675; Wed, 30 Nov 94 10:45:29 PST Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id JAA12104; Wed, 30 Nov 1994 09:41:51 -0800 Date: Wed, 30 Nov 1994 09:41:51 -0800 From: Tony Li Message-Id: <199411301741.JAA12104@lager.cisco.com> To: craig@aland.bbn.com Cc: end2end-interest@ISI.EDU, ipng@sunroof.Eng.Sun.COM, flows@research.ftp.com, int-serv@ISI.EDU In-Reply-To: Craig Partridge's message of Tue, 29 Nov 94 09:12:15 -0800 <199411291712.JAA01689@aland.bbn.com> Subject: (IPng) mechanisms for managing the flow ID field in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Craig, The argument against using Flow IDs in individual TCP connections is that it changes how we handling route caches in routers. Currently one can cache a route for a destination host, regardless of how many different sources are sending to that destination host. I.e., if five sources each have two TCP connections sending data to a server, one cache entry containing the route to the server handles all ten TCPs' traffic. Putting Flow IDs in each datagram changes the cache into a Flow ID cache, in which there is a cache entry for every TCP connection. So there's a potential for cache explosion. (One can alleviate this slightly by having the multiple Flow ID cache entries for the same destination point to the same routing entry, but there's still some cost). I take issue with this because it seems to preclude (or at least ignore) the obvious implementation. The flow ID cache may be a fixed-sized LRU cache in front of the existing destination cache. I don't believe there's even an issue here... just a clearly solvable implementation problem. 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 Nov 30 14:58:59 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27841; Wed, 30 Nov 94 14:58:59 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27834; Wed, 30 Nov 94 14:58:50 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA11373; Wed, 30 Nov 1994 14:52:35 -0800 Received: from relay.hp.com by Sun.COM (sun-barr.Sun.COM) id AA21847; Wed, 30 Nov 94 14:53:41 PST Received: from hpindlm.cup.hp.com by relay.hp.com with ESMTP (1.37.109.13/15.5+ECS 3.3) id AA198646019; Wed, 30 Nov 1994 14:53:40 -0800 Received: by hpindlm.cup.hp.com (1.37.109.11/15.5+IOS 3.20+cup+OMrelay) id AA262636016; Wed, 30 Nov 1994 14:53:36 -0800 Date: Wed, 30 Nov 1994 14:53:36 -0800 From: Wan-Yen Hsu Message-Id: <199411302253.AA262636016@hpindlm.cup.hp.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Unsolicited General Advertisements Cc: wanyen@hpindlm.cup.hp.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM At Hewlett-Packard a few of us have been studying the latest version of "IPv6 Neighbor Discovery -- Processing," which appears to disallow the use of unsolicited general advertisements: > IPv6 Neighbor Discovery -- Processing > draft-simpson-ipv6-discov-process-01.txt > 7. Sending General Advertisements > Every IPv6 MUST implement General Advertisements. > A General Advertisement is only sent in response to a General Solicitation. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^'' This restriction prohibits a node from notifying others of a change to its binding between an IP address and an media address. A node may have multiple interface cards over the same link to provide a highly available network configuration. When one interface card fails, it may move the IP address associated with the failed card to another card. In order to make clients aware of this change an unsolicited General Advertismement should be allowed and sent by a node to the "All-Node multicast address" with "intra-link" scope. Clients can then change their IP address <-> MAC address binding. On receipt of a General Advertisement, regardless of whether it is solicited or unsolicited, all nodes which have a Hop Cache entry for the Source field address specified in the General Advertisement should update the cache entry with the current information in the newly arrived General Advertisement. Chuck DeSostoa Wan-yen Hsu Brad Stone Hewlett Packard ------------------------------------------------------------------------------ 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 Nov 30 16:12:09 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27982; Wed, 30 Nov 94 16:12:09 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27976; Wed, 30 Nov 94 16:12:00 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA18417; Wed, 30 Nov 1994 16:05:46 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA06099; Wed, 30 Nov 94 16:06:39 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14690(5)>; Wed, 30 Nov 1994 16:06:20 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12173>; Wed, 30 Nov 1994 16:06:06 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: rcallon@pobox.wellfleet.com, deering@parc.xerox.com, hinden@Eng Subject: (IPng) soliciting IPng agenda items Date: Wed, 30 Nov 1994 16:05:59 PST From: Steve Deering Message-Id: <94Nov30.160606pst.12173@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The ipng working group has four meeting slots scheduled for San Jose (Mon 1:30-3:30, Mon 4-6, Tue 4-6, Wed 9:30-12). The ipng chairs and editor are finally getting around to putting together an agenda for the meetings, so if you have any specific topics that you want covered, please send a note to Ross Callon, Bob Hinden and me (our email addresses are in the cc line of this message). Topics specific to transition, address lifetime, address autoconfiguration, or IPng-OSI interoperation should be directed to the appropriate WG or BOF (ngtrans, tacit, ale, addrconf, or nosi), rather than the general ipng WG. Reminder to implementors: Jim Bound is again organizing a couple of IPng implementors' meetings (Sun 1-6, Fri 9-12), in the Garden Room at the same hotel as the IETF meetings. Presumably, the agenda for those meetings will be constructed in real time, as has been the practice in the past. 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 Wed Nov 30 16:45:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28006; Wed, 30 Nov 94 16:45:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28000; Wed, 30 Nov 94 16:45:27 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA21475; Wed, 30 Nov 1994 16:39:13 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA12309; Wed, 30 Nov 94 16:40:01 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA22743; Thu, 1 Dec 1994 11:39:07 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA24867; Thu, 1 Dec 94 11:51:00 +1100 Message-Id: <9412010051.AA24867@cms.datacraft.com.au> Received: by dcthq2.datacraft.com.au with VINES ; Thu, 1 Dec 94 11:03:19 AUS Date: Thu, 1 Dec 94 09:09:00 AUS From: Alan.Lloyd@datacraft.com.au Subject: re: (IPng) mechanisms for managing the flow ID field in IPv6 To: ipng@sunroof2.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM This flow id and its implementation. The problem is not one of cache explosion, it is one of: 100m users on a global internet and all of them controlling flow across the whole of the internet for all the random paths they use to all their random destinations for all their applications. Will this lead to: 50% of Internet traffic = users traffic 50% of Internet traffic = SNMP polls and flow Id management and 50% of router burn trying to cope with managing flows. Just a thought. Is the solution worse than the problem? 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 Nov 30 17:12:36 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28041; Wed, 30 Nov 94 17:12:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28035; Wed, 30 Nov 94 17:12:27 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA24186; Wed, 30 Nov 1994 17:06:14 -0800 Received: from uu2.psi.com by Sun.COM (sun-barr.Sun.COM) id AA16479; Wed, 30 Nov 94 17:06:58 PST Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA22219 for ipng@sunroof.eng.sun.com; Wed, 30 Nov 94 20:03:25 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id RAA02781; Wed, 30 Nov 1994 17:01:43 -0800 Message-Id: <199412010101.RAA02781@aland.bbn.com> To: ipng@sunroof.Eng.Sun.COM Cc: craig@aland.bbn.com, end2end-interest@ISI.EDU, flows@research.ftp.com, int-serv@ISI.EDU Subject: Re: (IPng) mechanisms for managing the flow ID field in IPv6 In-Reply-To: Your message of Wed, 30 Nov 94 09:41:51 -0800. <199411301741.JAA12104@lager.cisco.com> From: Craig Partridge Date: Wed, 30 Nov 94 17:01:18 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The argument against using Flow IDs in individual TCP connections is that it changes how we handling route caches in routers. Currently one can cache a route for a destination host, regardless of how many different sources are sending to that destination host. I.e., if five sources each have two TCP connections sending data to a server, one cache entry containing the route to the server handles all ten TCPs' traffic. Putting Flow IDs in each datagram changes the cache into a Flow ID cache, in which there is a cache entry for every TCP connection. So there's a potential for cache explosion. (One can alleviate this slightly by having the multiple Flow ID cache entries for the same destination point to the same routing entry, but there's still some cost). I take issue with this because it seems to preclude (or at least ignore) the obvious implementation. The flow ID cache may be a fixed-sized LRU cache in front of the existing destination cache. Hi Tony: I think this note misunderstands the problem (or are using a different architecture base). The idea behind this is the following. Take Van J's fast IP forwarding code and write it up in assembler for your favorite current processor. What you'll discover is that, in almost all cases, you are memory bound not instruction bound. I.e. the instruction count is small and you're usually running in-cache instructions, and so the key performance issue is how likely is your routing table entry to be in the primary cache in the processor? Provided your cache hit rate is high, you run pretty quickly. OK, now the problem. Flows force one to split the first level cache into two caches -- one of flow IDs and one of routing entries (note if one is tricky, the flow ID table simply points to routing entries in the routing cache, which improves cache memory usage). But we're still smashing up our first level cache differently. What's more, the flow space is bigger, so rather than using the, say, 100 or 200 most recent routes (ala Feldmeier's and Mogul's studies), we may have to cache the most recent 200-500 flow IDs. This may overflow primary cache, and voila, performance goes down sharply. I believe there's an analog of this problem that crops up in other solutions (like the Cisco 7000). Craig ------------------------------------------------------------------------------ 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 Nov 30 19:24:57 1994 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28168; Wed, 30 Nov 94 19:24:57 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28162; Wed, 30 Nov 94 19:24:43 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA00871; Wed, 30 Nov 1994 19:18:29 -0800 Received: from lager.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA03547; Wed, 30 Nov 94 19:19:30 PST Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA05368; Wed, 30 Nov 1994 18:44:43 -0800 Date: Wed, 30 Nov 1994 18:44:43 -0800 From: Tony Li Message-Id: <199412010244.SAA05368@lager.cisco.com> To: craig@aland.bbn.com Cc: ipng@sunroof.Eng.Sun.COM, craig@aland.bbn.com, end2end-interest@ISI.EDU, flows@Research.Ftp.Com, int-serv@ISI.EDU In-Reply-To: Craig Partridge's message of Wed, 30 Nov 94 17:01:18 -0800 <199412010101.RAA02781@aland.bbn.com> Subject: (IPng) mechanisms for managing the flow ID field in IPv6 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hi Craig, I think this note misunderstands the problem (or are using a different architecture base). Thanks for the explanation, yes, it's the latter. From your explanation, you're assuming a zero-sum game, which is not necessarily the case. I concur that it would be a problem in a zero-sum architecture. I believe there's an analog of this problem that crops up in other solutions (like the Cisco 7000). Not directly, because in the 7000 all caches occupy independent memories. 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