From owner-ipng@sunroof.eng.sun.com Sun Mar 1 00:25:37 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id AAA29527 for ipng-dist; Sun, 1 Mar 1998 00:20:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id AAA29520 for ; Sun, 1 Mar 1998 00:20:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA11346 for ; Sun, 1 Mar 1998 00:20:07 -0800 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA08274 for ; Sun, 1 Mar 1998 00:20:03 -0800 (PST) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id AAA02408; Sun, 1 Mar 1998 00:19:58 -0800 (PST) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.6.9) id AAA27506; Sun, 1 Mar 1998 00:19:57 -0800 (PST) From: Vivek Kashyap Message-Id: <199803010819.AAA27506@eng4.sequent.com> Subject: (IPng 5243) internet draft 'Modification in Datagram Too Big message' To: ipng@sunroof.eng.sun.com Date: Sun, 1 Mar 1998 00:19:57 -0800 (PST) Cc: viv@sequent.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I have written an Internet draft suggesting some changes in the ICMP 'Datagram too big' error message and handling: Modification in Datagram Too Big message While recently implementing the path MTU discovery feature, I reasoned that its implementation is costly for large servers with 1000s of connections but only a few routes. This is because the current protocol specifies per host route/path creation. My draft suggests route aggregation into net routes rather than creating host routes. I welcome comments on my suggestion. The draft is attached below. Thanks Vivek Kashyap viv@sequent.com ------ begin of draft-kashyap-too-big-00.txt -- ascii -- complete ------ Network Working Group V. Kashyap INTERNET DRAFT Sequent Computer Systems Expiration date: 9 August 1998 9 Feb 1998 Modification in Datagram Too Big message 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, and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts shadow directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo describes a small modification in the 'Datagram Too Big' message for both the IPv4(ICMPv4) and IPv6(ICMPv6) standards. The document addresses possible reduction in resources on large servers when implementing the Path MTU discovery process. Table of Contents 1. Introduction 2. Changes to Datagram Too Big message 2.1 IPv6 Datagram Too Big message 2.2 IPv4 Datagram Too Big message 3. Router specification 4. Impact on host implementation of Path MTU Discovery 5. Security Considerations 6. References 7. Author's Address 1. Introduction When one IP host has a large amount of data to send to another host, the data is transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the MTUs of each hop in the path. This shortcoming is overcome by the use of the path MTU discovery process as outlined in [1] and [2]. Datagram Too Big is defined in [1] and [2]. With the current specification of Datagram too Big the source host gets to know that there is a bottleneck in the path somewhere. It cannot aggregate this information to share with other connections (unless they are to the same destination). Thus the source host has to cache the path information on a per host basis. Any representation for the path may be used but in all the current implementations (that I am aware of) of Path MTU discovery the path information is kept as a routing table entry. The receipt of a Datagram Too Big message causes a routing table entry to be created for the destination host. Any reduction in this table size reduces the resources utilized to keep this information and in searching through the large routing table. The suggestion in this document is to attain the following advantages : . Aggregation of paths having the same PMTU . Reduction in resources utilized to store the Path MTU . Speed up in the MTU updates to all connections on a host rather than each discovering it independently. . On deletion of a network route on the host, each of the derived routes/paths has to be deleted too. With the reduction in the number of such caches it would take less time and simpler algorithms can be used. . utilities need to list a smaller set of routes. eg. netstat. . routing protocols need to exchange smaller tables and/or not weed through a large set of derived routes. 2. Changes to Datagram Too Big message 2.1 IPv6 'Datagram too Big' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Pri | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: 2 | mask code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Transmission Unit Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The mask translates as: prefix mask = -1 << mask code With the addresses being 128 bits long the code required in 8 bits long which fits in the unused ICMP code octet. The route/path for the Path MTU process is identified using the final destination address ANDed to the number of prefix bits. The path/route may also include the flow id [3] but that does not effect this discussion. It is yet another component of the path identification. A mask code of 0 implies all 1s ie. a host route. This is exactly same behaviour as the current definition. A value of 128 implies that the router used its default route. An indication of default route does not provide any information though. It can be considered to be equivalent to the host route case. If the ICMP message is received as a response to a Multicast address the prefix mask information may not be useful. 2.2 IPv4 'Datagram too Big' 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Code = 4 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask code | Next-Hop MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Datagram Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The mask code is defined as follows : Code Mask Comment ---- ----- ------- 0 255.255.255.255 host route (default) 32 0.0.0.0 default route 31 128.0.0.0 . . . 8 255.255.255.0 . . . 1 255.255.255.254 The above table is determined : mask = -1 << mask code The route/path MTU cache entry is identified by the final destination AND the mask. 3. Router specification The router in addition to returning the next hop MTU (as is done now) returns the mask code. The mask code as per the table 1, informs the end host of the net mask used by the router in determining the path to the final destination. IPv4 Currently the routers return 0 in the 16 bits used by the mask code. Hence a router implementing the existing ICMP Datagram too Big message will be interpreted exactly as now ie. create a host specific route (or Path MTU cache). IPv6 Currently the 8 bits for the icmp code are unused. Hence a router implementing the existing ICMP Datagram too Big message will be interpreted exactly as now ie. create a host specific route (or Path MTU cache). 4. Impact on host implementation of Path MTU Discovery When a host receives Datagram Too Big message for a connection it has no way of knowing whether the subnet the peer belongs to is behind the bottleneck. As a result the host is forced to create a path specifically for the peer. This information cannot be shared with another connection attempted to another host which may be on the same sub network and behind the same bottleneck. With the modification suggested in section 2 such sharing of information becomes possible. 4.1 Case 1 Consider two different connections endpoint Ca to Cx and Cb to Cy. +----+ +------+ M1 +------+ +------+ +----+ | Ca |----->| Ra |----->| Rb |----->| Rc |---->| Cx | | Cb | | | | |----->| |--+ +____+ +____+ +------+ +------+ +------+ | | | V +------+ | Cy | +------+ fig 1 The first MTU reduction occurs on the path from Ra to Rb. Instead of creating a separate per path route for both Ca and Cb the host may keep both the connections using the same route (or any other cache to store the pmtu). Currently the host will have to create two entries, one for each connection. 4.2 Case 2 Routing change occurs such that the PMTU for Cb is M2 +----+ +------+ M1 +------+ +------+ +----+ | Ca |----->| Ra |----->| Rb |----->| Rc |---->| Cx | | Cb | | | | | | |--+ +____+ +____+ +------+ +------+ +------+ | | |M2 V +------+ | Cy | +------+ fig 2 A Datagram too Big message will be received for the connection Ca to Cb. The host can utilize the information in the 'mask code' to create a more specific route. The above two cases can be extended to 1000s to connections on the two paths considered. 4.3 Case 3 +----+ +------+ +------+ +------+ M1 +----+ | Ca |----->| Ra |----->| Rb |----->| Rc |---->| Cx | | Cb | | | | | | |--+ +____+ +____+ +------+ +------+ +------+ | | | Ha V +------+ | Cy | +------+ Hy fig 3 The route to Cx from Rc is determined by the route x.y.255.255 but the path to Cy is determined by x.y.z.255 (considering an IPv4 inter network. The PMTU to Cx is determined by M1 at Rc but the path to Cy is the same as the first hop MTU all the way from the host Ha. If the connection Ca to Cx is made first the Ha will have an entry corresponding to Ha to the network x.y.255.255. This will cause the connection to Cy to use the same information as determined for the connection to Cx. Similar situation can occur if the topology change occurred while the connections Ca-Cx, Cb-Cy were active as in fig 1 to fig 3. Since the information is shared between the connections it is possible that at the 10 minute interval (as suggested in [1] and [2]) host Ha may fail to determine the increased Path MTU to Hy. This problem can be avoided if the end hosts implement the policy: . on a new connection use a non-PMTU discovered route/path. . at every probe time (if the host has data to send) use the original route. This will cause a rediscovery of the paths. 4.4 Case 4 If the Datagram Too Big message returns the code indicating that the router used the default route, it may be taken equivalent to the indication of the use of a host route. If the information returned indicates a more general route than the route that was used then the information must be discarded and it be considered to be a host route mask. The local routing information is received using a routing protocol or set up by an administrator and must not be overridden. 5. Security considerations If the Datagram Too Big message returns a more general route than was used by the host, the indication is taken equivalent to the host route mask. This blocks the host from being fed faulty network information. The host may however be sent Datagram Too Big messages indicating the default route. The end host will end up creating host routes instead of subnet routes. This is no different from what happens now. A code that indicates a more precise route does not have any effect on theflow of data or the path MTU information related to the path. 6. References [1] J.Mogul, S.Deering. Path MTU Discovery, RFC 1191, November 1990. [2] J. McCann, S. Deering, J. Mogul. Path MTU Discovery for IP version 6. RFC 1981, August 1996 [3] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification" RFC 1883, December 1995. [4] Conta, A., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995. 7. Author's Address Vivek Kashyap Sequent Computer Systems, Inc. 15450, SW Koll Parkway Beaverton, OR 97006 ph. 503 - 578 3422 email: viv@sequent.com ------ end of draft-kashyap-too-big-00.txt -- ascii -- complete ------ -- Vivek Kashyap viv@sequent.com 503 578 3422 (office) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 2 04:15:37 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id EAA00266 for ipng-dist; Mon, 2 Mar 1998 04:12:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id EAA00259 for ; Mon, 2 Mar 1998 04:11:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA04179 for ; Mon, 2 Mar 1998 04:11:52 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA00742 for ; Mon, 2 Mar 1998 04:11:47 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA25226; Mon, 2 Mar 1998 07:11:43 -0500 (EST) Message-Id: <199803021211.HAA25226@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5245) Protocol Action: Management Information Base for IP Version 6: Textual Conventions and General Group to Proposed Standard Date: Mon, 02 Mar 1998 07:11:42 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved publication of the following Internet-Draft: o Management Information Base for IP Version 6: Textual Conventions and General Group as a Proposed Standard. o Management Information Base for IP Version 6: ICMPv6 Group as a Proposed Standard. These documents are the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The document "Management Information Base for IP Version 6: Textual Conventions and General Group" is one in the series of documents that provide MIB definitions for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. The document "Management Information Base for IP Version 6: ICMPv6 Group" is one in the series of documents that define various MIB object groups for IPv6. This particular document defines the ICMPv6 group of the IPv6 MIB. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed for the IESG by Juergen Schoenwaelder. It has also been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 2 04:42:17 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id EAA00298 for ipng-dist; Mon, 2 Mar 1998 04:33:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id EAA00291 for ; Mon, 2 Mar 1998 04:33:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA05193 for ; Mon, 2 Mar 1998 04:33:20 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA07529 for ; Mon, 2 Mar 1998 04:33:15 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA25721; Mon, 2 Mar 1998 07:33:10 -0500 (EST) Message-Id: <199803021233.HAA25721@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5246) Protocol Action: Generic Packet Tunneling in IPv6 Specification to Proposed Standard Date: Mon, 02 Mar 1998 07:33:10 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Generic Packet Tunneling in IPv6 Specification' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document specifies a method and generic mechanisms by which a packet is encapsulated and carried as payload within an IPv6 packet. The resulting packet is called an IPv6 tunnel packet. The forwarding path between the source and destination of the tunnel packet is called an IPv6 tunnel. The technique is called IPv6 tunneling. The document also discusses specific mechanisms for tunneling IPv6 and IPv4 packets. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 2 09:25:45 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA00638 for ipng-dist; Mon, 2 Mar 1998 09:19:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA00631 for ; Mon, 2 Mar 1998 09:19:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA01501 for ; Mon, 2 Mar 1998 09:19:08 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA06561 for ; Mon, 2 Mar 1998 09:19:05 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA06898; Mon, 2 Mar 1998 12:19:02 -0500 (EST) Message-Id: <199803021719.MAA06898@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5247) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-06.txt Date: Mon, 02 Mar 1998 12:19:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-06.txt Pages : 14 Date : 27-Feb-98 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. 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-ietf-ipngwg-ipv6-over-ppp-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-06.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. 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: <19980227143327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-over-ppp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980227143327.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 2 13:35:25 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA00988 for ipng-dist; Mon, 2 Mar 1998 13:27:03 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA00981 for ; Mon, 2 Mar 1998 13:26:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA12685 for ; Mon, 2 Mar 1998 13:26:49 -0800 Received: from kentrox.com (kentrox.kentrox.com [192.228.59.2]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA24164 for ; Mon, 2 Mar 1998 13:26:45 -0800 (PST) Received: from kentrox.com by kentrox.com (Smail-3.2.0.91 1997-Jan-14 #1) id ; Mon, 2 Mar 1998 13:26:42 -0800 (PST) Received: from localhost by kentrox.com (4.1/SMI-4.1_KTX1.1) id AA00767; Mon, 2 Mar 98 13:26:40 PST Date: Mon, 2 Mar 1998 13:26:40 -0800 (PST) From: Gary Hanson X-Sender: gary@skeeter Reply-To: Gary Hanson To: iesg@ns.ietf.org Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5248) Impact on existing TCP-MIB and UDP-MIB RFCs Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Per the last call request on the drafts for the IPV6-TCP-MIB and IPV6-UDP-MIB, I just have two very similar questions: - Will a new RFC be issued that includes both the existing TCP-MIB and the new IPV6-TCP-MIB, or will a new RFC be issued that just includes the new IPV6-TCP-MIB and references back to RFC 2012? - Will a new RFC be issued that includes both the existing UDP-MIB and the new IPV6-UDP-MIB, or will a new RFC be issued that just includes the new IPV6-UDP-MIB and references back to RFC 2013? I was unable to tell from the drafts which approach was going to be used, since both drafts say "It is assumed that the objects defined in this memo will eventually be defined in an update to [TCP MIB] (or [UDP MIB])." I am mainly curious from the point of view of whether RFC 2012 and 2013 are "short-timers" or should continue to be referenced by other MIBs for some period of time.... Regards, Gary ______ | /// | TM Gary Hanson gary@kentrox.com | ADC|Kentrox 14375 NW Science Park Dr. 503-641-3321 (FAX) |______| Portland, Oregon 97229 800-733-5511 x6333 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 2 23:33:51 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id XAA01559 for ipng-dist; Mon, 2 Mar 1998 23:29:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id XAA01552 for ; Mon, 2 Mar 1998 23:29:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA04387 for ; Mon, 2 Mar 1998 23:29:37 -0800 Received: from samar.sasi.com (sasi.com [164.164.56.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA17088 for ; Mon, 2 Mar 1998 23:29:23 -0800 (PST) Received: from sunc2.sasi.com (sunc2.sasi.com [10.0.32.2]) by samar.sasi.com (8.8.7/8.8.7) with ESMTP id MAA01592; Tue, 3 Mar 1998 12:58:24 +0530 Received: from lnxc37.sasi.com (lnxc37.sasi.com [10.0.32.37]) by sunc2.sasi.com (8.8.7/8.8.7) with ESMTP id MAA04056; Tue, 3 Mar 1998 12:59:36 +0530 (IST) From: Jayesh Shah Received: (from jvs@localhost) by lnxc37.sasi.com (8.8.7/8.8.5) id NAA01541; Tue, 3 Mar 1998 13:07:56 +0530 Message-Id: <199803030737.NAA01541@lnxc37.sasi.com> Subject: (IPng 5249) Queries related to NDISC and Proxy ND To: netdev@nuclecu.unam.mx (Linux Networking Mailing List) Date: Tue, 3 Mar 1998 13:07:56 +0530 (IST) Cc: ipng@sunroof.eng.sun.com (IPng Mailing List), kuznet@ms2.inr.ac.ru (A.N.Kuznetsov) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I have some more queries related to IPv6 NDISC specs. As per the neighbour draft, in the neighbour advt. messages, the bit "R" is supposed to tell the receiver whether the "sender" is a router or not. However, I'm not clear as to what does "sender" mean. Whether it is the source address in the received packet or the address specified in the "target" field of the message. As per the Linux IPv6 implementation, it relates the "R" bit with the "target" (This is my conclusion, seeing the code, Correct me if I am wrong). Is it right ? If it is right, should we set the "R" bit for the advertisements sent on behalf of some other nodes (doing proxy ND) ? I don't think we should if it is related to the "target". However, again Linux code sets it while doing proxy ND also. Any comments are welcome. Regards Jayesh -- Jayesh V. Shah, Networking Group, SAS, Bangalore Phone - +91-80-5281229/5281461 EXTN : 4202 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 3 09:44:18 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA01938 for ipng-dist; Tue, 3 Mar 1998 09:35:20 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id JAA01931 for ; Tue, 3 Mar 1998 09:35:14 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id JAA14178 for ; Tue, 3 Mar 1998 09:35:13 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08329; Tue, 3 Mar 1998 09:34:10 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id DAA01626 for ; Tue, 3 Mar 1998 03:28:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA24980 for ; Tue, 3 Mar 1998 03:28:46 -0800 Received: from ms2.inr.ac.ru (flint.inr.ac.ru [193.233.7.75]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id DAA16154 for ; Tue, 3 Mar 1998 03:28:30 -0800 (PST) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.12/ANK) id OAA20059; Tue, 3 Mar 1998 14:26:24 +0300 From: "A.N.Kuznetsov" Message-Id: <199803031126.OAA20059@ms2.inr.ac.ru> Subject: (IPng 5251) Re: Queries related to NDISC and Proxy ND To: jvs@sasi.com (Jayesh Shah) Date: Tue, 3 Mar 1998 14:26:23 +0300 (MSK) Cc: netdev@nuclecu.unam.mx, ipng@sunroof.eng.sun.com In-Reply-To: <199803030737.NAA01541@lnxc37.sasi.com> from "Jayesh Shah" at Mar 3, 98 01:07:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > As per the Linux IPv6 implementation, it relates the "R" bit with the > "target" (This is my conclusion, seeing the code, Correct me if I am > wrong). Is it right ? It is right. IPv6 header is tested on validity, but not more. > If it is right, should we set the "R" bit for the advertisements sent > on behalf of some other nodes (doing proxy ND) ? I don't think we > should if it is related to the "target". However, again Linux code > sets it while doing proxy ND also. And it is bug. Thank you. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 3 11:53:58 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA02183 for ipng-dist; Tue, 3 Mar 1998 11:48:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA02176 for ; Tue, 3 Mar 1998 11:48:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA10827 for ; Tue, 3 Mar 1998 11:48:41 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA23557 for ; Tue, 3 Mar 1998 11:48:21 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id UAA10285; Tue, 3 Mar 1998 20:48:15 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA15876; Tue, 3 Mar 1998 20:48:14 +0100 (MET) Message-Id: <199803031948.UAA15876@givry.inria.fr> From: Francis Dupont To: "A.N.Kuznetsov" cc: jvs@sasi.com (Jayesh Shah), netdev@nuclecu.unam.mx, ipng@sunroof.eng.sun.com Subject: (IPng 5252) Re: Queries related to NDISC and Proxy ND In-reply-to: Your message of Tue, 03 Mar 1998 14:26:23 +0300. <199803031126.OAA20059@ms2.inr.ac.ru> Date: Tue, 03 Mar 1998 20:48:12 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have reread the last draft about the "R" bit in neighbor advertisement. It is relative to the sender and not to the target but the processing rules are obviously more for the target. Only one case is a problem, when a host sends a proxy advertisement for a router BUT the draft says "a router MAY proxy" then this should not happen, ie there is only one case of mismatch it is R bit set for a host target. Hosts on a link use router advertisement for everything with the R bit reset exception then I can't see any real problem. Regards Francis.Dupont@inria.fr PS: if the draft should be improved, just add that proxy advertisement MUST NOT be sent by a host. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 07:28:51 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA04856 for ipng-dist; Thu, 5 Mar 1998 07:24:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA04849 for ; Thu, 5 Mar 1998 07:24:03 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA00443 for ; Thu, 5 Mar 1998 07:24:01 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA12103 for ; Thu, 5 Mar 1998 07:24:00 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id KAA06789 for ; Thu, 5 Mar 1998 10:23:59 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21214; Thu, 5 Mar 1998 10:23:59 -0500 Message-Id: <199803051523.AA21214@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5255) ICMP Dst Unreachable for Link-Local and Site-Local Addresses Date: Thu, 05 Mar 1998 10:23:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Another impelementation issue. A router will not forward a link-local address off the link or a site-local address out of the site. The packet is dropped. Seems we should get either an ICMP Dst Unreachable or possibly some new ICMP informative error message. Also if we permit (per the other mail thread) for Hosts to send with lesser scope for src than dst like site == src and global == dst the packet will get dropped at the border or site router. The end result in both cases is no error message to the user and the connection will time out. But no one will no why. It seems prudent the routers should send an ICMP msg. Comments? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 07:28:50 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA04847 for ipng-dist; Thu, 5 Mar 1998 07:20:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA04840 for ; Thu, 5 Mar 1998 07:20:28 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29246 for ; Thu, 5 Mar 1998 07:20:27 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA09895 for ; Thu, 5 Mar 1998 07:20:26 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id KAA00274 for ; Thu, 5 Mar 1998 10:20:24 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20862; Thu, 5 Mar 1998 10:20:20 -0500 Message-Id: <199803051520.AA20862@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5254) Source Address Selection Issue and Scoping Date: Thu, 05 Mar 1998 10:20:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, We need to check if we need rules here for one case of source address selection. We ran into this while implementing as a re-check and design issue. Should a Host ever send a packet where: The src address is of lesser scope than the dst address, and the host only has addresses that are of less scope than the dst address it wants to send to. Example: src : FE80::2 (link local) dst : 3FFE::1230::4 We don't say anything in any specs that would prevent this behavior. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 09:09:32 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA05146 for ipng-dist; Thu, 5 Mar 1998 09:02:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA05138 for ; Thu, 5 Mar 1998 09:02:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA02267 for ; Thu, 5 Mar 1998 09:02:22 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA22120 for ; Thu, 5 Mar 1998 09:02:11 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id QAA08545; Thu, 5 Mar 1998 16:57:57 GMT Message-Id: <199803051657.QAA08545@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 05 Mar 1998 17:02:23 +0000 To: bound@zk3.dec.com From: Peter Curran Subject: (IPng 5256) Re: Source Address Selection Issue and Scoping Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199803051520.AA20862@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim raises an interesting question, that I think is related to a similar question that I have.... At 10:20 05/03/98 -0500, bound@zk3.dec.com wrote: >Should a Host ever send a packet where: > > The src address is of lesser scope than the dst address, and the > host only has addresses that are of less scope than the dst > address it wants to send to. > >Example: > > src : FE80::2 (link local) > dst : 3FFE::1230::4 > Whilst doing some protocol analysis on our network recently I noticed some interesting implementation-driven side effects. The environment under test was INRIA on the hosts and cisco tipv6.1024 on the router. (But I don't think this matters as the problem seems to be generic). The ordering of prefixes in the router advertisment is related to the order in which they are specified in the configuration file. When the host receives a RA it creates new addresses in the order in which they are read from the RA. So, if I advertise a global and site-local prefix in that order then the 'default' address used by the hosts is the site-local. My questions, really an extension to Jim's, is: Should we specify a priority ordering for addresses (global, site-local, link-local) to determine which is used by default? Should we always match the source address with the destination by default? By this I mean, if the dest is a link-local address should the source also be a link-local, if the dest is site-local then should the source be site-local? This behaviour is NOT exhibited by the implementations I am testing. It does result in an increase in the amount of background chatter associated with the protocol. E.g., a router learns the link-local/link-layer addresses of a host as a result of a router solicitation. The host then contacts the router (e.g. using telnet) to the link-local address of the router, using the (default) source address (a global or site-local). The router now has two addresses for this host in its NDP cache and proceeds to do reachability tests against both. In extreme cases it may cache all 3 addresses and do reachability against all 3. If the behaviour was to select the source address based on the destination then this would not happen. Peter TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 09:11:40 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA05155 for ipng-dist; Thu, 5 Mar 1998 09:08:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA05148 for ; Thu, 5 Mar 1998 09:08:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA04213 for ; Thu, 5 Mar 1998 09:08:35 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA26971 for ; Thu, 5 Mar 1998 09:08:33 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id RAA08556; Thu, 5 Mar 1998 17:04:00 GMT Message-Id: <199803051704.RAA08556@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 05 Mar 1998 17:08:25 +0000 To: bound@zk3.dec.com From: Peter Curran Subject: (IPng 5257) Re: ICMP Dst Unreachable for Link-Local and Site-Local Addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199803051523.AA21214@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:23 05/03/98 -0500, bound@zk3.dec.com wrote: >Another impelementation issue. > >A router will not forward a link-local address off the link or a >site-local address out of the site. The packet is dropped. > >Seems we should get either an ICMP Dst Unreachable or possibly some new >ICMP informative error message. > >Also if we permit (per the other mail thread) for Hosts to send with >lesser scope for src than dst like site == src and global == dst the >packet will get dropped at the border or site router. > >The end result in both cases is no error message to the user and the >connection will time out. But no one will no why. > >It seems prudent the routers should send an ICMP msg. > >Comments? Logically, such a message should be a new 'code' value for the 'unreachable' type 1 message. We could either add a new code type (most elegant) or overload the meaning of code 0 (no route to destination) or reuse code 2 (as this is now obsolescent). Either way, we should have an error message. Peter TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 10:39:02 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA05338 for ipng-dist; Thu, 5 Mar 1998 10:30:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA05331 for ; Thu, 5 Mar 1998 10:29:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA04228 for ; Thu, 5 Mar 1998 10:29:38 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA06146 for ; Thu, 5 Mar 1998 10:29:09 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: ipng@sunroof.eng.sun.com In-reply-to: <199803051520.AA20862@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5258) Re: Source Address Selection Issue and Scoping Date: Thu, 5 Mar 98 13:29:08 -0500 Message-ID: <9803051329.aa09550@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Should a Host ever send a packet where: > > The src address is of lesser scope than the dst address, and the > host only has addresses that are of less scope than the dst > address it wants to send to. Yes. I think a host would have to send this type of packet in response to a packet that came from a global address to the host's site- or link-local address. As far as I know, TCP connections and most UDP applications will continue to require that the end-point addresses remain constant for one "conversation". And, the fact that the original packet reached the host implies that the return packet is likely to reach the remote side. For the start of a new "conversation", a host should try to use a source address with the same scope as the destination, if available. If not, a wider-scoped source address should be used. As a last resort (when no wider-scoped address exists) a host should resort to a narrower-scoped address. The worst that happens in this case is that the communication will fail, but the communication would definitely fail if we refused to send the packet. I do agree that we need a new ICMP destination unreachable error code to handle packets which are of insufficient scope to be forwarded. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 11:26:03 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA05386 for ipng-dist; Thu, 5 Mar 1998 11:16:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA05379 for ; Thu, 5 Mar 1998 11:16:08 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA22460 for ; Thu, 5 Mar 1998 11:16:05 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA04061 for ; Thu, 5 Mar 1998 11:16:06 -0800 (PST) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA01367; Thu, 5 Mar 1998 14:16:05 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07165; Thu, 5 Mar 1998 14:16:03 -0500 Message-Id: <199803051916.AA07165@wasted.zk3.dec.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5259) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Thu, 05 Mar 1998 13:29:08 EST." <9803051329.aa09550@khitomer.epilogue.com> Date: Thu, 05 Mar 1998 14:16:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, On my dev team this was semi-consensus too. I take another view of it and that is don't send packets that may fail on networks. But I am not totally wedded to my view but more important is we all do the same rules and we have to have the icmp msg I agree, users should know why a connection timed out if it is an address scoping problem which is new to IPv6 and not an issue in IPv4. Also as a note if a host does get to another node where its src is greater than the dst in scope is an interesting twist to this and should this be allowed, which may give us the answer. Unless we say the scope must be equal to or less than the scope of the dst adddress? Why is that bad? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 11:51:05 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA05480 for ipng-dist; Thu, 5 Mar 1998 11:46:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA05472 for ; Thu, 5 Mar 1998 11:46:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA02908 for ; Thu, 5 Mar 1998 11:46:13 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA23534 for ; Thu, 5 Mar 1998 11:46:14 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: ipng@sunroof.eng.sun.com In-reply-to: <199803051916.AA07165@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5260) Re: Source Address Selection Issue and Scoping Date: Thu, 5 Mar 98 14:46:13 -0500 Message-ID: <9803051446.aa16200@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Unless we say the scope must >be equal to or less than the scope of the dst adddress? Why is that bad? If we take an example: HOST A has two addresses: global = GA, link-local = LA. A user on HOST A tries to ping (or initiate any other "conversation") to HOST B's site local address, SB. If A chooses his global address, GA, as the source address and B tries to respond, the communication will succeed if A and B are in the same site (including if they are on the same link). If A chooses his link-local address, LA, as the source address, the communication will only succeed for A and B are on the same link. So, assuming we are going to try to communicate at all, it increases the chance of success to choose a wider-scoped source when no equally-scoped source is available. Whether or not this type of situation will arise regularly will depend upon two factors: - How many IPv6 hosts will not have all three types of addresses associated with each of their interfaces. - How the domain name resolution mechanism and IP decide which address to use as the destination. I'm not sure that we've ever really resolved whether site-local or link-local addresses will be returned by the DNS. But, I would prefer the "best effort" approach to simply refusing to send the packet. Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Integrated Systems, Inc. FAX: (617) 245-8122 Epilogue Embedded Solutions http://www.epilogue.com 333 North Ave, 4th Floor http://www.isi.com Wakefield, MA 01880, USA Sales: info@epilogue.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 22:32:32 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id WAA06660 for ipng-dist; Thu, 5 Mar 1998 22:24:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id WAA06653 for ; Thu, 5 Mar 1998 22:24:16 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA29374 for ; Thu, 5 Mar 1998 22:24:15 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA05338 for ; Thu, 5 Mar 1998 22:24:16 -0800 (PST) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id BAA28496; Fri, 6 Mar 1998 01:22:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA31862; Fri, 6 Mar 1998 01:22:04 -0500 Message-Id: <199803060622.AA31862@wasted.zk3.dec.com> To: Margaret Wasserman Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5261) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Thu, 05 Mar 1998 14:46:13 EST." <9803051446.aa16200@khitomer.epilogue.com> Date: Fri, 06 Mar 1998 01:22:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Whether or not this type of situation will arise regularly will depend >upon two factors: > > - How many IPv6 hosts will not have all three types of > addresses associated with each of their interfaces. I think a host that is communicating with a correspondant node should have been assigned the proper scoped address. If you don't have a global address you can't initiate communications to global scope dst addresses. If you don't have site you can't talk to site addresses. This defines a strict rule which will also support the essence of renumbering too. No global no global comm. No site no site comm. and etc etc for all scopes. > - How the domain name resolution mechanism and IP decide > which address to use as the destination. I'm not > sure that we've ever really resolved whether > site-local or link-local addresses will be returned > by the DNS. But when you get an address from DNS and select a src address you scope the address based on the dst address you get from DNS. So I am not clear why it factors into this discussion? (clearly it does in other discussions). But this raises another issue. If we do reject sending a packet because of invalid scope we need to have a specific error to the APIs for this situation!!! >But, I would prefer the "best effort" approach to simply refusing >to send the packet. Hmmm probably the wrong guy to ask this but... I only apply this rule to the IP-layer to IP-layer. Not anywhere else in the TCP/IP suite, or in a network. Also the phrase "best effort" is over-used IMO. I believe in hard rules or the communications stops. If you don't have equal scope you can't send a packet is where I really think things should be. It is up to your site to be ordered and run efficiently or you don't work. Permitting errors to happen in an architecture is not easy for me and that is what we are doing if we permit different scoped addresses in packets. Its these minute errors we permit as we round off the IPv6 architecture which will fail the architecture long term. I know this is not a populous view but one I will continue to harp about. It also makes the code base much simpler with less conditions. Is this significant? No. But every place we save a line of code adds up and every error we can prevent is a good thing. Every little bit we can do to contain errors is prudent for IPv6. We can all find them in IPv4 and we do each week and each month in products. Not from our code base but from the architecture using a best-effort mind set at times in IPv4, which IMO we must curb in IPv6 as we can without making IPv6 so rigid it is not flexible and extensible. I don't believe equal scopes as required is not flexible but just common sense for IPv6. The end goal is not to make sure communications happens but that communications is reliable IMO. Reliability is greater if we require equal scoped addresses for src and dst. Reliability begats scalability and that is important too. When we have an architecture that is reliable and scalable, we can then fine tune it better and more efficiently to gain performance (less variance for errors which makes peformance testing less deviant). When we build a networking architecture that is Reliable, Scalable, and Performs well we have really done our job for customers as engineers, and work that we can be proud of to ship as a product that can support mission critical networking. True this we cannot always do but I think we can in this case. "Best Effort" is a good term in the right context, but it is also abused as a means to justify a non-rigorous set of rules which may in fact have valid justification to be rigorous. Renumbering is very important for IPv6 and the less connections that break during such an event is good. Different scoped addresses being permitted make renumbering more difficult for a connection that has one address that is in the scope being renumbered and the other is not. Requiring equal scoped addresses also sets expectations for addresses correctly on a node. I can go on with more reasons but will stop for now. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 22:49:21 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id WAA06689 for ipng-dist; Thu, 5 Mar 1998 22:45:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id WAA06682 for ; Thu, 5 Mar 1998 22:45:32 -0800 (PST) From: Alain.Durand@imag.fr Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA01804 for ; Thu, 5 Mar 1998 22:45:31 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA12387 for ; Thu, 5 Mar 1998 22:45:31 -0800 (PST) Received: from brahma.imag.fr (brahma.imag.fr [129.88.30.10]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id HAA02530; Fri, 6 Mar 1998 07:45:29 +0100 (MET) Received: (from durand@localhost) by brahma.imag.fr (8.8.7/8.8.5) id HAA20299; Fri, 6 Mar 1998 07:45:25 +0100 (MET) Date: Fri, 6 Mar 1998 07:45:25 +0100 (MET) Message-Id: <980306074525.ZM20297@brahma.imag.fr> In-Reply-To: bound@zk3.dec.com "(IPng 5254) Source Address Selection Issue and Scoping" (Mar 5, 10:20am) References: <199803051520.AA20862@wasted.zk3.dec.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5262) Re: Source Address Selection Issue and Scoping MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mar 5, 10:20am, bound@zk3.dec.com wrote: > Subject: (IPng 5254) Source Address Selection Issue and Scoping > > Should a Host ever send a packet where: > > The src address is of lesser scope than the dst address, and the > host only has addresses that are of less scope than the dst > address it wants to send to. > Example: > src : FE80::2 (link local) > dst : 3FFE::1230::4 There is another interesting example with IPv4 compatible addresses. They do not fit in the link local < site local < global scheme. example: src: ::10.0.0.1 dst: 3ffe:0301::1 BTW, this also raise an interesting question for routers. Should they forward such packets? - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 5 23:16:44 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id XAA06736 for ipng-dist; Thu, 5 Mar 1998 23:11:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id XAA06729 for ; Thu, 5 Mar 1998 23:11:08 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA05611 for ; Thu, 5 Mar 1998 23:11:05 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA20565 for ; Thu, 5 Mar 1998 23:11:05 -0800 (PST) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id CAA29078; Fri, 6 Mar 1998 02:11:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA32606; Fri, 6 Mar 1998 02:11:03 -0500 Message-Id: <199803060711.AA32606@wasted.zk3.dec.com> To: Alain.Durand@imag.fr Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5263) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Fri, 06 Mar 1998 07:45:25 +0100." <980306074525.ZM20297@brahma.imag.fr> Date: Fri, 06 Mar 1998 02:11:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, Good point. We have determined we need to special case v4-compats for any algorithm we build. The rules about this are fuzzy at best right now for v4-compat. I view them as "transition" addresses and that helps a little bit in the algorithm. But in my view you could not mix v4-compat with native-ipv6 address. I think that is evil for Hosts. Good point too on if routers should forward those packets with src ::1.2.3.4. For routers its more complex. But we should nail this down. I would claim what I am proposing solves this case for Hosts src/dst decisons too. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 04:32:50 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id EAA06961 for ipng-dist; Fri, 6 Mar 1998 04:25:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id EAA06954 for ; Fri, 6 Mar 1998 04:25:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA20190 for ; Fri, 6 Mar 1998 04:25:07 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA05437 for ; Fri, 6 Mar 1998 04:23:59 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA24514 for ; Fri, 6 Mar 1998 07:23:41 -0500 (EST) Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA37250 for ; Fri, 6 Mar 1998 07:23:41 -0500 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18936; Fri, 6 Mar 1998 07:23:48 -0500 Message-Id: <34FFEAD3.41C6@raleigh.ibm.com> Date: Fri, 06 Mar 1998 07:23:47 -0500 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 3.01 (X11; I; AIX 1) Mime-Version: 1.0 To: IPng Subject: (IPng 5265) Re: Source Address Selection Issue and Scoping References: <199803060622.AA31862@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com wrote: > > > Requiring equal scoped addresses also sets expectations for addresses > correctly on a node. I can go on with more reasons but will stop > for now. Another place where this will become important is site-scoped multicast addresses (FF05::X). While in the process of converting a multicast routing protocol to IPv6, the issue arose as to how do we determine site boundaries if the destination multicast address is FF05::X and the source address is global. By employing Jim's scoping requirement, this question is moot. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 05:09:44 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA06996 for ipng-dist; Fri, 6 Mar 1998 05:05:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA06989 for ; Fri, 6 Mar 1998 05:05:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA26916 for ; Fri, 6 Mar 1998 05:05:36 -0800 Received: from digi-data.com (odin.digi-data.com [196.32.33.17]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA21836 for ; Fri, 6 Mar 1998 05:03:47 -0800 (PST) Received: by odin.digi-data.com id <19589>; Fri, 6 Mar 1998 09:01:13 -0400 Date: Fri, 6 Mar 1998 09:02:36 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: IPng@sunroof.eng.sun.com Subject: (IPng 5266) Re: Source Address Selection Issue and Scoping References: <9803051446.aa16200@khitomer.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <98Mar6.090113gmt-0400.19589@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Folks, I think that I agree with Jim when he says a host should not be allowed to choose a source address different in scope from the destination address. I also agree there should be a new ICMP message or message class to indicate that a router could not forward a packet that violates this proposed restriction. Additionally, the DNS question advanced by Margaret Wasserman does have a small bearing on the problem: > - How the domain name resolution mechanism and IP decide > which address to use as the destination. I'm not > sure that we've ever really resolved whether > site-local or link-local addresses will be returned > by the DNS. > I believe that in addition to the requirement that hosts should match source and destination address scopes, the entire mechanism would be enhanced if DNS could return the address with the smallest scope that contains both the address of the node that is making the DNS query and the node that is being queried about. Thanks, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 05:43:54 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA07032 for ipng-dist; Fri, 6 Mar 1998 05:35:56 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA07025 for ; Fri, 6 Mar 1998 05:35:47 -0800 (PST) From: RAMAMIRTHAM@PROCESS.COM Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA02113 for ; Fri, 6 Mar 1998 05:35:43 -0800 Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA02662 for ; Fri, 6 Mar 1998 05:31:46 -0800 (PST) Date: Fri, 6 Mar 1998 08:31 -0500 Message-Id: <009C2C62AC7A5BED.A9CA@PROCESS.COM> To: IPNG@sunroof.eng.sun.com Subject: (IPng 5267) FWD: Re: Re: Source Address Selection Issue and Scoping X-VMS-To: IPng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On my dev team this was semi-consensus too. I take another view of it and >that is don't send packets that may fail on networks. But I am not >totally wedded to my view but more important is we all do the same rules >and we have to have the icmp msg I agree, users should know why a >connection timed out if it is an address scoping problem which is new to >IPv6 and not an issue in IPv4. I agree. We are facing a similar situation in our testing as we speak! An proper error message would save a lot of grief. >Also as a note if a host does get to another node where its src is >greater than the dst in scope is an interesting twist to this and should >this be allowed, which may give us the answer. Unless we say the scope must >be equal to or less than the scope of the dst adddress? Why is that bad? Makes sense to me. Would it make sense for the local host to refuse to initiate a connection if it can't find an address of the right scope to communicate with the destination? This would save a trip to the default router? Thanks, --Ravi Process Software Corp Framingham, MA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 06:43:21 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA07135 for ipng-dist; Fri, 6 Mar 1998 06:31:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA07128 for ; Fri, 6 Mar 1998 06:31:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA12549 for ; Fri, 6 Mar 1998 06:31:37 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA25770 for ; Fri, 6 Mar 1998 06:28:42 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-reply-to: <199803060622.AA31862@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5268) Re: Source Address Selection Issue and Scoping Date: Fri, 6 Mar 98 09:23:07 -0500 Message-ID: <9803060923.aa26966@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think a host that is communicating with a correspondant node should >have been assigned the proper scoped address. If you don't have a >global address you can't initiate communications to global scope dst >addresses. If you don't have site you can't talk to site addresses. >This defines a strict rule which will also support the essence of >renumbering too. No global no global comm. No site no site comm. >and etc etc for all scopes. The specifications do not currently require this, but perhaps such a rule should be added to reduce complexity, as you suggest. However, we should only add a new address-selection restriction to make IPv6 less complex if we are sure that we will not be eliminating any advantages that would justify the complexity cost. I don't see a certain amount of traffic being rejected at link or site boundaries due to improperly scoped source addresses as a particularly bad thing. Even if we add a restriction of the type you suggest, I believe that routers will still need to check both addresses and enforce link and site boundaries in the same way. I definitely agree that hosts SHOULD use an equally-scoped source address if available, but I believe that is already specified. My main concern on that point is related to my previous issue: >> - How the domain name resolution mechanism and IP decide >> which address to use as the destination. I'm not >> sure that we've ever really resolved whether >> site-local or link-local addresses will be returned >> by the DNS. > >But when you get an address from DNS and select a src address you >scope the address based on the dst address you get from DNS. So I am >not clear why it factors into this discussion? (clearly it does in other >discussions). Right now, hosts are required to store hostnames, rather than IP addresses, to identify hosts in any static locations (configuration files, for example). If the DNS will only return global addresses (at least within a globally-attached network) and no site-local or link-local name resolution mechanism is developed, it will only be possible to map a hostname to a global IP address. If we add a restriction that hosts cannot communicate using a global destination and a site-local or link-local source, then a host will not be able to attempt to communicate with any host stored by hostname until after it has configured a global address. Also, a host will not be able to choose to limit the routing scope of a particular message if it cannot determine a lesser-scoped destination address. Is it possible that I might want to use a site-local source to communicate with a host I have stored by hostname to make sure that my request does not go to servers (or whatever) outside of my site? As another example, are there any types of servers (Security, DHCP, Resource Location, etc.) that I might need to contact, given only their hostname, before I have a global address configured? What if I want to get some security information to authenticate router advertisements before I will believe them, for example? Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Integrated Systems, Inc. FAX: (617) 245-8122 Epilogue Embedded Solutions http://www.epilogue.com 333 North Ave, 4th Floor http://www.isi.com Wakefield, MA 01880, USA Sales: info@epilogue.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 07:29:20 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA07298 for ipng-dist; Fri, 6 Mar 1998 07:23:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA07291 for ; Fri, 6 Mar 1998 07:23:09 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA01063 for ; Fri, 6 Mar 1998 07:23:05 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA15946 for ; Fri, 6 Mar 1998 07:20:43 -0800 (PST) Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id KAA29114; Fri, 6 Mar 1998 10:20:37 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA15258; Fri, 6 Mar 1998 10:20:33 -0500 Message-Id: <199803061520.AA15258@wasted.zk3.dec.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5269) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Fri, 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> Date: Fri, 06 Mar 1998 10:20:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree that DNS only returning global addresses is problematic. I don't think DNS should return link-local. I await Erik Nordmarks updated draft on site-local addresses for additional input on this subject. I do believe DNS should be able to return site-local addresses though. So you will get back a multitude of addresses from host name query. We should specify how DNS should return those in what order as a default. Then if one gets a scope error at the API try the next addr in hostent (LOOP HERE I know but it is no worse than IPv4 if you cannot connect). This we should discuss and Robert H. hinted at it in his recent mail. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 09:28:32 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA07635 for ipng-dist; Fri, 6 Mar 1998 09:16:40 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id JAA07627 for ; Fri, 6 Mar 1998 09:16:32 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id JAA15406 for ; Fri, 6 Mar 1998 09:16:31 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA14340; Fri, 6 Mar 1998 09:15:27 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id AAA06811 for ; Fri, 6 Mar 1998 00:52:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA18871 for ; Fri, 6 Mar 1998 00:52:10 -0800 Received: from cs.nthu.edu.tw (cs.nthu.edu.tw [140.114.77.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA25445 for ; Fri, 6 Mar 1998 00:51:50 -0800 (PST) Received: from nfhuang.cs.nthu.edu.tw (nfhuang-pc.cs.nthu.edu.tw [140.114.76.29]) by cs.nthu.edu.tw (thcs.1/cs) with SMTP id QAA26294 for ; Fri, 6 Mar 1998 16:48:13 +0800 (CST) Date: Fri, 6 Mar 1998 16:48:13 +0800 (CST) Message-Id: <199803060848.QAA26294@cs.nthu.edu.tw> X-Sender: nfhuang@cs.nthu.edu.tw X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: "N.F.Huang" Subject: (IPng 5270) Re: Companies Implementing IPv6? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Paul: May be we can provide some information for you on Windows95 Ipv6. Currently we are implementing the Ipv6/Ipv4 protocol stack for the windows95. The protocols are ready for test. We have implemented an application (Ipv6 Chat) for the Ipv6 protocol. So far, the software provides: (1) Plag-and-play (auto-configurtion), station generates link local Ipv6 address and also gets the ipv6 prefix from the Ipv6 routers. We also implemented Ipv6 routers (based on ATM/Ethernet interface, supertask real-time kernel, i960 CPU). (2) Tunneling. Both host-to-host tunneling and tunneling to 6-bone transit site are provided. IF all the stations on the lan segment are Ipv6 stations, then no tunneling is needed. (3) Security transmission. Next step we will develop video applications over the Ipv6 protocols. The IPv6 API for the Winsock-II will be delivered within one or two months. We can provide a test package for you in case you need. At 09:44 AM 3/4/98 -0600, you wrote: > > > I am a systems engineer working research and development for General > Dynamics Information Systems. My company is just starting a lab > environment to implement IPv6. Our lab started out with a Windows NT 4.0 > server, laptops and Pentium machines. My first task was to find out > which companies produce IPv6 products. > > I started out using the "IPng Implementations" list at > > http://playground.sun.com/ipng/ipng-implementations.2.html > > I attempted to contact each of the host and router implementations listed > there. I got some kind of response from (routers) Cisco Systems, Hitachi, > Ipsilon Networks, and Telebit; as well as (hosts) Digital, Epilogue, > Process Software, Silicon Graphics, and Sun. > > What I need to find out is which products are "best" to select/purchase > for our new lab. Our R&D is based upon the following task statement > (number 1 of 8): > > "Mobile backbone that can support multimedia. Survey what is state of > the art. What exists now on IPv6 that can support mobile IP? RSVP? > Investigate relationships of OSI seven layer model and mobile backbone to > support multimedia. What is role of ATM? Are products available? What > is the cost? Report." > > I'd appreciate any advice on how to start: what routers, what work > stations, etc. > > Thank you in advance for your time and assistance. > > Paul Maggitti > > paul.v.maggitti@gd-is.com > General Dynamics Information Systems > 8800 Queen Avenue South, M/S BLCS2X > Bloomington, MN 55431 > (612) 921-6885/(612) 830-5100 (fax) > > Best Regards, Nen-Fu Huang Professor and Chairman Department of Computer Science National Tsing Hua University Hsin-Chu, Taiwan, 300 E-mail: nfhuang@cs.nthu.edu.tw Tel: +886-3-5731063 Fax: +886-3-5723694 WWW: http://www.cs.nthu.edu.tw/~nfhuang/ ---------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 10:20:16 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA07792 for ipng-dist; Fri, 6 Mar 1998 10:09:03 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA07784 for ; Fri, 6 Mar 1998 10:08:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA25661 for ; Fri, 6 Mar 1998 10:08:49 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA17634 for ; Fri, 6 Mar 1998 10:08:20 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA21451 for ; Fri, 6 Mar 1998 10:08:16 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199803061520.AA15258@wasted.zk3.dec.com> References: Your message of "Fri, 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 10:09:30 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 5271) Re: Source Address Selection Issue and Scoping Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we should *not* impose the requirement that scope of the source and destination addresses be the same, because I don't think it necessary for correctness and, as Margaret said, it may cut off potentially useful behaviors. For example, if a human types "ping " from a node that only has link-local and site-local addresses, the node should go ahead and try to send the packet. If the is in the same site as the source, the packet will be delivered, and that target node ought to reply by swapping the two (not-equivalently-scoped) addresses. If the is *not* in the same site as the source, an ICMP error message should inform the source (and thence the human) of the problem. I agree that we should define a new subcode of the ICMP Destination Unreachable message for reporting failure due to address scope. I also agree that, in any case where a node or an application has a choice of source and/or destination addresses (e.g., when getting multiple addresses back from a DNS lookup), it ought to choose the case where both source and dest have the same scope. However, when it does not have a choice (either because a human has requested a specific action, or because of a protocol requirement such as the need for a ping reply or a TCP SYN ACK to use the same addresses as were used in the initiating packet), it should go ahead and do what it was told to do. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 11:46:26 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA07942 for ipng-dist; Fri, 6 Mar 1998 11:36:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA07935 for ; Fri, 6 Mar 1998 11:36:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA23819 for ; Fri, 6 Mar 1998 11:35:57 -0800 Received: from digi-data.com ([196.32.33.17]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA26226 for ; Fri, 6 Mar 1998 11:35:44 -0800 (PST) Received: by odin.digi-data.com id <19590>; Fri, 6 Mar 1998 15:33:12 -0400 Date: Fri, 6 Mar 1998 15:34:40 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Steve Deering CC: ipng@sunroof.eng.sun.com Subject: (IPng 5272) Re: Source Address Selection Issue and Scoping References: Your message of "Fri, 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <98Mar6.153312gmt-0400.19590@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Steve, Steve Deering wrote: > > I think we should *not* impose the requirement that scope of the source > and destination addresses be the same, because I don't think it necessary > for correctness and, as Margaret said, it may cut off potentially useful > behaviors. > I would disagree with you there, Steve. If node A has only a link local and it should attempt to send a packet to node B's site local or B's global address, there is no way to show **topologically** that A can reach B or vice versa. Why should you try to send a packet to a node you have no acceptable reason to believe you can reach? While it may be true that within the same link or within the same site that Neighbour Discovery could perform the mapping to a link- or site local address for node B, without that mapping all you can expect at best is a threefold increase in the amount of traffic that must be sent and at worst complete unreachability. I believe we can do better than that. > For example, if a human types "ping " from a node that > only has link-local and site-local addresses, the node should go ahead > and try to send the packet. If the is in the same site > as the source, the packet will be delivered, and that target node ought > to reply by swapping the two (not-equivalently-scoped) addresses. If the > is *not* in the same site as the source, an ICMP error > message should inform the source (and thence the human) of the problem. How will the ping request even make it past the link to reach the destination node **even** if the destination node were in the same site? Additionally, if by some miracle the ping request should make it to the destination node, there will be no way for the reply to go back because by the definition, there would be no way to deduce a route back to the specific site or link so as to deliver the reply to the appropriate node interface. If it is guaranteed to fail, why bother to do it? > > I agree that we should define a new subcode of the ICMP Destination > Unreachable message for reporting failure due to address scope. > > I also agree that, in any case where a node or an application has a choice > of source and/or destination addresses (e.g., when getting multiple > addresses back from a DNS lookup), it ought to choose the case where both > source and dest have the same scope. However, when it does not have a > choice (either because a human has requested a specific action, or because > of a protocol requirement such as the need for a ping reply or a TCP SYN ACK > to use the same addresses as were used in the initiating packet), it should > go ahead and do what it was told to do. It should not do so blindly. In order to deliver a packet to any other node, the interface from which the packet is sent **should** have an address of equal scope and that address should be used as the source address. Thanks, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 12:17:24 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA08096 for ipng-dist; Fri, 6 Mar 1998 12:10:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA08089 for ; Fri, 6 Mar 1998 12:10:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA03487 for ; Fri, 6 Mar 1998 12:10:08 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA26087 for ; Fri, 6 Mar 1998 12:09:42 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA06732; Fri, 6 Mar 1998 12:08:45 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <98Mar6.153310gmt-0400.19589@odin.digi-data.com> References: Your message of "Fri, 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 12:07:19 -0800 To: robert@digi-data.com From: Steve Deering Subject: (IPng 5273) Re: Source Address Selection Issue and Scoping Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, > > I think we should *not* impose the requirement that scope of the source > > and destination addresses be the same, because I don't think it necessary > > for correctness and, as Margaret said, it may cut off potentially useful > > behaviors. > > I would disagree with you there, Steve. If node A has only a link local > and it should attempt to send a packet to node B's site local or B's > global address, there is no way to show **topologically** that A can > reach B or vice versa. But B *could* be a neighbor of A, i.e., attached to the same link, and the human who requests transmission of a packet from A to B might well know that and have some good reason for using B's site-local or global address as the destination address of the packet (e.g., debugging). In that case, I see no need to forbid the attempt. If it succeeds (because the larger-scope destination actually falls within the smaller scope of the source address), great; if it fails, an ICMP message can inforn the source of the reason for failure. > Why should you try to send a packet to a node you have no acceptable reason > to believe you can reach? I'm saying that there are cases where a user or application may very well know that the larger-scope destination is reachable within the smaller scope of the source address. > While it may be true that within the same link or within the same site > that Neighbour Discovery could perform the mapping to a link- or site-local > address for node B,... I don't know what mapping you are talking about. At the last hop, IPv6 destination addresses are mapped to link-layer (not link-local) addresses; at non-terminal hops, IPv6 destination addresses are looked up in routing tables to determine the next hop, and are never mapped to lesser-scoped IPv6 addresses. > ...without that mapping all you can expect at best is a threefold > increase in the amount of traffic that must be sent and at worst > complete unreachability. No, at best you can get succesful, single-packet delivery (in the case where the destination address actually resides within the scope of the source address). > > For example, if a human types "ping " from a node that > > only has link-local and site-local addresses, the node should go ahead > > and try to send the packet. If the is in the same site > > as the source, the packet will be delivered, and that target node ought > > to reply by swapping the two (not-equivalently-scoped) addresses. If the > > is *not* in the same site as the source, an ICMP error > > message should inform the source (and thence the human) of the problem. > > How will the ping request even make it past the link to reach the > destination node **even** if the destination node were in the same site? Sorry, I forgot to state the assumption in my example that the originator would use its site-local address as the source address of the ping. > Additionally, if by some miracle the ping request should make it to the > destination node, there will be no way for the reply to go back because > by the definition, there would be no way to deduce a route back to the > specific site or link so as to deliver the reply to the appropriate node > interface. No, if a packet makes it from A to B without violating any scope boundaries, then a packet ought to be able to make it in the reverse direction simply by swapping the original addresses (assuming both are unicast addresses). If the ping target receives on an interface a ping packet destined to one of the target's global addresses, sourced from a site-local address, the target should send its reply to the pinger's site-local address, via the arrival interface (or any other interface attached to the same site as the arrival interface), sourced from the global address originally used to reach the target. > If it is guaranteed to fail, why bother to do it? My point is that it is not guaranteed to fail. > > I also agree that, in any case where a node or an application has a choice > > of source and/or destination addresses (e.g., when getting multiple > > addresses back from a DNS lookup), it ought to choose the case where both > > source and dest have the same scope. However, when it does not have a > > choice (either because a human has requested a specific action, or because > > of a protocol requirement such as the need for a ping reply or a TCP >SYN ACK > > to use the same addresses as were used in the initiating packet), it should > > go ahead and do what it was told to do. > > It should not do so blindly. In order to deliver a packet to any other > node, the interface from which the packet is sent **should** have an > address of equal scope and that address should be used as the source > address. I agree with SHOULD, but not with MUST. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 14:04:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA08216 for ipng-dist; Fri, 6 Mar 1998 13:56:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA08209 for ; Fri, 6 Mar 1998 13:55:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA00740 for ; Fri, 6 Mar 1998 13:55:48 -0800 Received: from digi-data.com (odin.digi-data.com [196.32.33.17]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA22297 for ; Fri, 6 Mar 1998 13:54:23 -0800 (PST) Received: by odin.digi-data.com id <19596>; Fri, 6 Mar 1998 17:51:55 -0400 Date: Fri, 6 Mar 1998 17:53:20 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Steve Deering CC: ipng@sunroof.eng.sun.com Subject: (IPng 5274) Re: Source Address Selection Issue and Scoping References: Your message of "Fri, 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <98Mar6.175155gmt-0400.19596@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > But B *could* be a neighbor of A, i.e., attached to the same link, and the > human who requests transmission of a packet from A to B might well know that > and have some good reason for using B's site-local or global address as the > destination address of the packet (e.g., debugging). In that case, I see > no need to forbid the attempt. If it succeeds (because the larger-scope > destination actually falls within the smaller scope of the source address), > great; if it fails, an ICMP message can inforn the source of the reason for > failure. Even though I must agree with you that there is no need to forbid the attempt, I must at the same time I must ask how much can be gained from allowing the attmpt? This will forever be at most a very rare occurrence. In almost all cases, if an application on node A, using A's link- or site local address, sends a message to node B's global scope address and B is a neighbour, the applicatin should be reconfigured either to use B's link local addressfor the destination or to use A's global scope address as the source if one is available. What is the advantage? > I'm saying that there are cases where a user or application may very well > know that the larger-scope destination is reachable within the smaller scope > of the source address. In this case there exists an interface on that link or within that site that has an address of the smaller scope which corresponds to the global address the application is attempting to use. The application or user should attempt to learn **that** address. To do otherwise would cause performance problems for the application. For the user I fail to see what advantage it could offer if he is allowed to use non-equal scope addresses as his source and destination addresses. > > While it may be true that within the same link or within the same site > > that Neighbour Discovery could perform the mapping to a link- or site-local > > address for node B,... > > I don't know what mapping you are talking about. At the last hop, IPv6 > destination addresses are mapped to link-layer (not link-local) addresses; > at non-terminal hops, IPv6 destination addresses are looked up in routing > tables to determine the next hop, and are never mapped to lesser-scoped > IPv6 addresses. Sorry about that, I did mean link-layer addresses. > No, if a packet makes it from A to B without violating any scope boundaries, > then a packet ought to be able to make it in the reverse direction simply > by swapping the original addresses (assuming both are unicast addresses). > > If the ping target receives on an interface a ping packet destined to one of > the target's global addresses, sourced from a site-local address, the target > should send its reply to the pinger's site-local address, via the arrival > interface (or any other interface attached to the same site as the arrival > interface), sourced from the global address originally used to reach the > target. > > > If it is guaranteed to fail, why bother to do it? > > My point is that it is not guaranteed to fail. > Though it is not guaranteed to fail, in all cases where it does not fail, there already exists an address of lesser scope that should preferrably be used. > > It should not do so blindly. In order to deliver a packet to any other > > node, the interface from which the packet is sent **should** have an > > address of equal scope and that address should be used as the source > > address. > > I agree with SHOULD, but not with MUST. > You are quite right but I would add that in the case of user or application actions, there should be a set of user-level warning messages or something like that to prompt a reconfiguration of the application or the choice by the user of a different action. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 14:17:06 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA08250 for ipng-dist; Fri, 6 Mar 1998 14:07:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA08243 for ; Fri, 6 Mar 1998 14:06:50 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA03503 for ; Fri, 6 Mar 1998 14:06:47 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA21559 for ; Fri, 6 Mar 1998 14:06:44 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA26275; Fri, 6 Mar 1998 16:06:41 -0600 Message-Id: <199803062206.QAA26275@gungnir.fnal.gov> To: namedroppers@internic.net, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5275) draft-ietf-dnsind-dname-00.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mimeprimaryboundary Date: Fri, 06 Mar 1998 16:06:41 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain I just submitted the "DNAME" draft to the i-d editor. It's the non-terminal CNAME thing I was calling ZNAME during the last meeting. Since the i-d queue seems to be about 5 working days right now, I include a pointer to my own copy below. The binary labels draft came out last week if some of you in the ipngwg missed it. I'll be revising it shortly to make it more dnssec friendly. Discussion on namedroppers, please! Matt Crawford --mimeprimaryboundary Content-Type: message/external-body; access-type="anon-ftp"; site="berserk.fnal.gov"; directory="pub"; name="draft-ietf-dnsind-dname-00.txt" Content-Description: draft-ietf-dnsind-dname-00.txt Content-Type: text/plain --mimeprimaryboundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 14:35:20 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA08276 for ipng-dist; Fri, 6 Mar 1998 14:27:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA08267 for ; Fri, 6 Mar 1998 14:27:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA08406 for ; Fri, 6 Mar 1998 14:27:03 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA08862 for ; Fri, 6 Mar 1998 14:25:25 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id RAA05467; Fri, 6 Mar 1998 17:25:14 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id RAA29821; Fri, 6 Mar 1998 17:25:10 -0500 (EST) Date: Fri, 6 Mar 1998 17:25:10 -0500 (EST) From: Christian Huitema Message-Id: <980306172510.ZM29819@seawind.bellcore.com> In-Reply-To: Robert Honore "(IPng 5274) Re: Source Address Selection Issue and Scoping" (Mar 6, 5:53pm) References: Your message of "Fri 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> <98Mar6.175155gmt-0400.19596@odin.digi-data.com> X-Mailer: Z-Mail (5.0.0 30July97) To: robert@digi-data.com, Steve Deering Subject: (IPng 5276) Re: Source Address Selection Issue and Scoping Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The real point is: scoped address are evil. Link local is about OK, but should only be used when nothing else is available. Site local is about as bad as net 10. The only advantage I have heard so far is that using site local there is some way to constraint the packet to stay in a "site", which has a dubious security value, and that TCP connection that use site local addresses would survive renumbering (but the same result could be achieved with very simple extensions to TCP). If you want to have site local addresses in the DNS, then you must make sure that they are world-wide unique, albeit non necessarily aggregatable. , -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 14:35:25 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA08284 for ipng-dist; Fri, 6 Mar 1998 14:27:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA08275 for ; Fri, 6 Mar 1998 14:27:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA08458 for ; Fri, 6 Mar 1998 14:27:11 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA25102 for ; Fri, 6 Mar 1998 14:27:09 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id RAA05536; Fri, 6 Mar 1998 17:27:07 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id RAA29828; Fri, 6 Mar 1998 17:27:06 -0500 (EST) Date: Fri, 6 Mar 1998 17:27:06 -0500 (EST) From: Christian Huitema Message-Id: <980306172706.ZM29826@seawind.bellcore.com> In-Reply-To: "Matt Crawford" "(IPng 5275) draft-ietf-dnsind-dname-00.txt" (Mar 6, 4:06pm) References: <199803062206.QAA26275@gungnir.fnal.gov> X-Mailer: Z-Mail (5.0.0 30July97) To: "Matt Crawford" , namedroppers@internic.net, ipng@sunroof.eng.sun.com Subject: (IPng 5277) Re: draft-ietf-dnsind-dname-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I have read the binary label draft. If DNAME is what I think it is, then we can consider that invese lookup for IPv6 is a done deal. The only question I have is the cost of the mechanism. Should we assume that it comes for free ? -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 14:52:59 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA08341 for ipng-dist; Fri, 6 Mar 1998 14:45:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA08334 for ; Fri, 6 Mar 1998 14:45:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14185 for ; Fri, 6 Mar 1998 14:45:20 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA18209 for ; Fri, 6 Mar 1998 14:43:17 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA26400; Fri, 6 Mar 1998 16:43:07 -0600 Message-Id: <199803062243.QAA26400@gungnir.fnal.gov> To: Christian Huitema Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5278) Re: draft-ietf-dnsind-dname-00.txt In-reply-to: Your message of Fri, 06 Mar 1998 17:27:06 EST. <980306172706.ZM29826@seawind.bellcore.com> Date: Fri, 06 Mar 1998 16:43:06 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have read the binary label draft. If DNAME is what I think it is, > then we can consider that invese lookup for IPv6 is a done deal. Why, thank you. > The only question I have is the cost of the mechanism. Should we > assume that it comes for free ? If you mean the cost in network transactions to do a lookup, compared with the cost of delegations done by NS on a tree like in-addr.arpa, I claim that the cost is the same, both for the first time you hit a given zone and for subsequent queries in a zone. Actually, for the first lookup in a zone, in order to conclude that the methods have the same cost you have to assume that the higher-level server gives you nothing but the NS in the old method and nothing but the DNAME in the new method. If they have something useful cached, either one might win. Of course, this presumes deployment. Or is that the cost you were thinking of? If so, it should help that both DNAME and binary labels have other uses than meeting IPv6's needs. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 15:04:39 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA08360 for ipng-dist; Fri, 6 Mar 1998 14:56:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA08353 for ; Fri, 6 Mar 1998 14:56:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA17954 for ; Fri, 6 Mar 1998 14:56:30 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA22247 for ; Fri, 6 Mar 1998 14:55:29 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA23596; Fri, 6 Mar 1998 14:51:17 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <98Mar6.175155gmt-0400.19596@odin.digi-data.com> References: Your message of "Fri, 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 14:49:51 -0800 To: robert@digi-data.com From: Steve Deering Subject: (IPng 5279) Re: Source Address Selection Issue and Scoping Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:53 PM -0800 3/6/98, Robert Honore wrote: > Even though I must agree with you that there is no need to forbid the > attempt, I must at the same time I must ask how much can be gained from > allowing the attmpt? I don't know how much can be gained, because I can't predict how the variously scoped addresses might usefully be used in the future. I'd rather not eliminate that degree of flexibility without a good reason to do so. I also think it adds unnecessary code complexity and conceptual complexity to add the restrictions you want to add. > This will forever be at most a very rare occurrence. We don't know that. And even if it is rare, it might still be very important to be able to do it in those rare circumstances. > In almost all cases, if an application on node A, using A's > link- or site local address, sends a message to node B's global scope > address and B is a neighbour, the applicatin should be reconfigured > either to use B's link local addressfor the destination or to use A's > global scope address as the source if one is available. What is the > advantage? As I said, I can't predict all the possible advantages, but I can imagine some, like debugging/testing (e.g., my network manager phones me up and asks me to ping some global address from my site-local address to *confirm* that the site-internal routing is convex and working properly). The case of direct neighbors might be a little less compelling (because all interfaces have to have link-local addresses), but we do not currently require that all interfaces have both site-local and global addresses. That means that within a single site, some nodes might not have global addresses and some might not have site- local addresses, and it would nice for them to be able to communicate if they are on different links within the site, since it is topologically possible and since permitting it does not violate any scoping rules. > > I'm saying that there are cases where a user or application may very well > > know that the larger-scope destination is reachable within the smaller >scope > > of the source address. > > In this case there exists an interface on that link or within that site > that has an address of the smaller scope which corresponds to the global > address the application is attempting to use. Not necessarily. As I said, we do not mandate that all nodes with global addresses also have site-local addresses. The jury is still out on how useful site-local address are going to be, and what they are going to be used for. > The application or user should attempt to learn **that** address. To do > otherwise would cause performance problems for the application. ^^^^^ *might* (or might not -- it depends on the context) > Though it is not guaranteed to fail, in all cases where it does not > fail, there already exists an address of lesser scope that should > preferrably be used. That's not a requirement of the current addressing specs, and I don't think it needs to be or should be. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 15:42:52 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA08476 for ipng-dist; Fri, 6 Mar 1998 15:34:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA08469 for ; Fri, 6 Mar 1998 15:34:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA01101 for ; Fri, 6 Mar 1998 15:34:05 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA13027 for ; Fri, 6 Mar 1998 15:32:38 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA28669; Fri, 6 Mar 1998 15:31:56 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <980306172510.ZM29819@seawind.bellcore.com> References: Robert Honore "(IPng 5274) Re: Source Address Selection Issue and Scoping" (Mar 6, 5:53pm) Your message of "Fri 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> <98Mar6.175155gmt-0400.19596@odin.digi-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 15:30:30 -0800 To: Christian Huitema From: Steve Deering Subject: (IPng 5280) Re: Source Address Selection Issue and Scoping Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:25 PM -0800 3/6/98, Christian Huitema wrote: > The real point is: scoped address are evil. I tend to agree with the latter part of that sentence, though I don't think that's the entire real point, since *some* of the same issues under discussion still arise just between link-local and global. Site-local addresses made more sense in some of the earlier stages of SIP and SIPP development, based on ideas that no longer apply in IPv6. I would be quite happy to delete site-local unicast addresses entirely from IPv6 if we had consensus on that (though the notion of site boundaries would still appear in the scope field of multicast address) -- it would simplify the implementations and the specs, and eliminate much of the confusion and design choices of the sort we have been discussing. However, I don't recall consensus ever being reached about net 10 in the IPv4 world. Does anyone in the IPv6 community want to speak up in favor of site-local addesses? (Note: if we eliminated site-local addresses, we could always add them back in in the future if absolutely necessary, using the net 10 approach, i.e., simply designating one global prefix for private use.) (I realize that I probably sound rather inconsistent here, on the one hand arguing for flexibility in how site-local address may be used, and on the other hand being content to see them eliminated altogether. But I don't think I am contradicting myself: I prefer the minimum number of mechanisms that achieve the maximum "power"/capability/generality. *If* we are going to keep site-local addresses, I think we should not unnecessarily constrain their possible use.) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 16:15:12 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA08579 for ipng-dist; Fri, 6 Mar 1998 16:08:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA08572 for ; Fri, 6 Mar 1998 16:07:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA09706 for ; Fri, 6 Mar 1998 16:07:52 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA28700 for ; Fri, 6 Mar 1998 16:03:35 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA02200 for ; Fri, 6 Mar 1998 16:03:32 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 16:02:06 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 5281) Multicast Listener Discovery draft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new draft has been submitted, specifying the Multicast Listener Discovery (MLD) protocol, which, like Neighbor Discovery, is a part of ICMPv6. MLD is the IPv6 equivalent of IPv4's IGMPv2. If you want a copy before it appears in the I-D directories, you can fetch it from: ftp://ftp-eng.cisco.com/deering/draft-ietf-ipngwg-mld-00.txt Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 16:44:38 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA08671 for ipng-dist; Fri, 6 Mar 1998 16:38:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA08664 for ; Fri, 6 Mar 1998 16:38:07 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA17290 for ; Fri, 6 Mar 1998 16:37:58 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id QAA11162 for ; Fri, 6 Mar 1998 16:37:52 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA16240; Fri, 6 Mar 98 16:35:00 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA01994; Fri, 6 Mar 1998 16:39:12 -0800 Date: Fri, 6 Mar 1998 16:39:12 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803070039.QAA01994@feller.mentat.com> To: deering@cisco.com Subject: (IPng 5282) Re: Source Address Selection Issue and Scoping Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > I tend to agree with the latter part of that sentence, though I don't think > that's the entire real point, since *some* of the same issues under discussion > still arise just between link-local and global. > > Site-local addresses made more sense in some of the earlier stages of > SIP and SIPP development, based on ideas that no longer apply in IPv6. I > would be quite happy to delete site-local unicast addresses entirely from > IPv6 if we had consensus on that (though the notion of site boundaries would > still appear in the scope field of multicast address) -- it would simplify > the implementations and the specs, and eliminate much of the confusion and > design choices of the sort we have been discussing. However, I don't recall > consensus ever being reached about net 10 in the IPv4 world. Does anyone in > the IPv6 community want to speak up in favor of site-local addesses? > > (Note: if we eliminated site-local addresses, we could always add them back > in in the future if absolutely necessary, using the net 10 approach, i.e., > simply designating one global prefix for private use.) > I would not be disappointed to see site-local addresses go. There are a number of nasty problems with them (name resolution, site boundary issues , source address selection issues, etc.) which make them pretty complex to deal with in an implementation for the limited benefit they provide. > (I realize that I probably sound rather inconsistent here, on the one hand > arguing for flexibility in how site-local address may be used, and on the > other hand being content to see them eliminated altogether. But I don't think > I am contradicting myself: I prefer the minimum number of mechanisms that > achieve the maximum "power"/capability/generality. *If* we are going to > keep site-local addresses, I think we should not unnecessarily constrain > their possible use.) > I agree with your position so it must be inconsistent.:-). I think it would be a mistake to outlaw certain combinations of source and destination addresses, particularly link-local source, global destination. I believe that we can come up with a source selection algorithm (most implementations already have) which will bias source address selection toward matching a destination address with a like scoped source address without precluding other combinations if an exact match cannot be found. Adding the new destination unreachable code is probably a good idea although I have been using the administratively prohibited code for this case and I think we could get by just fine doing that. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 6 17:30:17 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id RAA08754 for ipng-dist; Fri, 6 Mar 1998 17:23:11 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id RAA08747 for ; Fri, 6 Mar 1998 17:23:00 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id RAA08214; Fri, 6 Mar 1998 17:22:52 -0800 (PST) Date: Fri, 6 Mar 1998 17:04:01 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5283) Re: Source Address Selection Issue and Scoping To: Steve Deering Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think we should *not* impose the requirement that scope of the source > and destination addresses be the same, because I don't think it necessary > for correctness and, as Margaret said, it may cut off potentially useful > behaviors. I agree that (at least) the source address can have a larger scope than the destination address (e.g. using a global source when sending to a site-local destination). The reverse is more tricky (I think). See below. > For example, if a human types "ping " from a node that > only has link-local and site-local addresses, the node should go ahead > and try to send the packet. If the is in the same site > as the source, the packet will be delivered, and that target node ought > to reply by swapping the two (not-equivalently-scoped) addresses. If the > is *not* in the same site as the source, an ICMP error > message should inform the source (and thence the human) of the problem. I think there is some issues in the precedence between between a the scope checks and the deprecated vs. preferred checks. In our implementation we've currently made the choice that if there is no preferred address available we'll try to use a deprecated address as the source. While this might violate the letter of RFC 1971 is errs on the side of "try communicating since it might work" instead of just giving up. Using a smaller scoped source for a larger scoped destination follows the same idea of trying to communicate. However, when you combine the two you have to answer the question of precedence. For example: A node has two valid addresses: a global deprecated address and a preferred site-local address. When sending to a global address should it 1. use the deprecated global address? 2. use the preferred site-local address? 3. give up without even trying? If you choose #1 then communication with succeed if the destination is outside the site and the routing infrastructure will still route packets back to the deprecated address. It will fail if the routing infrastructure is not capable of routing to the deprecated address even if the destination happens to be in the same site. If you choose #2 then communication will always work within the same site. However, if the global destination is outside the site it will always fail. My gut feel is that #1 is better since routing need to be working to support existing connections which use the deprecated address. Comments? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 11:22:39 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA09635 for ipng-dist; Sat, 7 Mar 1998 11:19:04 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA09628 for ; Sat, 7 Mar 1998 11:18:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA05732 for ; Sat, 7 Mar 1998 11:18:51 -0800 Received: from digi-data.com (odin.digi-data.com [196.32.33.17]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA02728 for ; Sat, 7 Mar 1998 11:18:48 -0800 (PST) Received: by odin.digi-data.com id <19596>; Sat, 7 Mar 1998 15:16:17 -0400 Date: Sat, 7 Mar 1998 15:17:34 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Steve Deering CC: Christian Huitema , ipng@sunroof.eng.sun.com Subject: (IPng 5284) Re: Source Address Selection Issue and Scoping References: Robert Honore "(IPng 5274) Re: Source Address Selection Issue and Scoping" (Mar 6, 5:53pm) Your message of "Fri 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> <98Mar6.175155gmt-0400.19596@odin.digi-data.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <98Mar7.151617gmt-0400.19596@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Steve, > (I realize that I probably sound rather inconsistent here, on the one hand > arguing for flexibility in how site-local address may be used, and on the > other hand being content to see them eliminated altogether. But I don't think > I am contradicting myself: I prefer the minimum number of mechanisms that > achieve the maximum "power"/capability/generality. *If* we are going to > keep site-local addresses, I think we should not unnecessarily constrain > their possible use.) > I suppose this is what should have been said all along. If we are going to keep site-local addresses, we should at least establish some convention that we can all agree with regarding their use and selection. I do not believe we will lose much if we do eliminate site-local addresses, though. Thanks, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 15:06:39 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA09793 for ipng-dist; Sat, 7 Mar 1998 15:03:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA09786 for ; Sat, 7 Mar 1998 15:02:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA23208 for ; Sat, 7 Mar 1998 15:02:57 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA00542 for ; Sat, 7 Mar 1998 15:02:56 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04000; Sat, 7 Mar 98 15:00:03 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA02665; Sat, 7 Mar 1998 15:04:15 -0800 Date: Sat, 7 Mar 1998 15:04:15 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803072304.PAA02665@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5285) Advanced Sockets API Issue X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, While I have been implementing the advanced socket API I reached the conclusion that the IPV6_PKTOPTIONS option is flawed and we need to modify its definition. Currently the IPV6_PKTOPTIONS option is used in conjunction with setsockopt to set the "sticky" options on an AF_INET6 socket. This is reasonable. However, its behavior when used with getsockopt seems problem- atic. Ascurrently defined, when used with getsockopt it is supposed to return the options which have been most recently received on the socket from a peer. This definition leaves us with no way to query the socket to determine what "sticky" options have been configured on the socket. This seems wrong. The analagous IPv4 option, IP_OPTIONS, does not behave this way and I don't see a reason why IPV6_PKTOPTIONS should either. I would suggest an alternate definition of IPV6_PKTOPTIONS which defines its getsockopt behavior as returning all the "sticky" options con- figured on the socket. Of course making this change will require that we come up with an alternate mechanism for TCP sockets to receive ancillary data. The easiest way and I believe the superior way to do this is to allow TCP socket to use recvmsg to receive ancillary data. We would still forbid TCP sockets from using sendmsg to send ancillary data. Comments? Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 16:06:52 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA09859 for ipng-dist; Sat, 7 Mar 1998 15:58:59 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id PAA09852 for ; Sat, 7 Mar 1998 15:58:50 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with ESMTP id PAA23487; Sat, 7 Mar 1998 15:58:49 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.8.8+Sun/8.8.8) id PAA07503; Sat, 7 Mar 1998 15:57:38 -0800 (PST) Date: Sat, 7 Mar 1998 15:57:38 -0800 (PST) From: Mukesh Kacker Message-Id: <199803072357.PAA07503@lucknow.eng.sun.com> To: thartric@mentat.com Subject: (IPng 5286) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com, mukesh@lucknow.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > While I have been implementing the advanced socket API I reached > the conclusion that the IPV6_PKTOPTIONS option is flawed and we need to > modify its definition. > I am implementing parts of it here at Sun. I have reached a similar conclusion about IPV6_PKTOPTIONS use in context of TCP. [ I also believe there are many other flaws in the Advanced API... particularly with CMSG_SPACE and CMSG_LEN not being workable with other alignment choices. I pointed out some of these problems in ipng messages 4240/4241. The fixes are easy but the issues did not get discussed at all. There are other flaws and issues too...which I was hoping to attend at next IETF but now it got elevated to Info RFC ....not sure how to affect changes now :-( ] Getting back to IPV6_PKTOPTIONS... > Currently the IPV6_PKTOPTIONS option is used in conjunction with > setsockopt to set the "sticky" options on an AF_INET6 socket. This is > reasonable. However, its behavior when used with getsockopt seems problem- > atic. Ascurrently defined, when used with getsockopt it is supposed > to return the options which have been most recently received on the socket > from a peer. This definition leaves us with no way to query the socket to > determine what "sticky" options have been configured on the socket. This > seems wrong. The analagous IPv4 option, IP_OPTIONS, does not behave this > way and I don't see a reason why IPV6_PKTOPTIONS should either. > I agree that defining getsockopt() according to your suggestion seems more useful. > I would suggest an alternate definition of IPV6_PKTOPTIONS which > defines its getsockopt behavior as returning all the "sticky" options con- > figured on the socket. Of course making this change will require that we > come up with an alternate mechanism for TCP sockets to receive ancillary > data. The easiest way and I believe the superior way to do this is to > allow TCP socket to use recvmsg to receive ancillary data. We would still > forbid TCP sockets from using sendmsg to send ancillary data. > I am not sure I like the idea of using recvmsg() to push ancillary data with TCP. I like the "pull-on-demand" model that getsockopt() provides (not to mention I wonder about the real usefullness or utility of ancillary data from "most recently received datagram" to TCP applications :-)) The kernel is not really aware what API call (recv/read/recvmsg) that the application would use so pushing them all the time is more work. One idea I had was to define a IPV6_RCV_PKTOPTIONS which would apply to the receive side context. Ideally I would like the current IPV6_PKTOPTIONS renamed to IPV6_SND_PKTOPTIONS in that case. Another idea I had was more radical. This involves inventing generic Socket level options SO_SND_CMSG and SO_RCV_CMSG and using the same design for it as current IPV6_PKTOPTIONS This was based on the observation that most of the code that I was reusing was from generic SOcket API for implementing IP layer functionality. We could view these IPV6_PKTIONS as hacks to extend the Socket API with an ability that it does not have...an ability to set/receive "groups of options" or ability to send "groups of ancillary data" before the state machine allows for sendmsg/recvmsg calls. (eg. before connection establishment). In the current design the level IPV6_PKTIONS is repeated at both the "level" field of setsockopt/getsockopts and in each embedded cmsghdr cmsg_level field as well. which is hokey. Having something like SO_SND_CMSG and SO_RCV_CMSG is clean way to send and receive "control message buffers" which can also be used for IPV6. I am sure there are more details and error semantics to be worked out, but I hope this conveys the general idea. Any comments ? -Mukesh Kacker -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 16:36:17 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA09910 for ipng-dist; Sat, 7 Mar 1998 16:28:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA09903 for ; Sat, 7 Mar 1998 16:28:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA08643 for ; Sat, 7 Mar 1998 16:28:09 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA21406 for ; Sat, 7 Mar 1998 16:28:09 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05202; Sat, 7 Mar 98 16:25:08 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA02724; Sat, 7 Mar 1998 16:29:22 -0800 Date: Sat, 7 Mar 1998 16:29:22 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803080029.QAA02724@feller.mentat.com> To: Mukesh.Kacker@Eng Subject: (IPng 5287) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, > > I am not sure I like the idea of using recvmsg() to push ancillary data > with TCP. I like the "pull-on-demand" model that getsockopt() provides > (not to mention I wonder about the real usefullness or utility of > ancillary data from "most recently received datagram" to TCP applications > :-)) > The kernel is not really aware what API call (recv/read/recvmsg) that the > application would use so pushing them all the time is more work. > I was not suggesting every TCP socket be subjected to a barrage of completely unsolicited ancillary data. That would be really bad. What I was suggesting was that if an TCP socket sets the IPPROTO_IPV6/ IPV6_HOPOPTS option that the transport provides the most recently received hop-by-hop options to the socket. If the application chooses to receive them it can by using recvmsg. If it uses some other call to receive data then the pending ancillary data gets discarded. The burden is placed only on the shoulders of those who request it. > One idea I had was to define a IPV6_RCV_PKTOPTIONS which would apply to > the receive side context. Ideally I would like the current IPV6_PKTOPTIONS > renamed to IPV6_SND_PKTOPTIONS in that case. > > Another idea I had was more radical. > This involves inventing generic Socket level options SO_SND_CMSG and > SO_RCV_CMSG and using the same design for it as current IPV6_PKTOPTIONS > > This was based on the observation that most of the code that I was reusing > was from generic SOcket API for implementing IP layer functionality. > We could view these IPV6_PKTIONS as hacks to extend the Socket API with > an ability that it does not have...an ability to set/receive "groups of > options" or ability to send "groups of ancillary data" before the state > machine allows for sendmsg/recvmsg calls. (eg. before connection > establishment). > > In the current design the level IPV6_PKTIONS is repeated at both the > "level" field of setsockopt/getsockopts and in each embedded cmsghdr > cmsg_level field as well. which is hokey. Having something like > SO_SND_CMSG and SO_RCV_CMSG is clean way to send and receive > "control message buffers" which can also be used for IPV6. > > I am sure there are more details and error semantics to be worked out, > but I hope this conveys the general idea. > Hmm.... I need to think about this a little. I like the idea of creating a generic option sequence mechanism for setting options. Your SO_SND_CMSG facility would fit quite nicely here. I am not sure about the need for the SO_RCV_CMSG portion. If the recvmsg mechansim I described above can be made to work efficiently, which I believe it can, I think it would obviate the need for the SO_RCV_CMSG facility. Tim Hartrick tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 16:51:50 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA09937 for ipng-dist; Sat, 7 Mar 1998 16:48:19 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id QAA09930 for ; Sat, 7 Mar 1998 16:48:09 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with ESMTP id QAA27329; Sat, 7 Mar 1998 16:48:08 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.8.8+Sun/8.8.8) id QAA07510; Sat, 7 Mar 1998 16:46:56 -0800 (PST) Date: Sat, 7 Mar 1998 16:46:56 -0800 (PST) From: Mukesh Kacker Message-Id: <199803080046.QAA07510@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, thartric@mentat.com Subject: (IPng 5288) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I was not suggesting every TCP socket be subjected to a barrage of completely > unsolicited ancillary data. That would be really bad. > That is not what I implied either. Ofcourse all this activity is specific to the endpoint. > What I was suggesting was that if an TCP socket sets the IPPROTO_IPV6/ > IPV6_HOPOPTS option that the transport provides the most recently received > hop-by-hop options to the socket. If the application chooses to receive them > it can by using recvmsg. If it uses some other call to receive data then > the pending ancillary data gets discarded. > This "pending ancillary data gets discarded" is the unnecesary work I was referring to. > The burden is placed only on the shoulders of those who request it. > Yes. So it is in the case of retrieval by getsockopt(). Also, I think the "ancillary data" being delivered *together with* regular data has natural semantics only in the context of a datagram protocol. With a byte-stream protocol, we are ending up having to invent more hacks like saying it is illegal on sendmsg() and legal on recvmsg(). There is also not necessarily any "correlation" to stuff in data buffer as this ancillary data is only from "most recent datagram". There are other issues too. So what happens when there is no incoming data ? Return zero length ? With TCP zero-length data already has EOF/half-close semantics .... So would you block on trying to receive ancillary data from "most recently received datagram" just because there is no data flowing ? That also seems unnecessary. Using getsockopt(), which is independent of the data flow stream seems more natural to use in the context of TCP for that reason. The "ancillary data" in that case has not much "correlation" to the byte-stream data flow. > > Hmm.... I need to think about this a little. I like the idea of creating > a generic option sequence mechanism for setting options. Your SO_SND_CMSG > facility would fit quite nicely here. I am not sure about the need for the > SO_RCV_CMSG portion. If the recvmsg mechansim I described above can be made > to work efficiently, which I believe it can, I think it would obviate the > need for the SO_RCV_CMSG facility. > The SND and RCV are general way of conveying user-to-kernel and "kernel-to-user" or send and receive direction and in general symmetric. In BSD implmentations, the SND prefix was not used, but there was definitely good practice in using "RECV" prefix such as in IP_RECVDSTADDR and IP_RECVOPTS datagram specific options to separate them from any send side similar semantics. That is what inspires these names. [ If I had my way, the "SND" and "RCV" prefixes would be there on other options too. :-) e.g The IPV6_HOPLIMIT for send has receive side has completely different connotations. Where the semantics are different, no harm in having a different name ] -Mukesh Kacker -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 17:46:19 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id RAA10023 for ipng-dist; Sat, 7 Mar 1998 17:37:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id RAA10016 for ; Sat, 7 Mar 1998 17:37:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA12157 for ; Sat, 7 Mar 1998 17:37:45 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id RAA08698 for ; Sat, 7 Mar 1998 17:37:46 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA06200; Sat, 7 Mar 98 17:34:48 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA02747; Sat, 7 Mar 1998 17:39:02 -0800 Date: Sat, 7 Mar 1998 17:39:02 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803080139.RAA02747@feller.mentat.com> To: Mukesh.Kacker@Eng Subject: (IPng 5289) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, > > This "pending ancillary data gets discarded" is the unnecesary work > I was referring to. > But the code to do this "extra" work already exists because it has to be there to support the RAW and DGRAM sockets. Also, the work the transport needs to do to retain the most recently received options is essentially equivalent to the unnecessary work that you are saying you don't want to do. The transport will need to continuously copy options out of segments and hold them some where until there are requested. Most of the time they won't be requested but they will still need to be held and repeatedly replaced with the latest copy in the event that they are requested. I don't see any savings in overhead. I just see more complexity in the transport. > Also, I think the "ancillary data" being delivered *together with* regular > data has natural semantics only in the context of a datagram protocol. > > With a byte-stream protocol, we are ending up having to invent more > hacks like saying it is illegal on sendmsg() and legal on recvmsg(). > There is also not necessarily any "correlation" to stuff in data > buffer as this ancillary data is only from "most recent datagram". > But hobbling both sendmsg and recvmsg for STREAM sockets is also a hack. I would like the ancillary data mechanisms used by RAW, DGRAM and STREAM sockets to be as close to the same as possible. Would we need to implement the SO_RCV_CMSG option for RAW and DGRAM sockets? If not then isn't that a hack just like not being able to use sendmsg with ancillary data for STREAM sockets is a hack? If so then aren't we doubling our work for RAW and DGRAM sockets? > There are other issues too. > So what happens when there is no incoming data ? Return zero length ? > With TCP zero-length data already has EOF/half-close semantics .... I would treat ancillary data as ancillary data. If I have ancillary data to give the user but I don't have any or enough real data to satisfy the user's request I would block. I don't think this changes EOF semantics but I may be missing something. > So would you block on trying to receive ancillary data from "most recently > received datagram" just because there is no data flowing ? That also > seems unnecessary. > Ancillary data is ancillary data. You shouldn't block waiting for it to arrive because it might not ever arrive. This is no different than on a RAW or DGRAM socket. If you didn't return from a recvmsg call on a DGRAM socket until you had ancillary data sufficient to satisfy the users request then you couldn't receive datagrams from systems that didn't send you options. That would be broken. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 18:27:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA10115 for ipng-dist; Sat, 7 Mar 1998 18:16:30 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id SAA10108 for ; Sat, 7 Mar 1998 18:16:21 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with ESMTP id SAA00568; Sat, 7 Mar 1998 18:16:20 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.8.8+Sun/8.8.8) id SAA07522; Sat, 7 Mar 1998 18:15:09 -0800 (PST) Date: Sat, 7 Mar 1998 18:15:09 -0800 (PST) From: Mukesh Kacker Message-Id: <199803080215.SAA07522@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, thartric@mentat.com Subject: (IPng 5290) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > This "pending ancillary data gets discarded" is the unnecesary work > > I was referring to. > > > > But the code to do this "extra" work already exists because it has to be > there to support the RAW and DGRAM sockets. > .. > I don't see any savings in overhead. I just see more complexity in > the transport. > I was referring to the "runtime" saving in delivery of data. The copying of "enabled" option received side data with every datagram ofcourse is not avoided. With proper soubroutines to parse cmsghdr buffers, I do not think it would add any more complexity than IPV6_PKTOPTIONS would. > > But hobbling both sendmsg and recvmsg for STREAM sockets is also a > hack. I would like the ancillary data mechanisms used by RAW, DGRAM > and STREAM sockets to be as close to the same as possible. > I am not sure I got the "hobbling" part. I do not think there is much utility in getting them "as same as possible" as datagram and bytestream protocols are just different. More on this "ancillary data" on byte stream protocols later. > Would we need to implement the SO_RCV_CMSG option for RAW and DGRAM > sockets? If not then isn't that a hack just like not being able to > use sendmsg with ancillary data for STREAM sockets is a hack? If so > then aren't we doubling our work for RAW and DGRAM sockets? > Yes, that is proposed as a more "general purpose" mechanism to replace current IPV6_PKTOPTIONS. [ embedded cmsg_level is enough to carry the level+name identification ]. It applies to RAW and DGRAM as much as IPV6_PKTOPTIONS does as means for "sticky options" > > I would treat ancillary data as ancillary data. If I have ancillary data > to give the user but I don't have any or enough real data to satisfy the user's > request I would block. I don't think this changes EOF semantics but I > may be missing something. > OK...got it that is a good enough semantics for the API. You can block. But more on this "ancillary data" for bytestream protocols later... > Ancillary data is ancillary data. You shouldn't block waiting for it > to arrive because it might not ever arrive. > This is no different than > on a RAW or DGRAM socket. If you didn't return from a recvmsg call on > a DGRAM socket until you had ancillary data sufficient to satisfy the > users request then you couldn't receive datagrams from systems that didn't > send you options. That would be broken. > So how "Ancillary" is this ancillary data for byte stream protocols ? Not really from a dictionarlly but I would thing "ancillary" as auxillary or related to accompanying user data. How much of that correlation can you guarantee for byte-stream protocols ? Maybe you can say that it probably came with atleast the last byte in the user data ? I am not even sure of that ! If you are buffering in the kernel more than what you are delivering in a chunk to a receive primitive, you are delivering the attributes fromm the "most recently received datagram" along with data that has absolutely no correlation to it!. SO I do not think that sending it in recmsg() makes it politically correct ancillary data. Bytestream protocols are just different beast when it comes to "ancillary data". Note also that we are discussing two somewhat orthogonal issues here. The main issue we are discussing/disagreeing on is receiving sticky options for TCP via "getsockopt() vs recvmsg()". My SO_*_CMSG idea is independent/orthogonal idea and more general purpose design of IPV6_PKTOPTIONS regardless of the stands on "sticky options deliver to TCP" issue. It is as complex/simple as current IPV6_PKTPTIONS design. Since you have been gracious enough to think about SO_*_CMSG here is some ascii art included to convey more of idea of what I was thinking. We can decide/resolve/talk later the issue of disagreements which are on "getsockopt() vs recvmsg() for TCP" issue. :-) --------------------------------------------------------------- \ Operations | getsockopt | setsockopt | Option\ | | | ---------------------------------------------------------------- | | | SO_SND_CMSG | retrieve what | "set" send side cmsg | | was set | attributes on endpoint | | | based on semantics | ---------------------------------------------------------------- | get the rcv | | SO_RCV_CMSG | control msg | illegal(EOOPNOTSUPP ?) | | buffer with | | | option receive | | | side attributes | | | enabled with | | | other "boolean" | | | setsockopt() | | |e.g. IPV6_HOPLIMIT| | | setsockopt. | | ---------------------------------------------------------------- -Mukesh Kacker -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 18:57:54 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA10200 for ipng-dist; Sat, 7 Mar 1998 18:53:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA10193 for ; Sat, 7 Mar 1998 18:53:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA16569 for ; Sat, 7 Mar 1998 18:53:30 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA27615 for ; Sat, 7 Mar 1998 18:53:32 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA07162; Sat, 7 Mar 98 18:50:39 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id SAA02772; Sat, 7 Mar 1998 18:54:52 -0800 Date: Sat, 7 Mar 1998 18:54:52 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803080254.SAA02772@feller.mentat.com> To: Mukesh.Kacker@Eng Subject: (IPng 5291) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, > .. > > I don't see any savings in overhead. I just see more complexity in > > the transport. > > > > I was referring to the "runtime" saving in delivery of data. The copying > of "enabled" option received side data with every datagram ofcourse is not > avoided. With proper soubroutines to > parse cmsghdr buffers, I do not think it would add any more > complexity than IPV6_PKTOPTIONS would. > I was also referring to runtime overhead. The difference between your SO_RCV_CMSG getsockopt and using recvmsg to retrieve the ancillary data in a BSD implementation would be nothing. In a STREAMS environment my proposal would have slightly more overhead. The dominant runtime cost is the data copies and those happen regardless. > > Would we need to implement the SO_RCV_CMSG option for RAW and DGRAM > > sockets? If not then isn't that a hack just like not being able to > > use sendmsg with ancillary data for STREAM sockets is a hack? If so > > then aren't we doubling our work for RAW and DGRAM sockets? > > > > Yes, that is proposed as a more "general purpose" mechanism to replace > current IPV6_PKTOPTIONS. [ embedded cmsg_level is enough to carry the > level+name identification ]. It applies to RAW and DGRAM as much as > IPV6_PKTOPTIONS does as means for "sticky options" > So DGRAM and RAW transports also need to save off the "most recently" received options so that they can be retrieved with SO_RCV_CMSG. But they also need to support recvmsg ancillary data. For a BSD implementation this is not big deal. For a STREAMS implementation it will almost certainly mean extra code in the datagram transports. I am down on extra code for options. > > How much of that correlation can you guarantee for byte-stream protocols ? > None. Why does there have to be a direct correlation between the ancillary data and the regular data for a STREAM socket? > Maybe you can say that it probably came with atleast the last byte in the > user data ? I am not even sure of that ! > I don't think we even need to say it probably came with the last byte of user data. All we need to say is that it arrived in conjunction with this connection. > If you are buffering in the kernel more than what you are delivering > in a chunk to a receive primitive, you are delivering the attributes > fromm the "most recently received datagram" along with data that has > absolutely no correlation to it!. SO I do not think that sending > it in recmsg() makes it politically correct ancillary data. > > Bytestream protocols are just different beast when it comes to "ancillary > data". > Yes they are different beasts. Ancillary data which arrives on a STREAM socket has no corellation to the regular data except that it arrived on the same connection. Why do we need to have more correlation than that? > > Note also that we are discussing two somewhat orthogonal issues here. > Yes, that is correct. > The main issue we are discussing/disagreeing on is receiving sticky > options for TCP via "getsockopt() vs recvmsg()". > Well they are not actually sticky. The options I set with with IPV6_- PKTOPTIONS are sticky. The options which are received by my TCP from the remote system are not sticky with respect to my local TCP unless the application chooses to reverse the source route or use the same destination options as my peer and communicates that via the IPV6_PKTOPTIONS option. What we are disagreeing about is the method used to retrieve the options which the remote system is sending. They are sticky for the remote TCP not for the local TCP unless explicitly set. > My SO_*_CMSG idea is independent/orthogonal idea and more general purpose > design of IPV6_PKTOPTIONS regardless of the stands on "sticky options > deliver to TCP" issue. It is as complex/simple as current IPV6_PKTPTIONS > design. > I agree. I would not be against replacing IPV6_PKTOPTIONS with a option called SO_CMSGHDR or something. This replacement would be a generic way to set and get a sequence of ancillary data items for a variety of levels via a single call to setsockopt or getsockopt respectively. It is a good idea. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 7 19:43:42 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id TAA10280 for ipng-dist; Sat, 7 Mar 1998 19:39:59 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id TAA10273 for ; Sat, 7 Mar 1998 19:39:50 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with ESMTP id TAA03920; Sat, 7 Mar 1998 19:39:51 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.8.8+Sun/8.8.8) id TAA07541; Sat, 7 Mar 1998 19:38:39 -0800 (PST) Date: Sat, 7 Mar 1998 19:38:39 -0800 (PST) From: Mukesh Kacker Message-Id: <199803080338.TAA07541@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, thartric@mentat.com Subject: (IPng 5292) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I was also referring to runtime overhead. The difference between your > SO_RCV_CMSG getsockopt and using recvmsg to retrieve the ancillary data > in a BSD implementation would be nothing. In a STREAMS environment my > proposal would have slightly more overhead. The dominant runtime cost > is the data copies and those happen regardless. > OK. though I am not dwelling on any BSD vs STREAMS implmentation issues here as the reason for preferring one approach or the other. > > So DGRAM and RAW transports also need to save off the "most recently" > received options so that they can be retrieved with SO_RCV_CMSG. But > they also need to support recvmsg ancillary data. For a BSD implementation > this is not big deal. For a STREAMS implementation it will almost > certainly mean extra code in the datagram transports. I am down on > extra code for options. > I (mis?)read your initial getsockopt(...IPV6_PKTOPTIONS...) semantics change as a TCP-only suggestion. I assume now you also implied it for RAW and datagram transports. I think it makes sense there too. I like it! :-) > > None. Why does there have to be a direct correlation between the ancillary > data and the regular data for a STREAM socket? > > > Maybe you can say that it probably came with atleast the last byte in the > > user data ? I am not even sure of that ! > > > > I don't think we even need to say it probably came with the last byte of > user data. All we need to say is that it arrived in conjunction with this > connection. > .... > > Yes they are different beasts. Ancillary data which arrives on a STREAM > socket has no corellation to the regular data except that it arrived on > the same connection. Why do we need to have more correlation than that? > We have some disagreement here. Unless "ancillary data" has some relevance to the accompanying data, I do not find it a useful interface for applications. Just needless complexity. We can specify whatever, but I do not see use for it. > Well they are not actually sticky. The options I set with with IPV6_- > PKTOPTIONS are sticky. The options which are received by my TCP from > the remote system are not sticky with respect to my local TCP unless the > application chooses to reverse the source route or use the same destination > options as my peer and communicates that via the IPV6_PKTOPTIONS option. > OK> I stand corrected. There is nothing "sticky" about receive side attributes, even when retrieved by IPV6_PKTOPTIONS/SO_RCV_CMSG/SO_CMSG/ recvmsg() ...whatever. > What we are disagreeing about is the method used to retrieve the options > which the remote system is sending. Yes. I see ancillary data as useful when it bears some correlation to accompanying user data. A bunch of attributes/fields from the "most recently received datagram" on a byte stream transport are a strange thing which should be received via a separate options mechanism. > > I agree. I would not be against replacing IPV6_PKTOPTIONS with a option > called SO_CMSGHDR or something. This replacement would be a generic way > to set and get a sequence of ancillary data items for a variety of levels > via a single call to setsockopt or getsockopt respectively. It is a good > idea. > SO_CMSGHDR or whatever. Names are not important...though as a general grouping mechanism that name fine. It is certainly fine if your recvmsg() idea prevails. There is still the general issue that without a way of enconding send or recieve side attributes when something exists for both sides. (e.g hoplimit makese sense for both sides, "nexthop" may not). Either you can encode it in the name of the option like IP_RECV* options in IPv4 ...but that seems to have not been done for IPV6. And I guess I still want to retrieve a "bunch of receive side attributes" not as part of "ancillary data" for TCP but I will sit back and think more about it. That's enough for today :-) -Mukesh Kacker PS: Anyone know why IPV6_NEXTHOP is of type sockaddr and not sockaddr_in6 ? So what is the semantics if "level" is IPPROTO_IPV6 (v4) but family is AF_INET ? Or something else ? Why do things mean when family is different than level ? Just wondering... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 8 11:48:30 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA11609 for ipng-dist; Sun, 8 Mar 1998 11:41:02 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA11602 for ; Sun, 8 Mar 1998 11:40:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA15006 for ; Sun, 8 Mar 1998 11:40:50 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA29325 for ; Sun, 8 Mar 1998 11:40:45 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA08317; Mon, 9 Mar 1998 06:40:38 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.eng.sun.com Subject: (IPng 5293) Re: Source Address Selection Issue and Scoping In-Reply-To: Robert Honore's message of "Fri, 06 Mar 1998 15:34:40 -0400." References: Your message of "Fri, 06 Mar 1998 09:23:07 EST." <9803060923.aa26966@khitomer.epilogue.com> <98Mar6.153312gmt-0400.19590@odin.digi-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Mar 1998 06:40:38 +1100 Message-Id: <29172.889386038@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 6 Mar 1998 15:34:40 -0400 From: Robert Honore Message-ID: <98Mar6.153312gmt-0400.19590@odin.digi-data.com> I agree with Margaret and Steve ... | I would disagree with you there, Steve. If node A has only a link local | and it should attempt to send a packet to node B's site local or B's | global address, there is no way to show **topologically** that A can | reach B or vice versa. Why should you try to send a packet to a node | you have no acceptable reason to believe you can reach? In order to find out whether or not I can reach it, of course! With link local addresses there's probably little point, there being better ways to determine if another address is on the same link, but with sites, discovering if some random global address is in my site is not easy. But one easy way would be to send from my site local address to its global address, if I get a response, I know it is in my site (the packet may even be asking for a site local address for it). If we assume that for the majority of sites that reaching the site border router is relatively cheap and quick, and that we do create an ICMP code to indicate "you can't get there with that address", then when presented with a global address unknown before, sending an exploratory "are you in my site and if so, what's your site local address" packet would seem like a reasonable strategy. In a later message ... robert@digi-data.com said: | Even though I must agree with you that there is no need to forbid the | attempt, which is exactly the point of course, not whether it ought routinely be done, but whether it ought be forbidden. Then, on much the same topic ... Erik.Nordmark@Eng.Sun.COM said: | I agree that (at least) the source address can have a larger scope | than the destination address (e.g. using a global source when sending | to a site-local destination). The reverse is more tricky (I think). Uh - no - the two are entirely equivalent. If I send to you from global scope to local (or site) scope, then you are required to send to me from lcoal (or site) scope to global scope. You can't have one without the other (or not in any communication that will be useful). On your question of deprecated vs site local addresses to use when there is no preferred address, I think you're asking the wrong question. The first question ought be, should I use site local or global addresses for this communication? Having answered that, and decided that you want to use a global address, then if there is no preferred address available, you use the deprecated one, deciding to reverse the earlier answer and switch back to site local would be silly. Then, having said all that, I also mostly agree with Christian, and Steve (etc) that we could easily live without site local addresses, at least, when any global addresses exist. They might just have some utility in the unconnected complex network (the true analog of net 10), but where a global address exists, I would just as soon prefer that it be used always (with link local reserved for communications that must be on the local link only, like "I am a router on this link" etc, and where no other addresses exist at all). I certainly believe that we ought be finding some better way of making connections survive renumbering than the "if you just use site local addresses all the important connections will survive" mentality. Long distance communications can be important too. However, we can't do that just by fixing TCP, as TCP isn't all that counts, I want my UDP NFS mounts to survive renumbering as well... (and my knowledge of where various nameservers live in the DNS, etc etc etc). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 8 19:03:30 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA11956 for ipng-dist; Sun, 8 Mar 1998 18:56:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA11949 for ; Sun, 8 Mar 1998 18:55:51 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA04833 for ; Sun, 8 Mar 1998 18:55:43 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA00079 for ; Sun, 8 Mar 1998 18:55:44 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id VAA06506; Sun, 8 Mar 1998 21:54:34 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09082; Sun, 8 Mar 1998 21:53:51 -0500 Message-Id: <199803090253.AA09082@wasted.zk3.dec.com> To: Steve Deering Cc: robert@digi-data.com, ipng@sunroof.eng.sun.com Subject: (IPng 5294) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Fri, 06 Mar 1998 12:07:19 PST." Date: Sun, 08 Mar 1998 21:53:50 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I emphatically disagree with your view of correctness. I won't respond further as my previous mail explained why I disagree with your view and you did not respond to that mail so I will not respond to yours, as this is a philosophical difference and not a "technical" one. I have studied this as an implementor and product engineer as to what is best for users and I strongly disagree with ever sending any packets that can fail on a network regardless of IPv6. We have had this debate for four years on various topics. You and I probably need to agree we just disagree, but my hope is others in the WG agree with me, and not you. But based on the short mail thus far it needs to be discussed possibly as an agenda item for L.A. I do think we need an ICMP error message though for the case discussed regardless of the outcome of WG consensus on this issue, I think that has consensous. Also note Brian Carpenters mail from the IPv6 Multicast Routing Group where forcing equal scope requirements may make that problem a moot issue. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 8 19:07:47 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id TAA11974 for ipng-dist; Sun, 8 Mar 1998 19:05:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id TAA11967 for ; Sun, 8 Mar 1998 19:04:56 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA06060 for ; Sun, 8 Mar 1998 19:04:54 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id TAA03129 for ; Sun, 8 Mar 1998 19:04:54 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id WAA28666; Sun, 8 Mar 1998 22:04:53 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09272; Sun, 8 Mar 1998 22:04:53 -0500 Message-Id: <199803090304.AA09272@wasted.zk3.dec.com> To: robert@digi-data.com Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 5295) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Fri, 06 Mar 1998 17:53:20 -0400." <98Mar6.175155gmt-0400.19596@odin.digi-data.com> Date: Sun, 08 Mar 1998 22:04:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If we do decide this is an issue, but we decide to use a SHOULD here is what will happen in the market IMO. No vendor will implement checking for equal scope and not send a packet they will always send a lesser scope. Here is why. Because it is a SHOULD no one will take the competitive risk to be the only vendor supporting not doing it. I think if we believe as a group it is an issue, then we should make it a MUST, and then say it MAY be disabled thru configuration by a user. This is how we have done a few of these pearls which I won't mention because they should not influence this decision IMO. In this manner we tell the user it is better to have equal scope and if you don't you have a problem ---> "health warning"... But if you don't care point-and-click this button and it won't apply. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 8 20:19:04 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id UAA12040 for ipng-dist; Sun, 8 Mar 1998 20:15:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id UAA12033 for ; Sun, 8 Mar 1998 20:15:23 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA22373 for ; Sun, 8 Mar 1998 20:15:22 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA27737 for ; Sun, 8 Mar 1998 20:15:19 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id XAA18435; Sun, 8 Mar 1998 23:12:52 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10373; Sun, 8 Mar 1998 23:12:36 -0500 Message-Id: <199803090412.AA10373@wasted.zk3.dec.com> To: Steve Deering Cc: robert@digi-data.com, ipng@sunroof.eng.sun.com Subject: (IPng 5296) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Fri, 06 Mar 1998 14:49:51 PST." Date: Sun, 08 Mar 1998 23:12:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >I also think it adds unnecessary code complexity and conceptual complexity >to add the restrictions you want to add. IMO not permitting lesser scope makes the algorithm and code more simple. >As I said, I can't predict all the possible advantages, but I can imagine >some, like debugging/testing (e.g., my network manager phones me up and asks >me to ping some global address from my site-local address to *confirm* that >the site-internal routing is convex and working properly). The case of >direct neighbors might be a little less compelling (because all interfaces >have to have link-local addresses), but we do not currently require that all >interfaces have both site-local and global addresses. That means that within >a single site, some nodes might not have global addresses and some might not >have site- local addresses, and it would nice for them to be able to >communicate if they are on different links within the site, since it is >topologically possible and since permitting it does not violate any scoping >rules. This can be solved with a MUST but MAY reconfigure. And it still does not create a lot of implementation complexity, even with a knob check in the code. In the rare case let the user can permit a behavior that may "fail", but the default should be no failures. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 8 20:29:33 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id UAA12080 for ipng-dist; Sun, 8 Mar 1998 20:25:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id UAA12073 for ; Sun, 8 Mar 1998 20:25:42 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA23900; Sun, 8 Mar 1998 20:25:41 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA01486; Sun, 8 Mar 1998 20:25:41 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id XAA11088; Sun, 8 Mar 1998 23:25:40 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10829; Sun, 8 Mar 1998 23:25:39 -0500 Message-Id: <199803090425.AA10829@wasted.zk3.dec.com> To: Erik Nordmark Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 5297) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Fri, 06 Mar 1998 17:04:01 PST." Date: Sun, 08 Mar 1998 23:25:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, I agree with you. IF scope greater AND deprecated ... Is more correct than a lesser scope AND preferred... I do think users would like if we all did this the same? I would not mind if site-local addresses went away. They also create havoc with the multihome case too. Whats a site? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 8 20:35:32 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id UAA12102 for ipng-dist; Sun, 8 Mar 1998 20:32:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id UAA12095 for ; Sun, 8 Mar 1998 20:32:48 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA24424; Sun, 8 Mar 1998 20:32:47 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA03921; Sun, 8 Mar 1998 20:32:44 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id XAA00443; Sun, 8 Mar 1998 23:32:42 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10936; Sun, 8 Mar 1998 23:32:42 -0500 Message-Id: <199803090432.AA10936@wasted.zk3.dec.com> To: Erik Nordmark Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 5298) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Fri, 06 Mar 1998 17:04:01 PST." Date: Sun, 08 Mar 1998 23:32:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As another comment regarding Net 10 for IPv4. I am now hinting in AIIH and street presentations I do in the industry that customers can soon avoid Net 10 and start using IPv6 addresses instead of Net 10 and then when the Internet routes IPv6 addresses they get global addresses again for free and because the IPv6 people are smart -----).......... Seriously I don't know of one customer who "says boy I can't wait to order up my non-global private addresses". They do it because they can't get any IPv4 addresses when its like 200,000 nodes needed. So I don't see why they would want IPv6 site-local addresses. Except for one case. They don't want their users to be able to access the Internet.. But this can be done if you have a global address too quite easily. The security reasons are not trust worthy as a reason for Private Addresses and makes it real hard to ever communicate with IPSEC end-to-end on the Internet if you did need to access the Internet. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 9 06:40:04 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA13885 for ipng-dist; Mon, 9 Mar 1998 06:31:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA13878 for ; Mon, 9 Mar 1998 06:31:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA22298 for ; Mon, 9 Mar 1998 06:30:56 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA02482 for ; Mon, 9 Mar 1998 06:30:54 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: deering@cisco.com, robert@digi-data.com, ipng@sunroof.eng.sun.com In-reply-to: <199803090253.AA09082@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5300) Re: Source Address Selection Issue and Scoping Date: Mon, 9 Mar 98 09:30:30 -0500 Message-ID: <9803090930.aa13109@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound writes: >...and I strongly disagree with ever sending any packets that can >fail on a network regardless of IPv6. Any packet _can_ fail. In general, I agree that we should send packets that have the greatest chance of success (which means using equal scopes for source and destination addresses where possible). This is the "SHOULD" that I believe everyone agrees to -- an equally scoped source address SHOULD be used when IP is given the opportunity to choose the source address AND an equally scoped address is available (even if it has been deprecated). By your reasoning, I believe we should never send DHCP Discover packets unless we have evidence that a DHCP server exists on our network, and we all know you disagree with that :-). However, refusing to send a packet when a higher layer specifically mandates the use of a source and destination which are not equal in scope is going to cause failures when the communication could have succeeded. This is not something that I agree that IP SHOULD "enforce". I believe that, in this case, IP SHOULD send the packet it was told to send, as not all of the "intelligence" of the system will necessarily reside in IP. Some of it could reside in upper-layers or in the mind of a sophisticated user. In general, I agree that the need to use unequal address scopes will only arise when something is "broken" in the network or if the user or upper-layer is trying to do something unusual. However, it can be very useful to try to send packets when something may be broken -- this would allow the use of SNMP or other management or debugging protocols to try to diagnose and repair a mis-configuration, for example. As all of the configuration becomes automatic in IPv6, it is even more important to be able to send and receive packets from nodes that may be mis-configured. >I think if we believe as a group it is an issue, then we should make it >a MUST, and then say it MAY be disabled thru configuration by a user. >This is how we have done a few of these pearls which I won't mention >because they should not influence this decision IMO. When you and I are talking about what should be a MUST or a SHOULD, I think we are actually talking about two different things: You are discussing whether a IP layer MUST or SHOULD _refuse_ to send a packet with unequally-scoped source and destination addresses. Correct me if I'm misunderstanding... I have been agreeing that a host SHOULD use an equally- scoped source address _if available_. I'd even be willing to agree that the IP stack MUST choose an equally- scoped source address _if available_, _unless_ an unequally-scoped address has been mandated by an upper layer. But, I believe that an IP stack also MUST try to send a packet as mandated by the upper layer as long as the source address is a valid local source address (of any scope), regardless of the scope of the destination address. Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Integrated Systems, Inc. FAX: (617) 245-8122 Epilogue Embedded Solutions http://www.epilogue.com 333 North Ave, 4th Floor http://www.isi.com Wakefield, MA 01880, USA Sales: info@epilogue.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 9 07:55:32 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA14022 for ipng-dist; Mon, 9 Mar 1998 07:48:53 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA14015 for ; Mon, 9 Mar 1998 07:48:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA08066 for ; Mon, 9 Mar 1998 07:48:39 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA13196 for ; Mon, 9 Mar 1998 07:47:06 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA26370; Mon, 9 Mar 1998 10:45:57 -0500 (EST) Message-Id: <199803091545.KAA26370@ns.ietf.org> 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@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5301) I-D ACTION:draft-ietf-ipngwg-mld-00.txt Date: Mon, 09 Mar 1998 10:45:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Multicast Listener Discovery (MLD) for IPv6 Author(s) : S. Deering, B. Fenner, B. Haberman Filename : draft-ietf-ipngwg-mld-00.txt Pages : 19 Date : 06-Mar-98 This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol [IGMPv2]. One important difference to note is that MLD uses ICMPv6 [ICMPv6] (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. This document is a product of the IP Next Generation working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipng@sunroof.Eng.Sun.COM and/or the author(s). 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-ietf-ipngwg-mld-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-00.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980306171744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980306171744.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 9 17:33:10 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id RAA14937 for ipng-dist; Mon, 9 Mar 1998 17:25:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id RAA14930 for ; Mon, 9 Mar 1998 17:25:38 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id RAA10788 for ; Mon, 9 Mar 1998 17:25:37 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA20676; Mon, 9 Mar 1998 17:24:31 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id RAA14913 for ; Mon, 9 Mar 1998 17:12:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA25745 for ; Mon, 9 Mar 1998 17:12:04 -0800 Received: from ceres.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA24615 for ; Mon, 9 Mar 1998 17:11:39 -0800 (PST) Received: (from mailer@localhost) by ceres.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) id KAA14154; Tue, 10 Mar 1998 10:25:29 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by ceres.backyard.wide.toshiba.co.jp via smap (V1.3) id sma014152; Tue Mar 10 10:25:13 1998 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) with ESMTP id KAA00270; Tue, 10 Mar 1998 10:12:17 +0900 (JST) To: ipv6imp@munnari.oz.au Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5305) received packets on raw IPv6 sockets using advanced API X-Mailer: Mew version 1.92 on Emacs 19.30 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980310100736R.jinmei@backyard.wide.toshiba.co.jp> Date: Tue, 10 Mar 1998 10:07:36 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 971024 Lines: 40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, especially those who are implementing advanced sockets API for IPv6(RFC 2292), I asked Mr. Richard Stevens, one of the authors of the RFC, about packets received on raw IPv6 sockets using the API. I got the following answer: + We can get the IPv6 header just followed by the datagram. + We can't get any extension headers as a part of received data on raw sockets. + We must get extension headers as ancillary data. But I have still some questions about raw IPv6 sockets, and Richard suggested me to ask them on this list. So I'd like to ask implementors the following questions. 1. At first, does your implementation follow the above rules? 2. If so, what values are stored in the following fields? a) The next header field of the IPv6 header. Is it the value of the upper layer protocol, or the value which identifies the 1st extension header of the original packet? b) The payload length field of the IPv6 header. Does it contain the length of extension headers or not? What if the original packet is a jumbo payload? What if the original packet is a jumbo payload, but the length of the upper layer datagrum is less than 65536? I admit these are not so serious problems, but it may affect portability of applications in some situation. So I'd like to know how other implementations do and what other implementors think about it. I'd appreciate any replies. Thanks in advance, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 9 19:06:28 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA15056 for ipng-dist; Mon, 9 Mar 1998 18:59:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA15048 for ; Mon, 9 Mar 1998 18:59:10 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA16176 for ; Mon, 9 Mar 1998 18:59:02 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA14059 for ; Mon, 9 Mar 1998 18:59:03 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id VAA22801; Mon, 9 Mar 1998 21:58:57 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA08100; Mon, 9 Mar 1998 21:58:56 -0500 Message-Id: <199803100258.AA08100@wasted.zk3.dec.com> To: Margaret Wasserman Cc: bound@zk3.dec.com, deering@cisco.com, robert@digi-data.com, ipng@sunroof.eng.sun.com Subject: (IPng 5306) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Mon, 09 Mar 1998 09:30:30 EST." <9803090930.aa13109@khitomer.epilogue.com> Date: Mon, 09 Mar 1998 21:58:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >Jim Bound writes: >>...and I strongly disagree with ever sending any packets that can >>fail on a network regardless of IPv6. > >Any packet _can_ fail. In general, I agree that we should send >packets that have the greatest chance of success (which means >using equal scopes for source and destination addresses where >possible). This is the "SHOULD" that I believe everyone agrees >to -- an equally scoped source address SHOULD be used when IP >is given the opportunity to choose the source address AND an >equally scoped address is available (even if it has been >deprecated). > >By your reasoning, I believe we should never send DHCP Discover >packets unless we have evidence that a DHCP server exists on our >network, and we all know you disagree with that :-). A DHCP Discover (note this is IPv4 and does not exist for IPv6) is a valid packet to discover a type of Host for the purpose of client/server computing. This may or may not happen whether the server is able to get or wants to respond to the Discover packet. Using a link-local address as a src and a global dst address is a completely different concept. The packet's src address will fail unless the dst Host is on the link. In addition Discover was mean't to behave this way and for this discussion scope was not well thought out as there is not even an ICMP message defined if in fact it was good behavior to use different scopes. I hope this clears up my reasoning for you, which is much better than you give me credit for in your above mail, which I did not appreciate either. I think I responded in spirit to the rest of your mail. We have now hit a block and seem to have two different views on this list now as to what is correct behavior... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 9 23:47:57 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id XAA15539 for ipng-dist; Mon, 9 Mar 1998 23:42:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id XAA15532 for ; Mon, 9 Mar 1998 23:42:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA12919 for ; Mon, 9 Mar 1998 23:42:30 -0800 Received: from pleco.cisco.com (pleco.cisco.com [171.69.30.22]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA29405 for ; Mon, 9 Mar 1998 23:42:30 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by pleco.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id XAA06684; Mon, 9 Mar 1998 23:41:56 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id XAA01977; Mon, 9 Mar 1998 23:41:55 -0800 (PST) Date: Mon, 9 Mar 1998 23:41:55 -0800 (PST) Message-Id: <199803100741.XAA01977@pedrom-ultra.cisco.com> From: Pedro Marques To: Steve Deering Cc: Christian Huitema , ipng@sunroof.eng.sun.com Subject: (IPng 5308) Re: Source Address Selection Issue and Scoping In-Reply-To: References: <9803060923.aa26966@khitomer.epilogue.com> <98Mar6.175155gmt-0400.19596@odin.digi-data.com> <980306172510.ZM29819@seawind.bellcore.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Steve" == Steve Deering writes: Steve> At 2:25 PM -0800 3/6/98, Christian Huitema wrote: >> The real point is: scoped address are evil. Steve> I tend to agree with the latter part of that sentence, Steve> though I don't think that's the entire real point, since Steve> *some* of the same issues under discussion still arise just Steve> between link-local and global. Steve> Site-local addresses made more sense in some of the earlier Steve> stages of SIP and SIPP development, based on ideas that no Steve> longer apply in IPv6. I would be quite happy to delete Steve> site-local unicast addresses entirely from IPv6 if we had Steve> consensus on that I'd really like to see them go away. First of all because the idea of scoping unicast addresses by their prefixes is, imho, incorrect. When you think about it there isn't really such thing as a global-scoped address. Unicast addresses are and should be scoped by how far the reachability information for them is spread. There is no way to assure that this scope will indeed be global (whatever global might mean). And when one wishes to limit it, there are mechanisms in place to control the scope to which you distribute reachability information for a given prefix. On the case of a misconfiguration, i believe it will be much easier to spot the case of a unique prefix leaking out of bounds than of a non unique prefix. Also, like you mentioned you can always use non-unique addresses like net 10. Adding special semantics to the prefix of addresses does, imho, add only complexity. Steve> (though the notion of site boundaries Steve> would still appear in the scope field of multicast address) Steve> -- it would simplify the implementations and the specs, and Steve> eliminate much of the confusion and design choices of the Steve> sort we have been discussing. Yes. Steve> (Note: if we eliminated site-local addresses, we could Steve> always add them back in in the future if absolutely Steve> necessary, using the net 10 approach, i.e., simply Steve> designating one global prefix for private use.) Which is, again imho, a better aproach than having the artificial differentiation by prefix. That way you don't have to invent a new way to do something that is already acomplished well by mechanisms that everybody understands. And while we are in the topic of scopes, may i suggest that we get rid of the usage of link local addresses in routing protocols. Specifically in RIP and ND Redirect. It causes a whole bunch of problems with redistribution between routing protocols that are based on directly connected nexthops and protocols that use non-local nexthops. It would be nice to see the following paragraph from 1970 disapear: "A router MUST be able to determine the link-local address for each of its neighboring routers in order to ensure that the target address in a Redirect message identifies the neighbor router by its link-local address. For static routing this requirement implies that the next- hop router's address should be specified using the link-local address of the router. For dynamic routing this requirement implies that all IPv6 routing protocols must somehow exchange the link-local addresses of neighboring routers." I never heard a good justification for the above requirement other than the fact that ND gives a special meaning to link local target addresses which i believe not to be necessary. Note that if the issue is that is desirable to notify hosts that the new nexthop is a router this can be made by the usage of a flag and not overloading the sematics of the target address field. As far as the issue of renumbering, redirects are cached information and should be aged (routing itself changes, hopefully much more frequently than renumbering occurs). In the case of redirect, i believe we should do a second modification, which is to add the prefix length of the route that caused the router to issue the redirect message. This will allow servers with a large number of correspondents (and in what can be probably considered a broken network design) to be able to agregate redirect state. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 05:25:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id FAA15946 for ipng-dist; Tue, 10 Mar 1998 05:21:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id FAA15939 for ; Tue, 10 Mar 1998 05:21:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA07504 for ; Tue, 10 Mar 1998 05:21:29 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA29787 for ; Tue, 10 Mar 1998 05:21:28 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: bound@zk3.dec.com, deering@cisco.com, robert@digi-data.com, ipng@sunroof.eng.sun.com In-reply-to: <199803100258.AA08100@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5309) Re: Source Address Selection Issue and Scoping Date: Tue, 10 Mar 98 08:21:05 -0500 Message-ID: <9803100821.aa01787@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I hope this clears up my reasoning for you, which is much better than >you give me credit for in your above mail, which I did not appreciate >either. I'm sorry, Jim. I meant my DHCP comment completely as a joke. I do understand your reasoning on the subject of sending packets with different scopes. We just have a difference of opinion regarding whether it is IP's job to do what the upper-layer says or to enforce this type of restriction. Again, I am sorry for any offense that I inadvertently gave. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 07:45:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id HAA16102 for ipng-dist; Tue, 10 Mar 1998 07:39:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id HAA16095 for ; Tue, 10 Mar 1998 07:39:09 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA05776 for ; Tue, 10 Mar 1998 07:39:08 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA08116 for ; Tue, 10 Mar 1998 07:38:50 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id KAA06444; Tue, 10 Mar 1998 10:38:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03563; Tue, 10 Mar 1998 10:38:30 -0500 Message-Id: <199803101538.AA03563@wasted.zk3.dec.com> To: Margaret Wasserman Cc: bound@zk3.dec.com, deering@cisco.com, robert@digi-data.com, ipng@sunroof.eng.sun.com Subject: (IPng 5310) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Tue, 10 Mar 1998 08:21:05 EST." <9803100821.aa01787@khitomer.epilogue.com> Date: Tue, 10 Mar 1998 10:38:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK.. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 08:24:57 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id IAA16184 for ipng-dist; Tue, 10 Mar 1998 08:17:03 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id IAA16176 for ; Tue, 10 Mar 1998 08:16:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA14835 for ; Tue, 10 Mar 1998 08:16:27 -0800 Received: from att.com (kcgw1.att.com [192.128.133.151]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA27255 for ; Tue, 10 Mar 1998 08:15:38 -0800 (PST) Received: by kcgw1.att.com; Tue Mar 10 10:15 CST 1998 Received: from frgmsx1.de.att.com (frgmsx1.de.att.com [135.76.188.33]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id KAA24851 for ; Tue, 10 Mar 1998 10:14:43 -0600 (CST) Received: by FRGMSX1 with Internet Mail Service (5.0.1458.49) id ; Tue, 10 Mar 1998 17:15:19 +0100 Message-ID: From: "Buclin, Bertrand" To: bound@zk3.dec.com, Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5311) Re: Source Address Selection Issue and Scoping Date: Tue, 10 Mar 1998 17:15:09 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, After having read through the thread (to date...), I would tend to support Steve's and Margaret's point of views: there might be legitimate cases when sending packets with different scopes for src and dst address is desirable. However, these cases should really be exceptional. I think a few rules are needed to avoid things getting really messy: - A first rule might be that by default a host SHOULD use addresses in the same scope for both src and dst (as you suggest and apparently is accepted by many). - Only when a specific configuration/management action is taken, the above principle MAY be overruled. - As you requested, there MUST be an ICMP message returned when the packet cannot be delivered. - But there MUST be a management/configuration mechanism allowing the user to change things so that communication can be established. For example, if the user for any reason (like because DNS or the application configuration says to do so) sends a packet with local-scope src and global-scope dst, and an ICMP error is returned, the user must be able to change the host behavior (reconfigure the application, or tell the DNS resolver to change the order in which addresses are returned, or discard the invalid scope addresses). There is nothing more frustrating for a user (actually more frequently a network manager) to get stuck against something which won't work and not have any control available to force things through. My 2 cents... CHeers, Bertrand PS: From an architectural point of view, I support you, Jim: if there are scoped addresses in IPv6, then the scope should be stricly adhered to. Pragmatically, all rules beg for exception, and I believe it's better to define the exception mechanims now than later. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 09:44:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id JAA16467 for ipng-dist; Tue, 10 Mar 1998 09:35:10 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id JAA16456 for ; Tue, 10 Mar 1998 09:34:58 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id JAA10648; Tue, 10 Mar 1998 09:34:54 -0800 (PST) Date: Tue, 10 Mar 1998 09:33:16 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5312) ND use of link-locals [WAS: Re: Source Address Selection Issue and Scoping] To: Pedro Marques Cc: Steve Deering , Christian Huitema , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803100741.XAA01977@pedrom-ultra.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let's make this a different subject. > And while we are in the topic of scopes, may i suggest that we get rid > of the usage of link local addresses in routing protocols. Specifically > in RIP and ND Redirect. It causes a whole bunch of problems with > redistribution between routing protocols that are based on directly > connected nexthops and protocols that use non-local nexthops. > > It would be nice to see the following paragraph from 1970 disapear: > > "A router MUST be able to determine the link-local address for each of > its neighboring routers in order to ensure that the target address in > a Redirect message identifies the neighbor router by its link-local > address. For static routing this requirement implies that the next- > hop router's address should be specified using the link-local address > of the router. For dynamic routing this requirement implies that all > IPv6 routing protocols must somehow exchange the link-local addresses > of neighboring routers." > > I never heard a good justification for the above requirement other than > the fact that ND gives a special meaning to link local target addresses > which i believe not to be necessary. Perhaps we (the authors of RFC 1970) have failed to communicate this issue clearly - all I find is this in section 8.1 (and similar text in section 4.5) - IP Source Address is a link-local address. Routers must use their link-local address as the source for Router Advertisement and Redirect messages so that hosts can uniquely identify routers. Anyhow, the issue is that we want hosts to be able to disregard stale redirects by ignoring redirects which are not sent by the current first hop router (just like in IPv4). The problem is that when the routers potentially have more than address it is hard for a host to tell if the router sending a redirect is indeed the current first hop router unless each router is always referred to by a single address. Using the router's link-local address for this has the added advantage that redirects work across renumbering events. Here are some examples: Two routers on the link: R1 and R2 R1 has 3 addresses: R1(LL) (link-local), R1(A), and R1(B) (both global). R2 has the corresponding addresses R2(LL), R2(A), and R2(B) The host is H. H starts of using R1(LL) as the next-hop for a particular destination. (It gets R1(LL) from the source address of a router advertisement from R1.) If R2 is the better first hop then R1 will send a redirect to H telling it to use R2. Which address should it use for R2? The address is picks for R2 will become the new next-hop used by H for the destination. Should R1 become the best next-hop for the destination then R2 will need to send a redirect to H (when packets arrive from H) telling it to use R1. But for the "ignore stale/bogus redirects" check to work the source address of the redirect packet MUST be the same as the target address used by R1 to specify R2. If R1 told H to use R2(A) then the redirect from R2 must use R2(A) as a source address. But how can R2 know which address R1 used as the redirect target? And H might have gotten the next-hop from the Router Advertisement instead of from the Redirect. Using the link-local address of the routers in router advertisements and as redirect targets is a simple solution. Also, should the site renumber (so that R2 now has the addresses R2(LL), R2(C), R2(D)) you don't have to do anything special since the link-local address is the same. We contemplated other solutions when ND was designed back in 1995. One working one (but more complex) would be to require that all hosts track all addresses of the routers. Thus the router advertisements would list all IP addresses the router uses on that link. Such a solution would add more complexity in the hosts for no real benefit. > In the case of redirect, i believe we should do a second modification, > which is to add the prefix length of the route that caused the router > to issue the redirect message. This will allow servers with a large number > of correspondents (and in what can be probably considered a broken network > design) to be able to agregate redirect state. This was discussed a few(!) years back. I don't recall exactly what tipped the scale to not include a prefix length. I think that part of it was that simple host implementations would just ignore the prefix part and treat it as a redirect for a single host. Also, there was no data to indicate that the "redirect a prefix" would reduce the number of redirect packets in practise. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 09:44:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id JAA16510 for ipng-dist; Tue, 10 Mar 1998 09:40:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id JAA16503 for ; Tue, 10 Mar 1998 09:40:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA06238 for ; Tue, 10 Mar 1998 09:40:21 -0800 Received: from digi-data.com (odin.digi-data.com [196.32.33.17]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA10286 for ; Tue, 10 Mar 1998 09:39:42 -0800 (PST) Received: by odin.digi-data.com id <19601>; Tue, 10 Mar 1998 13:37:08 -0400 Date: Tue, 10 Mar 1998 13:38:44 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: IPng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 5313) Re: Source Address Selection Issue and Scoping References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <98Mar10.133708gmt-0400.19601@odin.digi-data.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jim, One item I keep tripping over in this discussion, though, is the issue of the ICMP messages. Specifically, my problem is who will receive the ICMP message. From what I see, I do not think the ICMP message will go to the correct place, that is, the node that is not "properly configured", or the node that is trying to send a packet from a local-scope source address. I have two examples by way of illustration. Consider for the first example Node A attempting to use its link-local address to send to Node B's global-scope address and B is with is within the site but not a neighbour. A sends to B: A.link-local -->{Site's Network Infrastructure} -->B.global B receives packet and attempts to reply to A: A.link-local <--{Site's Network Infrastructure} <--B.global The site's network infrastructure cannot deliver B's packet because there is no route to A so it sends back an ICMP message: {Site's Network Infrastructure} ->[ICMP]-->B.global It seems to me that besides the apparent inability of B to reply to A, B is both correctly configured and received an ICMP message that would have been a whole lot more useful to A; but it is impossible for A to receive that message. Second example. Consider, now, Node A wants to send a packet to B who is not within the site using A's site-local address as the source and B's global address. A sends to B: A.site-local -->{Site and Internet Infrastructure} -->B.global B received the packet and now attempts to reply to A by simply interchanging addresses in the arriving packet (PING?). However, C is another node in B's site which happens to have an identical site-local address: A.site-local {Site and Internet Infrastructure} <--B.global | V C.site-local=A.site-local This time, the packet is delivered to a node. B dows not receive any ICMP messages and A does not receive any replies from B. Additionally, C on receiving an unsolicited packet that it is not required to process, drops all packets that B attempts to send to A. Now, can somebody tell me if I have missed something? Am I making an argument here that is not worth making? How can A usefully determine exactly what needs to be done to correct its inability to communicate (conventions about the usage of similar scopes in an exchange notwithstanding)? Thanks, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 10:07:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id JAA16563 for ipng-dist; Tue, 10 Mar 1998 09:58:42 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id JAA16556 for ; Tue, 10 Mar 1998 09:58:30 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id JAA14439; Tue, 10 Mar 1998 09:58:25 -0800 (PST) Date: Tue, 10 Mar 1998 09:56:47 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5315) Re: Source Address Selection Issue and Scoping To: Steve Deering Cc: Christian Huitema , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone in > the IPv6 community want to speak up in favor of site-local addresses? I think they provide something valuable that increases the probability of the global internet being able to scale. I'd agree with Christian in that in an ideal world all we would need would be the secure protocol for renumbering long-running TCP connections (and UDP "sessions"). This plus being able to renumber the DNS "glue" and the protocols we have for router and host renumbers would be sufficient. In this ideal world all nodes have certificates (so that IPsec just works), there is no (latent) software bugs, and there are no lawyers! In particular there is no software which stores IP addresses for a long time (in memory or in configuration files) since such software can not take advantage of the TCP/UDP "connection" renumber protocol Christian mentioned. And, should there be a *perception" that renumbering is risky there can be no lawyers that will sue to let an organization/company keep its IPv6 addresses when the org/company switches to a different ISP. So in the real world I think we need to hedge our bets and in addition to both working on Making renumbering easy (protocols like addrconf, router-renum etc) as well as Exchange based address/route aggregation (that removes the need to renumber when switching ISPs) I'd argue that we should also use site-local addresses as a means to reduce the risk to site-internal communication when the site's global addresses are renumbered (even in the face of applications which incorrectly store IP addresses). I'd agree that this is redundant work but I still think it is very important to avoid the development of the *perception* that renumbering is dangerous due there being too much "broken" software out there. It is redundant along the same lines that both working on simplifying renumbering easy and working on removing the need for renumbering is largely redundant. Thus in order to be able to move the Internet from today's reality to where we would like it to be I think we need (at least) all of: Easy renumbering (addrconf, TCP/UDP renumbering) Reducing the need for renumbering (exchange based aggregation) Reducing the risk of renumbering (using site-local addresses for site local communication). My 2 cents, Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 10:08:02 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id JAA16554 for ipng-dist; Tue, 10 Mar 1998 09:58:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id JAA16547 for ; Tue, 10 Mar 1998 09:57:56 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA11916 for ; Tue, 10 Mar 1998 09:57:53 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id JAA17945 for ; Tue, 10 Mar 1998 09:57:44 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA24771; Wed, 11 Mar 1998 04:57:38 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: (IPng 5314) Site Local Addresses Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Mar 1998 04:57:36 +1100 Message-Id: <13022.889552656@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I said in my earlier message (number 5293 I believe), I would kind of prefer that site local addresses not exist. However, after thinking about it, I don't think we're at the stage now (yet) where we can reasonably delete them. That is, right now, site local addresses are the only thing we have that will reasonably permit IPv6 sites to be renumbered in any rational way. Until we have better technology that allows connections to survive renumbering (which we desperately need), renumbering will be almost as impractical for IPv6 as it is for IPv4, if it means that no local connectivity can be retained through the renumbering. Do recall that local "connections" (like NFS mounts) can often exist for many months, and need to be able to continue to exist for periods like that, or longer. Since one of the major features of IPv6 is supposed to be its ease of renumbering sites, in order to make the global routing architecture (such as it is) continue to scale in a reasonable way, I don't think we can do anything right now to decrease the ease of renumbering. I think that means that we need to retain site locals, work out how to use the things, somehow (even if only in a kludgey like way), but make it clear that eventually, once better renumbering support exists for connections of all kinds, we expect site locals to gradually dissapear. If we don't do this, then I expect the effect will be that we either lose renumbering, or if we continue to require it, sites will simply allocate themselves an IPv6 address prefix to be used as their site local (ie: unadvertised, but immune to renumbering requirements) but without any of the router or host support in order to make the things work even semi-cleanly. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 10:12:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id KAA16602 for ipng-dist; Tue, 10 Mar 1998 10:04:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id KAA16595 for ; Tue, 10 Mar 1998 10:04:33 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA14059 for ; Tue, 10 Mar 1998 10:04:30 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA22770 for ; Tue, 10 Mar 1998 10:03:39 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id NAA10432; Tue, 10 Mar 1998 13:03:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA14306; Tue, 10 Mar 1998 13:03:34 -0500 Message-Id: <199803101803.AA14306@wasted.zk3.dec.com> To: robert@digi-data.com Cc: IPng@sunroof.eng.sun.com Subject: (IPng 5316) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Tue, 10 Mar 1998 13:38:44 -0400." <98Mar10.133708gmt-0400.19602@odin.digi-data.com> Date: Tue, 10 Mar 1998 13:03:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, >One item I keep tripping over in this discussion, though, is the issue >of the ICMP messages. Specifically, my problem is who will receive the >ICMP message. From what I see, I do not think the ICMP message will go >to the correct place, that is, the node that is not "properly >configured", or the node that is trying to send a packet from a >local-scope source address. I have two examples by way of illustration. >Consider for the first example Node A attempting to use its link-local >address to send to Node B's global-scope address and B is with is within >the site but not a neighbour. >A sends to B: > > A.link-local -->{Site's Network Infrastructure} -->B.global > >B receives packet and attempts to reply to A: An IPv6 router will not forward an IPv6 packet with a link-local address src so this can't happen. But an ICMP msg should be sent to the A.Host. A.link-local <--{Site's Network Infrastructure} <--B.global >Second example. >Consider, now, Node A wants to send a packet to B who is not within the >site using A's site-local address as the source and B's global address. Same answer but for site. An IPv6 router will not forward a site-local src address out of the site. If a router did do these things my argumennt for equal scopes would be even stronger because there is no way to get the ICMP messages back. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 10:13:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id KAA16628 for ipng-dist; Tue, 10 Mar 1998 10:05:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id KAA16621 for ; Tue, 10 Mar 1998 10:05:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA14368 for ; Tue, 10 Mar 1998 10:05:22 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA19848 for ; Tue, 10 Mar 1998 10:05:19 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA12823; Wed, 11 Mar 1998 05:04:50 +1100 (from kre@munnari.OZ.AU) To: robert@digi-data.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5317) Re: Source Address Selection Issue and Scoping In-Reply-To: Robert Honore's message of "Tue, 10 Mar 1998 13:38:44 -0400." References: <98Mar10.133708gmt-0400.19601@odin.digi-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Mar 1998 05:04:50 +1100 Message-Id: <13085.889553090@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 10 Mar 1998 13:38:44 -0400 From: Robert Honore Message-ID: <98Mar10.133708gmt-0400.19601@odin.digi-data.com> | A sends to B: | | A.link-local -->{Site's Network Infrastructure} -->B.global This is where the ICMP to be sent, as soon as that packet gets into the network infrastructure - the router detects that the source address is link local, the packet is passing off the link (or the source address is site local, and the packet is passing out of the site). That's the new ICMP that is being discussed, not this ... | B receives packet and attempts to reply to A: | | A.link-local <--{Site's Network Infrastructure} <--B.global | | The site's network infrastructure cannot deliver B's packet because | there is no route to A so it sends back an ICMP message: | | {Site's Network Infrastructure} ->[ICMP]-->B.global which would just be an unreachable ICMP of some kind (though in practice, in that example, B would see that it was sending to a link local, and the packet would never get to the network infrastructure). Link local addresses are on link by definition, hence one uses neighbour discovery to find the link address, and sends directly to them. | Second example. Exactly the same. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 10:20:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id KAA16663 for ipng-dist; Tue, 10 Mar 1998 10:09:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id KAA16652 for ; Tue, 10 Mar 1998 10:08:47 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA15464 for ; Tue, 10 Mar 1998 10:08:44 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA25161 for ; Tue, 10 Mar 1998 10:08:25 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id NAA11884; Tue, 10 Mar 1998 13:08:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA14669; Tue, 10 Mar 1998 13:08:16 -0500 Message-Id: <199803101808.AA14669@wasted.zk3.dec.com> To: "Buclin, Bertrand" Cc: bound@zk3.dec.com, Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: (IPng 5318) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Tue, 10 Mar 1998 17:15:09 +0100." Date: Tue, 10 Mar 1998 13:08:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bertrand, I have no problem the way you outliineed it.. If its the default. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 10:21:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id KAA16693 for ipng-dist; Tue, 10 Mar 1998 10:17:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id KAA16686 for ; Tue, 10 Mar 1998 10:17:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA18207 for ; Tue, 10 Mar 1998 10:17:00 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA28003 for ; Tue, 10 Mar 1998 10:14:50 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28771; Tue, 10 Mar 1998 10:13:27 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <98Mar10.133708gmt-0400.19601@odin.digi-data.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Mar 1998 10:14:39 -0800 To: robert@digi-data.com From: Steve Deering Subject: (IPng 5319) Re: Source Address Selection Issue and Scoping Cc: IPng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, > A.link-local -->{Site's Network Infrastructure} -->B.global > > B receives packet... No, B does not receive the packet. When the router on A's link determines that the next hop toward B is via a different link, it drops the packet (since a packet with a link-local source or destination address is not allowed to be forwarded beyond its original link) and sends an ICMP error message back to A's link-local address. Your second example suffers from the same misunderstanding. A packet whose source address is not of sufficient scope to reach the destination address is stopped (and reported to the source via IACMP) at the point where it would otherwise leave the scope of the source address. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 10:23:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id KAA16703 for ipng-dist; Tue, 10 Mar 1998 10:18:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id KAA16696 for ; Tue, 10 Mar 1998 10:18:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA18735 for ; Tue, 10 Mar 1998 10:18:29 -0800 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA29511 for ; Tue, 10 Mar 1998 10:16:55 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id MAA05613; Tue, 10 Mar 1998 12:15:55 -0600 (CST) Date: Tue, 10 Mar 1998 12:15:55 -0600 (CST) From: David Borman Message-Id: <199803101815.MAA05613@frantic.bsdi.com> To: bound@zk3.dec.com, IPng@sunroof.eng.sun.com, robert@digi-data.com Subject: (IPng 5320) Re: Source Address Selection Issue and Scoping Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, > Date: Tue, 10 Mar 1998 13:38:44 -0400 > From: Robert Honore > Subject: (IPng 5313) Re: Source Address Selection Issue and Scoping > ... > Consider for the first example Node A attempting to use its link-local > address to send to Node B's global-scope address and B is with is within > the site but not a neighbour. > > A sends to B: > > A.link-local -->{Site's Network Infrastructure} -->B.global > > B receives packet and attempts to reply to A: > > A.link-local <--{Site's Network Infrastructure} <--B.global > > The site's network infrastructure cannot deliver B's packet because > there is no route to A so it sends back an ICMP message: > > {Site's Network Infrastructure} ->[ICMP]-->B.global This is wrong, B should never have gotten the message. The router on A's network should never forward packets with a link-local source address off the link, so the router should generate the ICMP error message back to A. (The same is true for your second example, just substitue "site" for "link".) -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 11:17:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id LAA16972 for ipng-dist; Tue, 10 Mar 1998 11:09:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id LAA16965 for ; Tue, 10 Mar 1998 11:09:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA08849 for ; Tue, 10 Mar 1998 11:08:58 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA01924 for ; Tue, 10 Mar 1998 11:08:51 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id OAA24164; Tue, 10 Mar 1998 14:08:30 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA25992; Tue, 10 Mar 1998 14:08:32 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id OAA18272; Tue, 10 Mar 1998 14:08:40 -0500 (EST) Message-Id: <199803101908.OAA18272@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: (IPng 5321) Re: Source Address Selection Issue and Scoping In-reply-to: Your message of "Fri, 06 Mar 1998 15:30:30 PST." Date: Tue, 10 Mar 1998 14:08:40 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone in the IPv6 community want to speak up in favor of > site-local addesses? While it doesn't surprise me that no one seems to like them, I view site-local addresses as a necessary evil. They are a concession to the reality that net 10 addresses are a fact of life in IPv4. Does anyone really think we can tell folks that there is absolutely no need for net 10 addresses in IPv6? > (Note: if we eliminated site-local addresses, we could always add > them back in in the future if absolutely necessary, using the net 10 > approach, i.e., simply designating one global prefix for private > use.) My take is that the all the ugly cases that we'd rather just ignore and not deal with that come up with site-local addresses are exactly the same for net 10 addresses. Just designating a global prefix later if need be means we are punting on smoothing out the rough edges. The time to address these issues is now, before there is an installed base that can't easily be upgraded. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 12:05:36 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id LAA17243 for ipng-dist; Tue, 10 Mar 1998 11:58:18 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id LAA17236 for ; Tue, 10 Mar 1998 11:58:03 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id LAA07045; Tue, 10 Mar 1998 11:57:57 -0800 (PST) Date: Tue, 10 Mar 1998 11:56:18 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5322) Re: Advanced Sockets API Issue To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803072304.PAA02665@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I would suggest an alternate definition of IPV6_PKTOPTIONS which > defines its getsockopt behavior as returning all the "sticky" options con- > figured on the socket. Of course making this change will require that we > come up with an alternate mechanism for TCP sockets to receive ancillary > data. The easiest way and I believe the superior way to do this is to > allow TCP socket to use recvmsg to receive ancillary data. We would still > forbid TCP sockets from using sendmsg to send ancillary data. I don't have a problem with a getsockopt of IPV6_PKTOPTIONS returning what was set with the same setsockopt. However, you don't specify much detail in what it would mean to have recvmsg on TCP return ancillary data. The text in the advanced API doesn't seem to me to clearly specify how ancillary data would be used with TCP. Some key questions: - Do we expect the ancillary data (i.e. the extension headers etc) to change during a TCP connection? - If so, how important is it that an interested application be notified of such a change? (E.g. if every other TCP segment uses a different destination options header does the application want/need to know exactly which bytes of the TCP stream were carried with which destination options?) *IF* we want the TCP application to be able to track the exact content of the extension headers I think we have two choices in the API: - TCP sends up the ancillary data to the socket layer with every TCP segment. - TCP sends up the ancillary data only for the first piece of data and when the extension headers are different. At first sight it might seem that the only difference between the two are whether the "compare the extension headers with the previos ones" is done in TCP or in the application. However, from looking at both the 4.4BSD and the Solaris source it seems like associating msg_control with each TCP segment is likely to force each TCP segment to be a separate record (sbappendrecord() in BSD) in order for the control information to correctly be associated with the data. As far as I can tell this would mean that a recv*() or read() would only be able to return one TCP segment at a time since it can't "merge" all the control headers. We can all these issues if we make TCP only send up (i.e. sbappend*() in BSD implementations) control information for the first packet on the connection and when the extension headers change. Of course, if we don't think TCP applications need to be able to track the changes to the extension headers then we don't need to use recvmsg ancillary data with TCP at all. It would be sufficient to have a getsockopt (IPV6_RECVPKTOPTIONS?) that would return some approximate extension headers like those received on the last TCP segment. (Note that TCP would still only record the extension headers when it has been enabled with the corresponding setsockopt - IPV6_PKTINFO, IPV6_HOPLIMIT, IPV6_HOPOPTS, IPV6_DSTOPTS, IPV6_RTHDR). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 13:22:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id NAA17730 for ipng-dist; Tue, 10 Mar 1998 13:14:46 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id NAA17723 for ; Tue, 10 Mar 1998 13:14:36 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id NAA18149 for ; Tue, 10 Mar 1998 13:14:34 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA22281; Tue, 10 Mar 1998 13:13:28 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id MAA17546 for ; Tue, 10 Mar 1998 12:57:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA11820 for ; Tue, 10 Mar 1998 12:57:54 -0800 Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA21428 for ; Tue, 10 Mar 1998 12:56:07 -0800 (PST) Received: from zrchh190.us.nortel.com by smtprich.nortel.com; Tue, 10 Mar 1998 14:55:17 -0600 Received: from zrchb200.bnr.ca (actually zrchb200.us.nortel.com) by zrchh190.us.nortel.com; Tue, 10 Mar 1998 14:42:38 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.0.1460.8) id ; Tue, 10 Mar 1998 15:46:13 -0600 Message-ID: From: "Darren Vann" To: Thomas Narten , Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5324) Re: Source Address Selection Issue and Scoping Date: Tue, 10 Mar 1998 14:42:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I certainly agree that site-local addresses are necessary and the issue should be confronted prior to final release of v6 . Regardless of how many host or network addresses will be available in the v6 scheme, site-local addressing will be used just as it is today. There are a tremendous number of internal networks that are now using NAT (Network Address Translation) to connect site-locally addressed networks to registered or Internet networks. The move to v6 will probably not cause that implementation to change in any way. -Darren Darren E. Vann Senior Network Consultant, Rapport Business Operations Public Data Networks Northern Telecom dvann@nortel.com > -----Original Message----- > From: Thomas Narten [SMTP:narten@raleigh.ibm.com] > Sent: Tuesday, March 10, 1998 1:09 PM > To: Steve Deering > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 5321) Re: Source Address Selection Issue and Scoping > > > Does anyone in the IPv6 community want to speak up in favor of > > site-local addesses? > > While it doesn't surprise me that no one seems to like them, I view > site-local addresses as a necessary evil. They are a concession to the > reality that net 10 addresses are a fact of life in IPv4. > > Does anyone really think we can tell folks that there is absolutely no > need for net 10 addresses in IPv6? > > > (Note: if we eliminated site-local addresses, we could always add > > them back in in the future if absolutely necessary, using the net 10 > > approach, i.e., simply designating one global prefix for private > > use.) > > My take is that the all the ugly cases that we'd rather just ignore > and not deal with that come up with site-local addresses are exactly > the same for net 10 addresses. Just designating a global prefix later > if need be means we are punting on smoothing out the rough edges. The > time to address these issues is now, before there is an installed base > that can't easily be upgraded. > > Thomas > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 14:02:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id NAA17892 for ipng-dist; Tue, 10 Mar 1998 13:51:03 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id NAA17885 for ; Tue, 10 Mar 1998 13:50:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA29997 for ; Tue, 10 Mar 1998 13:50:49 -0800 Received: from pony-1.mail.digex.net (pony-1.mail.digex.net [204.91.241.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA17892 for ; Tue, 10 Mar 1998 13:49:54 -0800 (PST) Received: from krakow.brighttiger.com (brighttiger.com [207.86.119.34]) by pony-1.mail.digex.net (8.8.8/8.8.8) with SMTP id QAA12352 for ; Tue, 10 Mar 1998 16:49:52 -0500 (EST) Received: from mitera (192.168.0.160) by krakow.brighttiger.com (EMWAC SMTPRS 0.81) with SMTP id ; Tue, 10 Mar 1998 16:49:08 -0500 Message-ID: Reply-To: From: "Peter A. Schulter" To: Subject: (IPng 5325) Latest IPv6 over ATM draft available Date: Tue, 10 Mar 1998 04:48:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The latest IPv6 over ATM draft is now available. Regards, --- pete ----------------------------------------------------- Peter A. Schulter schulter@brighttiger.com Bright Tiger Technologies www.brighttiger.com 125 Nagog Park (Voice) 978-263-5455 x109 Acton, MA 01720 (FAX) 978-263-5547 > -----Original Message----- > From: owner-ion@sunroof.Eng.Sun.COM > [mailto:owner-ion@sunroof.Eng.Sun.COM] On Behalf Of > Internet-Drafts@ns.ietf.org > Sent: Friday, March 06, 1998 2:40 PM > To: "IETF-Announce:;;;@cnri.reston.va.us;"@Eng.Sun.COM > Cc: ion@sunroof.Eng.Sun.COM > Subject: (ION) I-D ACTION:draft-ietf-ion-ipv6-atm-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Internetworking Over NBMA Working > Group of the IETF. > > Title : IPv6 over ATM Networks > Author(s) : G. Armitage, M. Jork, P. Schulter, G. Harter > Filename : draft-ietf-ion-ipv6-atm-01.txt > Pages : 10 > Date : 05-Mar-98 > > This document is a companion to the ION working group's architecture > document 'IPv6 over Non Broadcast Multiple Access (NBMA) networks'. > It provides specific details on how to apply the IPv6 over NBMA > architecture to ATM networks. This architecture allows conventional > host-side operation of the IPv6 Neighbor Discovery protocol, while > also supporting the establishment of 'shortcut' ATM forwarding paths > (when using SVCs). Operation over administratively configured Point > to Point PVCs is also supported. > > 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-ietf-ion-ipv6-atm-01.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ion-ipv6-atm-01.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-ion-ipv6-atm-01.txt". > > NOTE: The mail server at ietf.org 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. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 14:35:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id OAA18018 for ipng-dist; Tue, 10 Mar 1998 14:24:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id OAA18011 for ; Tue, 10 Mar 1998 14:24:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14134 for ; Tue, 10 Mar 1998 14:24:25 -0800 Received: from pony-1.mail.digex.net (pony-1.mail.digex.net [204.91.241.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA04977 for ; Tue, 10 Mar 1998 14:21:31 -0800 (PST) Received: from krakow.brighttiger.com (brighttiger.com [207.86.119.34]) by pony-1.mail.digex.net (8.8.8/8.8.8) with SMTP id RAA24377 for ; Tue, 10 Mar 1998 17:21:29 -0500 (EST) Received: from mitera (192.168.0.160) by krakow.brighttiger.com (EMWAC SMTPRS 0.81) with SMTP id ; Tue, 10 Mar 1998 17:20:45 -0500 Message-ID: Reply-To: From: "Peter A. Schulter" To: Subject: (IPng 5326) Latest IPv6 over NBMA draft available Date: Tue, 10 Mar 1998 05:20:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The latest IPv6 over NBMA draft is now available. Regards, --- pete ----------------------------------------------------- Peter A. Schulter schulter@brighttiger.com Bright Tiger Technologies www.brighttiger.com 125 Nagog Park (Voice) 978-263-5455 x109 Acton, MA 01720 (FAX) 978-263-5547 > -----Original Message----- > From: owner-ion@sunroof.Eng.Sun.COM > [mailto:owner-ion@sunroof.Eng.Sun.COM] On Behalf Of > Internet-Drafts@ns.ietf.org > Sent: Friday, March 06, 1998 2:40 PM > To: "IETF-Announce:;;;@cnri.reston.va.us;"@Eng.Sun.COM > Cc: ion@sunroof.Eng.Sun.COM > Subject: (ION) I-D ACTION:draft-ietf-ion-ipv6-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Internetworking Over NBMA Working > Group of the IETF. > > Title : IPv6 over Non-Broadcast Multiple Access > (NBMA) networks > Author(s) : G. Armitage, M. Jork, P. Schulter, G. Harter > Filename : draft-ietf-ion-ipv6-01.txt > Pages : 46 > Date : 05-Mar-98 > > This document describes a general architecture for IPv6 over NBMA > networks. It forms the basis for subsidiary companion documents that > describe details for various specific NBMA technologies (such as ATM > or Frame Relay). The IPv6 over NBMA architecture allows conventional > host-side operation of the IPv6 Neighbor Discovery protocol, while > also supporting the establishment of 'shortcut' NBMA forwarding > paths when dynamically signaled NBMA links are available. Operations > over administratively configured Point to Point NBMA links are also > described. > > Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor > Discovery protocol operation within Logical Links, and inter-router > NHRP for the discovery of off-Link NBMA destinations. Both flow- > triggered and explicitly source-triggered shortcuts are supported. > > 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-ietf-ion-ipv6-01.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ion-ipv6-01.txt > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-ion-ipv6-01.txt". > > NOTE: The mail server at ietf.org 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. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 17:00:04 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id QAA18793 for ipng-dist; Tue, 10 Mar 1998 16:53:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id QAA18786 for ; Tue, 10 Mar 1998 16:53:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA25010 for ; Tue, 10 Mar 1998 16:53:25 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA25852 for ; Tue, 10 Mar 1998 16:52:25 -0800 (PST) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA08243; Tue, 10 Mar 98 16:49:05 PST Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id QAA01223; Tue, 10 Mar 1998 16:53:22 -0800 Date: Tue, 10 Mar 1998 16:53:22 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803110053.QAA01223@orna.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 5327) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't have a problem with a getsockopt of IPV6_PKTOPTIONS > returning what was set with the same setsockopt. > > However, you don't specify much detail in what it would mean to have > recvmsg on TCP return ancillary data. > I was hoping that the details would be kept very simple. My goal would be for the IPV6_PKTOPTIONS options (or Mukesh's proposed replpacement) to behave exactly the same for RAW, DGRAM and STREAM sockets. It is also desireable in my opinion for the reception of the IPV6_HOPLIMIT, IPV6_PKTINFO, IPV6_RTHDR, IPV6_DSTOPTS and IPV6_HOPOPTS ancillary data items to work the same for RAW, DGRAM and STREAM sockets. > The text in the advanced API doesn't seem to me to clearly specify > how ancillary data would be used with TCP. Some key questions: > - Do we expect the ancillary data (i.e. the extension headers etc) to > change during a TCP connection? Currently I would expect the answer to be no. I expect the answer will most likely remain no. That being the case if an application wanted to receive the options and routing headers used on the initial segments of a connection it could set IPV6_RTHDR, IPV6_DSTOPTS and IPV6_HOPOPTS for the first receive call of the connection and then turn them off. > - If so, how important is it that an interested application be notified of > such a change? (E.g. if every other TCP segment uses a different destination > options header does the application want/need to know exactly which bytes > of the TCP stream were carried with which destination options?) > As I noted to Mukesh, I don't believe that it is important for the application to be able to synchronize the data stream with the ancillary data stream. The application may still want to know about every incoming option header but I don't see any problem in specifying that there is no direct correlation between the data and the ancillary data other than it arrived on the same TCP connection. What I am in search here is a way to make as much of the functionality as possible common between RAW, DGRAM and STREAM sockets. > *IF* we want the TCP application to be able to track the exact content of > the extension headers I think we have two choices in the API: > - TCP sends up the ancillary data to the socket layer with every TCP segment. I would prefer this since I would like to keep our TCP out of the business of trying to figure out when the remote host changes some option buried inside a destination options header. If the user sets IPV6_DSTOPTS then it is up to them to receive the options and figure out what changed if any- thing. > - TCP sends up the ancillary data only for the first piece of data > and when the extension headers are different. > This seems like a lot of work. I would leave it to the application to figure out what changed. > At first sight it might seem that the only difference between the two > are whether the "compare the extension headers with the previos ones" > is done in TCP or in the application. However, from looking at > both the 4.4BSD and the Solaris source it seems like associating > msg_control with each TCP segment is likely to force each TCP > segment to be a separate record (sbappendrecord() in BSD) > in order for the control information to correctly be associated > with the data. As far as I can tell this would mean that > a recv*() or read() would only be able to return one TCP segment at > a time since it can't "merge" all the control headers. > Not having the BSD source in front of me at the moment so I can't say what implementation technique would be best. However, if we take the approach that the most recently received ancillary data will cause any existing ancillary data to be discarded then the segment at a time problem can avoided. The TCP data needs to be reliable the ancillary data does not. > We can all these issues if we make TCP only send up (i.e. sbappend*() in BSD > implementations) control information for the first packet on the connection and > when the extension headers change. > As I said above I think we would be doing ourselves a big favor if we keep TCP out of the business of attempting determine if the fifth hop in the source route just changed. Just pass the ancillary data to the user and let them figure out what to do with it. > Of course, if we don't think TCP applications need to be able to track > the changes to the extension headers then we don't need to use recvmsg > ancillary data with TCP at all. It would be sufficient to have a > getsockopt (IPV6_RECVPKTOPTIONS?) that would return some approximate > extension headers like those received on the last TCP segment. > (Note that TCP would still only record the extension headers when it > has been enabled with the corresponding setsockopt - IPV6_PKTINFO, > IPV6_HOPLIMIT, IPV6_HOPOPTS, IPV6_DSTOPTS, IPV6_RTHDR). > My preference is to have RAW, DGRAM and STREAM sockets behave as close to the same as possible with respect to ancillary data. Defining yet some other option which will require a bunch of special purpose code in TCP does not appeal to me. Here is my idea of the ideal solution. Throw out the IPV6_PKTOPTIONS option and replace it with an option called SO_CMSGHDR or something. The SO_CMSGHDR option is merely a more general version of IPV6_PKTOPTIONS which allows a vector of options to be set or gotten simultaneously. This is basically Mukesh's idea. Use recvmsg ancillary data for reception of IPV6_PKTINFO, IPV6_HOPLIMIT, IPV6_HOPTOPTS, IPV6_DSTOPTS and IPV6_RTHDR ancillary data for RAW, DGRAM and STREAM sockets. The passing of this information would be controlled by the enabling of the respective options with setsockopt. This translates to the least code for me, probably for you too and I think BSD implementation probably win in total code mass as well. I also think the application writer gets a nice orthogonal mechanism for dealing with IPV6 options. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 17:06:25 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id RAA18923 for ipng-dist; Tue, 10 Mar 1998 17:03:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id RAA18916 for ; Tue, 10 Mar 1998 17:02:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA27479 for ; Tue, 10 Mar 1998 17:02:55 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id RAA01329 for ; Tue, 10 Mar 1998 17:01:57 -0800 (PST) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA08387; Tue, 10 Mar 98 16:59:03 PST Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id RAA01264; Tue, 10 Mar 1998 17:03:19 -0800 Date: Tue, 10 Mar 1998 17:03:19 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803110103.RAA01264@orna.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5328) Re: received packets on raw IPv6 sockets using advanced API X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > + We can get the IPv6 header just followed by the datagram. I don't believe that this is correct. The whole point of having the flowinfo in the sockaddr_in6, the IPv6_HOPLIMIT ancillary data item, the IPV6_PKTINFO ancillary data item and the IPV6_HOPOPTS and IPV6_DESTOPTS ancillary data items was to avoid having to pass "raw" IPv6 base and extension headers out to the user. If we are going to pass headers out then we might as well dispense with the ancillary data. > + We can't get any extension headers as a part of received data on raw > sockets. > + We must get extension headers as ancillary data. > > But I have still some questions about raw IPv6 sockets, and Richard > suggested me to ask them on this list. So I'd like to ask implementors > the following questions. > > 1. At first, does your implementation follow the above rules? > No. In our implementation the IPv6 base and extension headers are stripped and only the upper-layer protocol data is returned in the buffer of the receive call. All other attributes of the IPv6 base and extension headers must be accessed via ancillary data. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 17:43:25 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id RAA19038 for ipng-dist; Tue, 10 Mar 1998 17:36:10 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id RAA19031 for ; Tue, 10 Mar 1998 17:35:17 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id RAA29122; Tue, 10 Mar 1998 17:34:54 -0800 (PST) Date: Tue, 10 Mar 1998 17:33:09 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5329) Re: Advanced Sockets API Issue To: Tim Hartrick Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803110053.QAA01223@orna.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What I am in search here is a way to make as much of the functionality as > possible common between RAW, DGRAM and STREAM sockets. I also like simplicity and commonality. However, I also realize that TCP reliable byte stream is a rather different thing than the datagrams in RAW and DGRAM sockets in that there is not a one for one correspondence between received packets and receive operations in the socket API. If we think that these extension headers might be interesting to TCP applications in the future why not make those TCP application have similar access to these headers as do the UDP and RAW applications? > I would prefer this since I would like to keep our TCP out of the business > of trying to figure out when the remote host changes some option buried > inside a destination options header. If the user sets IPV6_DSTOPTS then > it is up to them to receive the options and figure out what changed if any- > thing. I don't think a byte compare of everything between the IP and TCP header (or a byte compare of the extension headers the application is asking for) is very complex. > Not having the BSD source in front of me at the moment so I can't say > what implementation technique would be best. However, if we take the > approach that the most recently received ancillary data will cause > any existing ancillary data to be discarded then the segment at a time > problem can avoided. The TCP data needs to be reliable the ancillary > data does not. How do you know that future applications will not want a reliable delivery of the fact that the extension headers have changed mid-stream in a TCP connection? How do you know that the application will not want this notification to be synchronized with the data so that it can tell where in the byte stream the change occurred? I don't claim to know the answers to the above questions. But I think that if we want the API to support ancillary data for TCP that it would make sense to look at providing an API that doesn't unnecessarily or accidentally hide information from the applications since we don't know what the applications will look like. > Here is my idea of the ideal solution. > > Throw out the IPV6_PKTOPTIONS option and replace it with an option called > SO_CMSGHDR or something. The SO_CMSGHDR option is merely a more general > version of IPV6_PKTOPTIONS which allows a vector of options to be set or > gotten simultaneously. This is basically Mukesh's idea. Fine with me. And I assume a getsockopt of this will return what setsockopt has set as you originally argued. > Use recvmsg ancillary data for reception of IPV6_PKTINFO, IPV6_HOPLIMIT, > IPV6_HOPTOPTS, IPV6_DSTOPTS and IPV6_RTHDR ancillary data for RAW, DGRAM and > STREAM sockets. The passing of this information would be controlled by > the enabling of the respective options with setsockopt. OK. Except that when TCP receives 37 1 byte telnet segments which all have the same extension header content I'd like to be able to pass these to the application in a single read/recvmsg instead of it being broken up in 37 1 byte recvmsg calls all having the same ancillary data. I don't see how this can be done with the current socket framework (e.g. in 4.4BSD) without supressing the identical extension headers in tcp. All this supression adds in a bcmp() in TCP to determine if the extension headers are identical to the previously received segment. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 10 17:43:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id RAA19047 for ipng-dist; Tue, 10 Mar 1998 17:36:53 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id RAA19040 for ; Tue, 10 Mar 1998 17:36:43 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id RAA29455; Tue, 10 Mar 1998 17:36:39 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.8.8+Sun/8.8.8) id RAA12104; Tue, 10 Mar 1998 17:35:24 -0800 (PST) Date: Tue, 10 Mar 1998 17:35:24 -0800 (PST) From: Mukesh Kacker Message-Id: <199803110135.RAA12104@lucknow.eng.sun.com> To: Erik.Nordmark@Eng, thartric@mentat.com Subject: (IPng 5330) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com, mukesh@lucknow.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Here is my idea of the ideal solution. > .... > > Use recvmsg ancillary data for reception of IPV6_PKTINFO, IPV6_HOPLIMIT, > IPV6_HOPTOPTS, IPV6_DSTOPTS and IPV6_RTHDR ancillary data for RAW, DGRAM and > STREAM sockets. The passing of this information would be controlled by > the enabling of the respective options with setsockopt. > Since we are going into ideal solutions I would like to propose more related fixes. :-) With the proposal fix send side sticky options setsockopt() to be symmteric to what you get through getsockopt(), I would like the option names for send side sticky options and receive side attirbutes to be different in line with traditional BSD naming conventions. They also represent semantically different "information" as they are derived from send and receive side header/extension-header fields. Thus what you will send through a sendmsg control buffer, or through sticky opts IPV6_PKTOPTIONS/SO_CMSG would be options with names like IPV6_PKTINFO, IPV6_HOPLIMT, IPV6_HOPOPTS, IPV6_DSTOPTS, IPV6_RTHDR, IPV6_NEXTHOP etc. The options names you will use to enable the boolean enabling of optional received stuff and on receive side will have a IPv6_RECV* prefix (ala IP_RECVDSTADDR). So for receive side we would use, IPV6_RECVPKTINFO, IPV6_RECVHOPLIMIT, IPV6_RECVHOOPTS, IPV6_RECVDSTOPTS, IPV6_RECVRTHDR. Thus IP{V6}_RECV* prefix options would have a consistent semantics where when used through setsockopt()/getsockopt() they have boolean semantics of enabling/disabling optional receive side stuff and when contained in a control buffer retrieved through recvmsg() [ or whatever way one gets receive side control buffer ], they represent the content of the attribute/extension-header. -Mukesh Kacker -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 00:07:17 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id XAA19501 for ipng-dist; Tue, 10 Mar 1998 23:58:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id XAA19494 for ; Tue, 10 Mar 1998 23:58:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA01950; Tue, 10 Mar 1998 23:58:44 -0800 Received: from quisp.cisco.com (quisp.cisco.com [171.69.95.82]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA07952; Tue, 10 Mar 1998 23:58:44 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by quisp.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id XAA27532; Tue, 10 Mar 1998 23:58:50 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id XAA02630; Tue, 10 Mar 1998 23:58:40 -0800 (PST) Date: Tue, 10 Mar 1998 23:58:40 -0800 (PST) Message-Id: <199803110758.XAA02630@pedrom-ultra.cisco.com> From: Pedro Marques To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5331) ND use of link-locals [WAS: Re: Source Address Selection Issue and Scoping] In-Reply-To: References: <199803100741.XAA01977@pedrom-ultra.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Erik" == Erik Nordmark writes: Erik> Let's make this a different subject. >> It would be nice to see the following paragraph from 1970 >> disapear: >> >> "A router MUST be able to determine the link-local address for >> each of its neighboring routers in order to ensure that the >> target address in a Redirect message identifies the neighbor >> router by its link-local address. For static routing this >> requirement implies that the next- hop router's address should >> be specified using the link-local address of the router. For >> dynamic routing this requirement implies that all IPv6 routing >> protocols must somehow exchange the link-local addresses of >> neighboring routers." >> >> I never heard a good justification for the above requirement >> other than the fact that ND gives a special meaning to link >> local target addresses which i believe not to be necessary. [snip] Erik, First of all thanks for your explanation of the problem. Erik> We contemplated other solutions when ND was designed back in Erik> 1995. One working one (but more complex) would be to Erik> require that all hosts track all addresses of the routers. Erik> Thus the router advertisements would list all IP addresses Erik> the router uses on that link. Another alternative would be for the router to list the addresses he is serving on an interface in the redirect message. While these don't sound too elegant i believe we should look further into the problem. Erik> Such a solution would add more Erik> complexity in the hosts for no real benefit. When you consider redirects only, you are correct, there is no real benefit. But if you consider the requirements that you place on routing protocols i believe the issue is not so straight forward. The solution for the router identification problem used in Redirect messages causes, imho, the problem to spread to all other routing protocols. We can take for an axiom that some routing protocols need non-local addresses for identification and/or as nexthop addresses. The fact that routing protocols are also required to provide for link local addresses creates a lot of complexity and some rather ugly solutions (BGP for IPv6 to name one). >> In the case of redirect, i believe we should do a second >> modification, which is to add the prefix length of the route >> that caused the router to issue the redirect message. This will >> allow servers with a large number of correspondents (and in >> what can be probably considered a broken network design) to be >> able to agregate redirect state. Erik> This was discussed a few(!) years back. I don't recall Erik> exactly what tipped the scale to not include a prefix Erik> length. Erik> I think that part of it was that simple host Erik> implementations would just ignore the prefix part and treat Erik> it as a redirect for a single host. That shouldn't be a problem. I don't think the extra information would hurt and some hosts could potentially benefict. Erik> Also, there was no data Erik> to indicate that the "redirect a prefix" would reduce the Erik> number of redirect packets in practise. Suppose you have a web server on a link with two routers, one which is the best nexthop for default and one which is the best nexthop for the internal network. With the prefix information 2 redirect cache entries would probably be suficient while without it you will need, statistically, N/2 cache entries when N is the number of correspondents. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 04:41:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id EAA19871 for ipng-dist; Wed, 11 Mar 1998 04:32:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id EAA19864 for ; Wed, 11 Mar 1998 04:32:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA22159; Wed, 11 Mar 1998 04:32:25 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA17974; Wed, 11 Mar 1998 04:32:20 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA22806; Wed, 11 Mar 1998 07:32:02 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA27752; Wed, 11 Mar 1998 07:32:03 -0500 Received: from hygro.raleigh.ibm.com (lig32-224-57-168.us.lig-dial.ibm.com [32.224.57.168]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id HAA12118; Wed, 11 Mar 1998 07:32:06 -0500 (EST) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id GAA00707; Wed, 11 Mar 1998 06:31:53 -0500 Message-Id: <199803111131.GAA00707@hygro.raleigh.ibm.com> To: Pedro Marques cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: (IPng 5332) Re: ND use of link-locals [WAS: Re: Source Address Selection Issue and Scoping] In-reply-to: Your message of "Tue, 10 Mar 1998 23:58:40 PST." <199803110758.XAA02630@pedrom-ultra.cisco.com> Date: Wed, 11 Mar 1998 06:31:53 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, As Erik says, life is a lot simpler if a router is known to hosts by a single address. Erik described the case of redirects. Another example is the default router list. Do you want the same router to appear on the default list multiple times (once for each address?). If this were the case, switching to a backup router would take longer since you'd likely end up trying the same router (unknowingly) through one of its other addresses. Once you accept that a router should be known by a single address, which address should that be? Every interface has a link-local address, and only one. Thus, it is an easy choice that requires no additional configuration. One alternative might have been to require that routers be configured prior to use. Also, if the burdon on routing protocols to exchange link-local addresses is so large, another alternative would be to develop a simple (standalone) protocol that is designed specifically to return all addresses on an interface. For example, an ICMP "get addresses" query could result in a response that lists all of an interfaces addresses. This then provides one with the option for having a routing protocol that doesn't mention link-local addresses per se, but uses the "get addresses" protocol to map an address into its link-local counterpart. Whether such an approach is more work than just taking link-local addresses into account in the routing protocol itself becomes an engineering trade off. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 06:49:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id GAA20286 for ipng-dist; Wed, 11 Mar 1998 06:38:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id GAA20265 for ; Wed, 11 Mar 1998 06:38:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA04318 for ; Wed, 11 Mar 1998 06:38:21 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA14372 for ; Wed, 11 Mar 1998 06:38:22 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26520; Wed, 11 Mar 1998 09:38:18 -0500 (EST) Message-Id: <199803111438.JAA26520@ns.ietf.org> 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@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5333) I-D ACTION:draft-ietf-ipngwg-icmp-namelookups-02.txt Date: Wed, 11 Mar 1998 09:38:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Name Lookups Through ICMP Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-namelookups-02.txt Pages : 6 Date : 10-Mar-98 IPv4 addresses are translated to fully-qualified domain names (FQDNs) using the DNS. Experience shows that the IN-ADDR.ARPA zones used for this translation tend to be poorly maintained in some cases. In a larger internet with more frequent site renumbering, the maintenance of such zones will be even more difficult. This document describes an experimental protocol for simply asking an IPv6 node to supply its FQDN when needed. The DNS style of authority delegation is thus eliminated for IPv6 address-to-name translations and the routing infrastructure plays that role. 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-ietf-ipngwg-icmp-namelookups-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-namelookups-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-namelookups-02.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980310115711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-namelookups-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-namelookups-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980310115711.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 10:23:33 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id KAA20858 for ipng-dist; Wed, 11 Mar 1998 10:16:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id KAA20851 for ; Wed, 11 Mar 1998 10:16:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA03625 for ; Wed, 11 Mar 1998 10:16:19 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA00591 for ; Wed, 11 Mar 1998 10:13:46 -0800 (PST) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA23859; Wed, 11 Mar 98 10:10:48 PST Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id KAA02424; Wed, 11 Mar 1998 10:15:07 -0800 Date: Wed, 11 Mar 1998 10:15:07 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803111815.KAA02424@orna.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 5334) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > I also like simplicity and commonality. > However, I also realize that TCP reliable byte stream is a rather different > thing than the datagrams in RAW and DGRAM sockets in that there is not > a one for one correspondence between received packets and receive operations > in the socket API. > > If we think that these extension headers might be interesting to TCP > applications in the future why not make those TCP application have > similar access to these headers as do the UDP and RAW applications? > So you would like the reception of ancillary data by a STREAM socket to be as reliable as the reception of the regular data? Unless we start retransmitting option headers I don't think that is going to be possible. The options which are travelling with a lost segment will be lost and there is no guarantee that the options which are included with the retransmission of the lost segment will be the same. The ancillary data is inherently unreliable. Whether the API/transport drops it because of buffer overflow or it gets lost on the wire the application cannot count on it being 100% reliable. > > I don't think a byte compare of everything between the IP and TCP header > (or a byte compare of the extension headers the application is asking for) > is very complex. > It is more complex when compared to passing the data out to the application for processing. > > How do you know that future applications will not want a reliable delivery > of the fact that the extension headers have changed mid-stream in a > TCP connection? See my comments about reliable ancillary data above. > How do you know that the application will not want this notification to > be synchronized with the data so that it can tell where in the byte stream > the change occurred? I don't. > I don't claim to know the answers to the above questions. > But I think that if we want the API to support ancillary data for TCP > that it would make sense to look at providing an API that doesn't unnecessarily > or accidentally hide information from the applications since we don't know > what the applications will look like. > But what I am proposing is substantially better than what we currently have. Under the current scheme the application gets no notification when things change. > > Fine with me. And I assume a getsockopt of this will return what setsockopt > has set as you originally argued. > Yes. > > Except that when TCP receives 37 1 byte telnet segments which all have > the same extension header content I'd like to be able to pass these > to the application in a single read/recvmsg instead of it being broken > up in 37 1 byte recvmsg calls all having the same ancillary data. > > I don't see how this can be done with the current socket framework > (e.g. in 4.4BSD) without supressing the identical extension headers > in tcp. All this supression adds in a bcmp() in TCP to determine if > the extension headers are identical to the previously received segment. > As I said I am not convinced that we need to provide ancillary data reliability and explicit synchronization of ancillary data with the regular data stream. I also can't comment on specific implementation possibilities for 4.4 BSD since I don't have the source code in front of me at the moment. If you would like to discuss implementation techniques for STREAMS I would be happy to discuss that offline. My instinct about this issue is that unless we can provide 100% reliability of option data, which we know we can't, then simply providing the latest option data we have received is the correct answer. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 11:06:16 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id KAA20977 for ipng-dist; Wed, 11 Mar 1998 10:59:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id KAA20970 for ; Wed, 11 Mar 1998 10:59:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA16352 for ; Wed, 11 Mar 1998 10:58:56 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA19354 for ; Wed, 11 Mar 1998 10:54:43 -0800 (PST) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA24580; Wed, 11 Mar 98 10:51:47 PST Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id KAA02441; Wed, 11 Mar 1998 10:56:06 -0800 Date: Wed, 11 Mar 1998 10:56:06 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803111856.KAA02441@orna.mentat.com> To: Mukesh.Kacker@Eng Subject: (IPng 5335) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, > Thus what you will send through a sendmsg control buffer, or > through sticky opts IPV6_PKTOPTIONS/SO_CMSG would be options > with names like IPV6_PKTINFO, IPV6_HOPLIMT, IPV6_HOPOPTS, > IPV6_DSTOPTS, IPV6_RTHDR, IPV6_NEXTHOP etc. > > The options names you will use to enable the boolean enabling > of optional received stuff and on receive side will have a > IPv6_RECV* prefix (ala IP_RECVDSTADDR). So for receive side we would > use, IPV6_RECVPKTINFO, IPV6_RECVHOPLIMIT, IPV6_RECVHOOPTS, > IPV6_RECVDSTOPTS, IPV6_RECVRTHDR. > > Thus IP{V6}_RECV* prefix options would have a consistent semantics where > when used through setsockopt()/getsockopt() they have boolean semantics > of enabling/disabling optional receive side stuff and when contained > in a control buffer retrieved through recvmsg() [ or whatever way > one gets receive side control buffer ], they represent the content > of the attribute/extension-header. > This is fine with me. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 13:20:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id NAA21375 for ipng-dist; Wed, 11 Mar 1998 13:10:02 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with ESMTP id NAA21368 for ; Wed, 11 Mar 1998 13:09:49 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id NAA09353; Wed, 11 Mar 1998 13:09:40 -0800 (PST) Date: Wed, 11 Mar 1998 13:08:00 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5336) Re: Advanced Sockets API Issue To: Tim Hartrick Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803111815.KAA02424@orna.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So you would like the reception of ancillary data by a STREAM socket > to be as reliable as the reception of the regular data? Unless we > start retransmitting option headers I don't think that is going to be > possible. The options which are travelling with a lost segment will > be lost and there is no guarantee that the options which are included > with the retransmission of the lost segment will be the same. The > ancillary data is inherently unreliable. Whether the API/transport > drops it because of buffer overflow or it gets lost on the wire the > application cannot count on it being 100% reliable. Wait a second. There are two different "reliability" issues: 1. Does/should TCP deliver extension headers reliably even if the extension headers are only included in one TCP segment. 2. Should the API (really: the mechanism between TCP and the application) be capable of delivering extension headers reliably. The answer to 1 is NO. However, is a TCP connection switches from sending extension header content X on all segments to sending extension header content Y on all segments this switch will be reliable in the sense that sooner or later the receiver will get a segment with the new extension header content. (But if the sender switches to content Z 10 seconds after switching to content Y you are correct that the receiver might never get any segments with content Y.) All I'm arguing is that the answer to 2 should be YES. I don't see enough benefit in designing an API where ancillary data can be lost in the receiving node for no good reason since I think it is easy (and efficient) enough to design a mechanism which is reliable. > But what I am proposing is substantially better than what we currently have. > Under the current scheme the application gets no notification when things > change. I agree. But while we are trying to fix it why not explore what we think might be useful for TCP applications that would like to receive ancillary data containing IPv6 extension headers. > My instinct about this issue is that unless we can provide 100% reliability > of option data, which we know we can't, then simply providing the latest > option data we have received is the correct answer. We can (easily in my opinion) provide 100% reliability inside the receiving node i.e. in the path from TCP to the application. So why not provide that mechanism? I'd hate to have an application down the road which would like to be reliably notified of changes to the extension header content that fails occasionally because the receiving node occasionally drops this information. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 17:40:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id RAA21783 for ipng-dist; Wed, 11 Mar 1998 17:34:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id RAA21776 for ; Wed, 11 Mar 1998 17:33:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA04653 for ; Wed, 11 Mar 1998 17:33:52 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA01329 for ; Wed, 11 Mar 1998 17:33:44 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20309; Wed, 11 Mar 1998 17:26:29 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199803090253.AA09082@wasted.zk3.dec.com> References: Your message of "Fri, 06 Mar 1998 12:07:19 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Mar 1998 17:27:57 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 5337) Re: Source Address Selection Issue and Scoping Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Sorry for the delayed response. > I emphatically disagree with your view of correctness. I won't respond > further as my previous mail explained why I disagree with your view and > you did not respond to that mail so I will not respond to yours, as this > is a philosophical difference and not a "technical" one. I agree that this issue is a matter of engineering judgement or philosophy, rather than something for which only one approach is technically correct. That's what I was referring to when I said that requiring the scope of a packet's source and destination addresses be the same was not necessary for correctness. I believe one of the philosophical underpinnings of IP (and one of the important attributes that distinguishes it from some other communications architectures, especially those developed by the traditional telecommunications industry) is to always default in the direction of allowing communication, rather than denying communication, whenever conditions are not perfect. This philosophy is revealed in those old IP aphorisms that you so dislike, like "be liberal in what you accept" and "best-efforts". I believe that philosophy is a key part of IP's robustness and success to date (though it is indeed a part that is being more and more eroded over time, I think because of lack of appreciation of its importance). I'm not sure exactly what your point is about me not responding to your mail. We both posted our opinions, which I think is a more appropriate form of response than a point-by-point technical rebuttal, for an issue that is at heart philosophical and not technical. > I have studied this as an implementor and product engineer as to what is > best for users and I strongly disagree with ever sending any packets that > can fail on a network regardless of IPv6. I'm sure you don't mean that literally, because that's an argument for never sending any packets, since any packet can fail for any number of reasons. > You and I probably need to agree we just disagree,... OK. > But based on the short mail thus far it needs to be discussed possibly > as an agenda item for L.A. Yep, we'll put it on the agenda. > Also note Brian Carpenters mail from the IPv6 Multicast Routing Group > where forcing equal scope requirements may make that problem a moot > issue. I don't know what mail or group you are talking about. Is there an IPv6 Multicast Routing Group that I don't know about?!? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 18:16:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id SAA21854 for ipng-dist; Wed, 11 Mar 1998 18:10:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id SAA21847 for ; Wed, 11 Mar 1998 18:10:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA11968 for ; Wed, 11 Mar 1998 18:10:43 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA17339 for ; Wed, 11 Mar 1998 18:10:43 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA24954 for ; Wed, 11 Mar 1998 18:10:42 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <13022.889552656@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Mar 1998 18:12:10 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 5338) Re: Site Local Addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, it does appear that we do not have consensus on deleting site-local addresses from IPv6. Also, someone mentioned to me another reason for retaining site-locals: deleting them at this point would just strengthen a preception in some quarters that IPv6 is still undergoing significant changes, and therefore is not ready to be taken seriously. While I personally think that deletion of inessential features is a much more benign type of change than addition of new features, and that as a living, evolving technology, it is wrong to expect IP ever to be "done", it is nonetheless important for us to be sensitive to the concerns people have about its stability. So for that reason and the other reasons people have identified, I propose that we keep site-local addresses for now, and continue to work on ironing out the details of their use. Comments? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 18:49:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id SAA21930 for ipng-dist; Wed, 11 Mar 1998 18:43:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id SAA21923 for ; Wed, 11 Mar 1998 18:43:45 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA16939 for ; Wed, 11 Mar 1998 18:43:43 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA29911 for ; Wed, 11 Mar 1998 18:43:44 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id VAA24651; Wed, 11 Mar 1998 21:43:43 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03381; Wed, 11 Mar 1998 21:43:42 -0500 Message-Id: <199803120243.AA03381@wasted.zk3.dec.com> To: Thomas Narten Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 5339) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Tue, 10 Mar 1998 14:08:40 EST." <199803101908.OAA18272@cichlid.raleigh.ibm.com> Date: Wed, 11 Mar 1998 21:43:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I don't think using the NET 10 reasoning to keep site local addresses is valid. That reasoning really was because the IPv4 address is depleting. Also to do Net 10 we do not need site local addresses anyway, if one was so inclined. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 21:09:57 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id VAA22254 for ipng-dist; Wed, 11 Mar 1998 21:05:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id VAA22247 for ; Wed, 11 Mar 1998 21:05:07 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA05263 for ; Wed, 11 Mar 1998 21:05:05 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id VAA01370 for ; Wed, 11 Mar 1998 21:05:02 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id AAA18200; Thu, 12 Mar 1998 00:05:01 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07660; Thu, 12 Mar 1998 00:05:01 -0500 Message-Id: <199803120505.AA07660@wasted.zk3.dec.com> To: Steve Deering Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5340) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Wed, 11 Mar 1998 17:27:57 PST." Date: Thu, 12 Mar 1998 00:05:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >I agree that this issue is a matter of engineering judgement or philosophy, >rather than something for which only one approach is technically correct. >That's what I was referring to when I said that requiring the scope of >a packet's source and destination addresses be the same was not necessary >for correctness. I believe one of the philosophical underpinnings of IP >(and one of the important attributes that distinguishes it from some other >communications architectures, especially those developed by the traditional >telecommunications industry) is to always default in the direction of >allowing communication, rather than denying communication, whenever >conditions are not perfect. This philosophy is revealed in those old IP >aphorisms that you so dislike, like "be liberal in what you accept" and >"best-efforts". I believe that philosophy is a key part of IP's robustness >and success to date (though it is indeed a part that is being more and more >eroded over time, I think because of lack of appreciation of its importance). I believe that the "IP" layer, and from the point an IP packet leaves a source node, thru the path it traverses to the destination node, that the philosophy of "best-effort", from long ago still does apply (though I would like to see us define better than "best effort" if requested thru QOS at some point in time) to IP. I don't believe it applies at other virtual layers in the IP architecture, especially with IPv6 parts, nor do I think it does in many cases today. It is not that I don't like any wise sayings, I don't like when cliches are used to win a debate in and of themselves. I also think that liberal part is very painful to Host implementors and interoperability, but more importantly tracking the IP software in an implementation for scalability, performance, multi-processor systems, etc is very difficult so having a defined set of rules when possible makes the implementation more likely to succeed to satisfy networking product software reqs. These are concepts important to Host products and I really object to folks using cliches as opposed to valid technical reasons for doing things. So "maybe" I object to when the cliches are used, cliches rather than the cliches themselves. Verbose discussion is important. >I'm not sure exactly what your point is about me not responding to your >mail. We both posted our opinions, which I think is a more appropriate >form of response than a point-by-point technical rebuttal, for an issue >that is at heart philosophical and not technical. I agree. I was trying to say its OK to not respond to my philosophical view, but you just said it very well what I mean't. But I do think it useful to have this kind of discussion occasionally as these thougths can be the precedent to architecture ideas and then technical plans. >> I have studied this as an implementor and product engineer as to what is >> best for users and I strongly disagree with ever sending any packets that >> can fail on a network regardless of IPv6. >I'm sure you don't mean that literally, because that's an argument for never >sending any packets, since any packet can fail for any number of reasons. True not what I mean "literally". When a packet of a lesser scope src is sent there is a better chance (I realize I am throwing dice here) IMO, that the packet will fail than not fail, except for the occasional quirk (e.g. Global Address node is on same link as a src node), IFF the network is set up correctly. I do agree it could be a debugging tool or analysis tool to perform such an action. This failure can be prevented by requiring equal scopes or return an error. First the failure will not occur, and second the user will know it has a scope discrepancy, which could point to more serious problems regarding the nodes network configuration internally, what it is hearing externally via ND, and the sys admin configuring addresses etc. >> Also note Brian Carpenters mail from the IPv6 Multicast Routing Group >> where forcing equal scope requirements may make that problem a moot >> issue. >I don't know what mail or group you are talking about. Is there an IPv6 >Multicast Routing Group that I don't know about?!? Whoops wrong Brian.... I mean't Brian Haberman see attached for my reference I was speaking of: thanks /jim ---------------------------------------------- Date: Fri, 06 Mar 1998 07:23:47 -0500 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 3.01 (X11; I; AIX 1) Mime-Version: 1.0 To: IPng Subject: (IPng 5265) Re: Source Address Selection Issue and Scoping References: <199803060622.AA31862@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com wrote: > > > Requiring equal scoped addresses also sets expectations for addresses > correctly on a node. I can go on with more reasons but will stop > for now. Another place where this will become important is site-scoped multicast addresses (FF05::X). While in the process of converting a multicast routing protocol to IPv6, the issue arose as to how do we determine site boundaries if the destination multicast address is FF05::X and the source address is global. By employing Jim's scoping requirement, this question is moot. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 11 21:13:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id VAA22263 for ipng-dist; Wed, 11 Mar 1998 21:09:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id VAA22256 for ; Wed, 11 Mar 1998 21:09:09 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA05726 for ; Wed, 11 Mar 1998 21:09:08 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id VAA03088 for ; Wed, 11 Mar 1998 21:09:07 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id AAA21483; Thu, 12 Mar 1998 00:09:06 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07931; Thu, 12 Mar 1998 00:09:06 -0500 Message-Id: <199803120509.AA07931@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5341) Re: Site Local Addresses In-Reply-To: Your message of "Wed, 11 Mar 1998 18:12:10 PST." Date: Thu, 12 Mar 1998 00:09:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK with me Steve... I agree with you we have to keep evolving and there is nothing wrong with that. I think the concept of "site-local" is very useful for multicast just as a comment. Reality sucks some times........ thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 04:46:27 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id EAA22855 for ipng-dist; Thu, 12 Mar 1998 04:42:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id EAA22848 for ; Thu, 12 Mar 1998 04:42:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA12123; Thu, 12 Mar 1998 04:42:03 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA27202; Thu, 12 Mar 1998 04:42:02 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA31336; Thu, 12 Mar 1998 07:41:46 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA30888; Thu, 12 Mar 1998 07:41:48 -0500 Received: from hygro.raleigh.ibm.com (lig32-225-17-83.us.lig-dial.ibm.com [32.225.17.83]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id HAA18044; Thu, 12 Mar 1998 07:41:57 -0500 (EST) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id HAA05828; Thu, 12 Mar 1998 07:39:00 -0500 Message-Id: <199803121239.HAA05828@hygro.raleigh.ibm.com> To: Pedro Marques cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: (IPng 5342) Re: ND use of link-locals [WAS: Re: Source Address Selection Issue and Scoping] In-reply-to: Your message of "Tue, 10 Mar 1998 23:58:40 PST." <199803110758.XAA02630@pedrom-ultra.cisco.com> Date: Thu, 12 Mar 1998 07:39:00 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, > Erik> Also, there was no data > Erik> to indicate that the "redirect a prefix" would reduce the > Erik> number of redirect packets in practise. > Suppose you have a web server on a link with two routers, one which is > the best nexthop for default and one which is the best nexthop for > the internal network. With the prefix information 2 redirect cache entries > would probably be suficient while without it you will need, statistically, > N/2 cache entries when N is the number of correspondents. The argument that won the day on prefix redirects (this is the DC interim meeting I believe) was that one can construct scenarios that make *either* type of redirect (per-host or prefix based) look better. That is, there are scenarios where the use of prefix redirects results in *more* redirects than the per-host redirects we have today. It all depends on what your assuptions are. Also, the argument that prefix redirects allow you to reduce cache state (i.e., maintain it per-prefix rather than per-host) is somewhat suspect because there are lots of compelling arguments for maintaining per-host state anyway (i.e., PMTU information, RTTs, etc.). That is, having per-prefix state doesn't allow one to do away with the per-destination host state. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 04:46:27 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id EAA22864 for ipng-dist; Thu, 12 Mar 1998 04:42:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id EAA22857 for ; Thu, 12 Mar 1998 04:42:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA12126 for ; Thu, 12 Mar 1998 04:42:04 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA27218 for ; Thu, 12 Mar 1998 04:42:04 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA31342; Thu, 12 Mar 1998 07:41:48 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA30910; Thu, 12 Mar 1998 07:41:51 -0500 Received: from hygro.raleigh.ibm.com (lig32-225-17-83.us.lig-dial.ibm.com [32.225.17.83]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id HAA18046; Thu, 12 Mar 1998 07:41:59 -0500 (EST) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id HAA05554; Thu, 12 Mar 1998 07:09:59 -0500 Message-Id: <199803121209.HAA05554@hygro.raleigh.ibm.com> To: bound@zk3.dec.com cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 5343) Re: Source Address Selection Issue and Scoping In-reply-to: Your message of "Wed, 11 Mar 1998 21:43:42 EST." <199803120243.AA03381@wasted.zk3.dec.com> Date: Thu, 12 Mar 1998 07:09:59 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > I don't think using the NET 10 reasoning to keep site local > addresses is valid. I don't mean to imply that just because IPv4 has net 10 addresses, we must have them in IPv6. My point was that whether we like it or not, there are situations where folks will want to assign addresses without getting them from a provider (e.g., a non Internet connected site, someone who wants some addresses to survive renumbering). This is the reality I was referring to. We have a choice here. Pretend this won't happen and/or tell folks they really shouldn't do that. But IMO, folks will do this anyway (e.g., by just making up a prefix without regard to whether someone else is using it), so designating a site-local prefix is a wise thing to do. It is also wise to then think through the implications that implies. > That reasoning really was because the IPv4 address is depleting. Looking at it another way, some folks are (for whatever reasons) unwilling to get public addresses. In IPv4, address depletion is a big reason why getting addresses is difficult for some. My fear is that with IPv6, however, some folks will still do this for other reasons. > Also to do Net 10 we do not need site local addresses anyway, if one > was so inclined. Site local addresses == net 10 addresses. I see no fundamental difference between the two. But by making site-local addresses part of the architecture, we are more likely to make them work correctly in the boundary cases than we are if we pretend they are no different than other addresses and require no special considerations. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 06:56:32 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id GAA23076 for ipng-dist; Thu, 12 Mar 1998 06:51:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id GAA23069 for ; Thu, 12 Mar 1998 06:51:07 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA28327 for ; Thu, 12 Mar 1998 06:51:04 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA28959 for ; Thu, 12 Mar 1998 06:49:56 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id JAA05623; Thu, 12 Mar 1998 09:49:54 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA31334; Thu, 12 Mar 1998 09:49:52 -0500 Message-Id: <199803121449.AA31334@wasted.zk3.dec.com> To: Thomas Narten Cc: bound@zk3.dec.com, Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 5344) Re: Source Address Selection Issue and Scoping In-Reply-To: Your message of "Thu, 12 Mar 1998 07:09:59 EST." <199803121209.HAA05554@hygro.raleigh.ibm.com> Date: Thu, 12 Mar 1998 09:49:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >Site local addresses == net 10 addresses. I see no fundamental >difference between the two. But by making site-local addresses part of >the architecture, we are more likely to make them work correctly in >the boundary cases than we are if we pretend they are no different >than other addresses and require no special considerations. Good point. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 07:29:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) id HAA23195 for ipng-dist; Thu, 12 Mar 1998 07:25:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta0+Sun/8.9.0.Beta0) with SMTP id HAA23188 for ; Thu, 12 Mar 1998 07:25:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09400 for ; Thu, 12 Mar 1998 07:25:07 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id HAA17120 for ; Thu, 12 Mar 1998 07:24:45 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA06928; Thu, 12 Mar 1998 09:24:44 -0600 Message-Id: <199803121524.JAA06928@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5345) Re: Site Local Addresses In-reply-to: Your message of Wed, 11 Mar 1998 18:12:10 PST. Date: Thu, 12 Mar 1998 09:24:43 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ..., I propose that we keep site-local addresses for now, and > continue to work on ironing out the details of their use. > > Comments? I concur. Use of site-locals will wither away or it won't. Network managers each get their own choice. Implementers get no choice, but they knew the job was dangerous when they took it. Matt (Relieved at not having to purge mentions of site-local from Router Renumbering. But I knew the job was ...) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 13:52:06 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id NAA23967 for ipng-dist; Thu, 12 Mar 1998 13:46:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id NAA23960 for ; Thu, 12 Mar 1998 13:46:45 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA28961 for ; Thu, 12 Mar 1998 13:46:43 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA04286 for ; Thu, 12 Mar 1998 13:46:43 -0800 (PST) Received: from spruce.ipsilon.com (spruce.ipsilon.com [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA20389; Thu, 12 Mar 1998 13:46:42 -0800 Message-Id: <3.0.3.32.19980312134606.00a236b0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 12 Mar 1998 13:46:06 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5346) W.G. Last Call on "IPv6 Name Lookups Through ICMP" Cc: hinden@ipsilon.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on publishing the following document as an Experimental RFC: Title : IPv6 Name Lookups Through ICMP Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-namelookups-02.txt Pages : 6 Date : 10-Mar-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 26, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 14:00:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id NAA24008 for ipng-dist; Thu, 12 Mar 1998 13:55:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id NAA24001 for ; Thu, 12 Mar 1998 13:55:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA02163 for ; Thu, 12 Mar 1998 13:55:36 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA00985 for ; Thu, 12 Mar 1998 13:54:37 -0800 (PST) Received: from spruce.ipsilon.com (spruce.ipsilon.com [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA20659; Thu, 12 Mar 1998 13:54:16 -0800 Message-Id: <3.0.3.32.19980312135339.00a26100@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 12 Mar 1998 13:53:39 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5347) W.G. Last Call on "Neighbor Discovery and Stateless Address Autoconfiguration" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following documents as an Draft Standards: Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : W. Simpson, T. Narten, E. Nordmark Filename : draft-ietf-ipngwg-discovery-v2-02.txt Pages : 92 Date : 25-Feb-98 Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson, T. Narten Filename : draft-ietf-ipngwg-addrconf-v2-02.txt Pages : 25 Date : 17-Feb-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 26, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 14:44:17 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id OAA24149 for ipng-dist; Thu, 12 Mar 1998 14:39:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id OAA24142 for ; Thu, 12 Mar 1998 14:39:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA13814 for ; Thu, 12 Mar 1998 14:39:27 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA21280 for ; Thu, 12 Mar 1998 14:36:14 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA10519; Fri, 13 Mar 1998 09:29:03 +1100 (from kre@munnari.OZ.AU) To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5348) Re: W.G. Last Call on "Neighbor Discovery and Stateless Address Autoconfiguration" In-Reply-To: Bob Hinden's message of "Thu, 12 Mar 1998 13:53:39 -0800." References: <3.0.3.32.19980312135339.00a26100@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Mar 1998 09:28:57 +1100 Message-Id: <2580.889741737@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that the IESG are now requiring docs that advance in grade contain a section specifying what has changed since the earlier doc (if there are no changes, there won't be a new draft, the old RFC will just change status, but that isn't happening here). Addrconf has such a section, discovery doesn't, or not that I could see. Aside from that, and assuming that you have collected the obviously available implementation information, go for it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 14:57:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id OAA24224 for ipng-dist; Thu, 12 Mar 1998 14:52:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id OAA24217 for ; Thu, 12 Mar 1998 14:52:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA16939 for ; Thu, 12 Mar 1998 14:52:18 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA27735 for ; Thu, 12 Mar 1998 14:49:54 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA08390; Fri, 13 Mar 1998 09:47:40 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.eng.sun.com Subject: (IPng 5349) Re: W.G. Last Call on "IPv6 Name Lookups Through ICMP" In-Reply-To: Bob Hinden's message of "Thu, 12 Mar 1998 13:46:06 -0800." References: <3.0.3.32.19980312134606.00a236b0@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Mar 1998 09:47:34 +1100 Message-Id: <2781.889742854@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have sent Matt some comments on that draft, some editorial, some or slightly more substance. I suspect the two issues most worthy of more WG consideration before advancing the doc are whether this technique can be used for anycast address translation (the doc is silent, but appears to say unicast only), (it also gives no suggestion on what to do to translate a multicast address to a name). And second, whether or not a DNS addr->name function is still to be provided (the doc suggests yes, as it presumes that DNS servers will do the ICMP, not clients, so as to allow caching to function). If so, there needs to be some guidance as to when which kind of query ought be done I think - if there is a DNS mechanism defined, people are going to be using it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 15:39:36 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id PAA24299 for ipng-dist; Thu, 12 Mar 1998 15:32:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with ESMTP id PAA24292 for ; Thu, 12 Mar 1998 15:32:46 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id PAA28763; Thu, 12 Mar 1998 15:32:42 -0800 (PST) Date: Thu, 12 Mar 1998 15:31:51 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5350) Re: W.G. Last Call on "Neighbor Discovery and Stateless Address Autoconfiguration" To: Robert Elz Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2580.889741737@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that the IESG are now requiring docs that advance in grade > contain a section specifying what has changed since the earlier doc > (if there are no changes, there won't be a new draft, the old RFC will > just change status, but that isn't happening here). > > Addrconf has such a section, discovery doesn't, or not that I could see. Look again :-) APPENDIX F: CHANGES SINCE RFC 1970 The following changes, which are also marked with change bars ('|' or | '*') in the right margin, have been made since RFC 1970: | [stuff omitted] BTW: There appears to be some editorial problem in that the appendicies are missing from the table of contents. I assume we can fix that after the W.G. last call completes. The missing TOC items are: REFERENCES................................................... 82 | AUTHORS' ADDRESSES........................................... 83 | APPENDIX A: MULTIHOMED HOSTS................................. 84 | APPENDIX B: FUTURE EXTENSIONS................................ 85 | APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE......... 86 | APPENDIX D: SUMMARY OF ISROUTER RULES........................ 88 | APPENDIX E: IMPLEMENTATION ISSUES............................ 89 | Appendix E.1: Reachability confirmations.................. 89 | APPENDIX F: CHANGES SINCE RFC 1970........................... 90 | Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 15:40:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id PAA24319 for ipng-dist; Thu, 12 Mar 1998 15:36:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id PAA24312 for ; Thu, 12 Mar 1998 15:36:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA00210 for ; Thu, 12 Mar 1998 15:36:27 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA19107 for ; Thu, 12 Mar 1998 15:35:35 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id QAA02349 for ; Thu, 12 Mar 1998 16:35:04 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id QAA24185 for ipng@sunroof.Eng.Sun.COM; Thu, 12 Mar 1998 16:35:04 -0700 (MST) Message-Id: <199803122335.QAA24185@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 12 Mar 1998 16:35:04 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 5351) updated Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted a new version of the "Basic Socket Interface Extensions for IPv6" I-D (the planned replacement for RFC 2133). If you want a copy before it shows up in the well-known locations, grab ftp://ftp.kohala.com/pub/rstevens/draft-ietf-ipngwg-bsd-api-new-01.txt Changes made in the March 1998 Edition (-01 draft): - Changed all "hostname" to "nodename" for consistency with other IPv6 documents. - Section 3.3: changed comment for sin6_flowinfo to be "traffic class & flow info" and updated corresponding text description to current definition of these two fields. - Section 3.10 ("Portablity Additions") is new. - Section 6: a new paragraph was added reiterating that the existing gethostbyname() and gethostbyaddr() are not changed. - Section 6.1: change gethostbyname3() to getnodebyname(). Add AI_DEFAULT to handle majority of applications. Renamed AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and IPv4 addresses too. Defined exactly what getnodebyname() must return if the name argument is a numeric address string. - Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword items 2 and 3 in the description of how to handle IPv4-mapped and IPv4-compatible addresses to "lookup a name" for a given address, instead of specifying what type of DNS query to issue. - Section 6.3: added two more requirements to getaddrinfo(). - Section 7: added the following constants to the list for : AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union sockaddr_union and SA_LEN to the lists for . - Updated references. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 17:15:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id RAA24731 for ipng-dist; Thu, 12 Mar 1998 17:10:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id RAA24724 for ; Thu, 12 Mar 1998 17:10:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA24635 for ; Thu, 12 Mar 1998 17:10:23 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id RAA03601 for ; Thu, 12 Mar 1998 17:09:08 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id TAA00740; Thu, 12 Mar 1998 19:08:55 -0600 Message-Id: <199803130108.TAA00740@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com Cc: Steve Deering , Bob Hinden From: "Matt Crawford" Subject: (IPng 5352) Router Renumbering Date: Thu, 12 Mar 1998 19:08:55 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted draft-ietf-ipngwg-router-renum-03.txt. It has *examples* (ooh, ah). It also contains the IANA-assigned type value for router renumbering, so implementers, start your machines. I believe every comment I've received so far is addressed, so I request that the chairs begin a WG last call when the draft appears. The noble I-D editor has been keeping up inhumanly well, so I'm not going to post a copy myself. If anyone's impatient, ask me for it. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 12 21:46:21 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id VAA25024 for ipng-dist; Thu, 12 Mar 1998 21:41:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id VAA25017 for ; Thu, 12 Mar 1998 21:41:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA12158 for ; Thu, 12 Mar 1998 21:41:23 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id VAA23026 for ; Thu, 12 Mar 1998 21:41:19 -0800 (PST) Received: from spruce.ipsilon.com ([205.226.22.78]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id VAA05991; Thu, 12 Mar 1998 21:41:17 -0800 Message-Id: <3.0.3.32.19980312214017.0085a270@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 12 Mar 1998 21:40:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5353) Request for Agenda Items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng working group will meet for two sessions at the Los Angeles IETF. We have requested a third session but it has not been scheduled yet. The current sessions are: MONDAY, March 30, 1998, 1930-2200 THURSDAY, April 2, 1998, 0900-1130 Please send Steve Deering and myself proposed agenda items including topic description and length of time required. Thanks, Bob Hinden / Steve Deering IPng Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 13 05:15:33 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id FAA25418 for ipng-dist; Fri, 13 Mar 1998 05:10:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id FAA25411 for ; Fri, 13 Mar 1998 05:10:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA17719 for ; Fri, 13 Mar 1998 05:10:05 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA24113 for ; Fri, 13 Mar 1998 05:10:05 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA24116; Fri, 13 Mar 1998 08:10:02 -0500 (EST) Message-Id: <199803131310.IAA24116@ns.ietf.org> 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@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5355) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-01.txt Date: Fri, 13 Mar 1998 08:10:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, W. Stevens, J. Bound, S. Thomson Filename : draft-ietf-ipngwg-bsd-api-new-01.txt Pages : 33 Date : 12-Mar-98 The de facto standard application program interface (API) for TCP/IP applications is the ''sockets'' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [6]. | 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-ietf-ipngwg-bsd-api-new-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-01.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980312170541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-new-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980312170541.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 13 09:11:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id JAA25814 for ipng-dist; Fri, 13 Mar 1998 09:06:36 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with ESMTP id JAA25807 for ; Fri, 13 Mar 1998 09:06:30 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id JAA16019 for ; Fri, 13 Mar 1998 09:06:30 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28502; Fri, 13 Mar 1998 09:05:22 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id FAA25399 for ; Fri, 13 Mar 1998 05:02:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA17171 for ; Fri, 13 Mar 1998 05:02:22 -0800 Received: from ceres.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA20687 for ; Fri, 13 Mar 1998 05:02:16 -0800 (PST) Received: (from mailer@localhost) by ceres.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) id WAA18755; Fri, 13 Mar 1998 22:16:26 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by ceres.backyard.wide.toshiba.co.jp via smap (V1.3) id sma018753; Fri Mar 13 22:16:19 1998 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) with ESMTP id WAA02602; Fri, 13 Mar 1998 22:03:20 +0900 (JST) To: thartric@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5356) Re: received packets on raw IPv6 sockets using advanced API In-Reply-To: Your message of "Tue, 10 Mar 1998 17:03:19 -0800" <199803110103.RAA01264@orna.mentat.com> References: <199803110103.RAA01264@orna.mentat.com> X-Mailer: Mew version 1.93b24 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980313215835X.jinmei@backyard.wide.toshiba.co.jp> Date: Fri, 13 Mar 1998 21:58:35 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980302 Lines: 60 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, Thank you for replying, and sorry for my late reply. >>>>> On Tue, 10 Mar 1998 17:03:19 -0800, >>>>> thartric@mentat.com (Tim Hartrick) said: >> >> + We can get the IPv6 header just followed by the datagram. > I don't believe that this is correct. The whole point of having the > flowinfo in the sockaddr_in6, the IPv6_HOPLIMIT ancillary data item, > the IPV6_PKTINFO ancillary data item and the IPV6_HOPOPTS and IPV6_DESTOPTS > ancillary data items was to avoid having to pass "raw" IPv6 base and extension > headers out to the user. If we are going to pass headers out then we might > as well dispense with the ancillary data. Actually, my first expectation of the specification was exactly the same as yours; Since we can get all information in IPv6 headers as ancillary data and via traditional sockets interfaces, the IPv6 header itself should not be passed to the user. But it was different from the Richard's intention. He said >>>>> On Mon, 2 Mar 1998 07:01:07 -0700, >>>>> rstevens@kohala.com (W. Richard Stevens) said: >> Which is correct? Should we expect IPv6 header as a part of a received >> message on a raw IPv6 socket or not? > You get the basic IPv6 header but you don't get any extension headers. > That is what the text was trying to say. So we now have two choices: 1. pass IPv6 header to follow the specification, at least the intention of the author of the specification. Or, 2. change the specification not to include IPv6 header as a part of data passed to user. What do you think? Or do we have a better choice? >> 1. At first, does your implementation follow the above rules? > No. In our implementation the IPv6 base and extension headers are stripped > and only the upper-layer protocol data is returned in the buffer of the > receive call. All other attributes of the IPv6 base and extension headers > must be accessed via ancillary data. I think it's a right behavior if we choose to change the specification. Anyway, I'd appreciate hearing your(and other implementors') opinion. Thanks, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 13 10:28:25 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id KAA28136 for ipng-dist; Fri, 13 Mar 1998 10:24:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id KAA28129 for ; Fri, 13 Mar 1998 10:23:55 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA06815 for ; Fri, 13 Mar 1998 10:23:48 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA08934 for ; Fri, 13 Mar 1998 10:23:48 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA14272; Fri, 13 Mar 98 10:20:48 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA07174; Fri, 13 Mar 1998 10:25:06 -0800 Date: Fri, 13 Mar 1998 10:25:06 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803131825.KAA07174@feller.mentat.com> To: jinmei@backyard.wide.toshiba.co.jp Subject: (IPng 5357) Re: received packets on raw IPv6 sockets using advanced API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > So we now have two choices: > > 1. pass IPv6 header to follow the specification, at least the > intention of the author of the specification. Or, > > 2. change the specification not to include IPv6 header as a part of > data passed to user. > > What do you think? Or do we have a better choice? > My reading of draft-stevens-advanced-api-04.txt, specifically section three, is that RAW sockets are not supposed to pass the IPv6 header to the user. The section has reasoning similar to the reasoning you and I have with respect to using ancillary data to receive all the relevent fields of the header. In reading section three of the recently release RFC I don't see any change which makes be believe that full IPv6 headers should be passed to the user. Is there some other section of RFC 2292 which contradicts section three? > >> 1. At first, does your implementation follow the above rules? > > > No. In our implementation the IPv6 base and extension headers are stripped > > and only the upper-layer protocol data is returned in the buffer of the > > receive call. All other attributes of the IPv6 base and extension headers > > must be accessed via ancillary data. > > I think it's a right behavior if we choose to change the > specification. > > Anyway, I'd appreciate hearing your(and other implementors') opinion. > As I said I don't see any need to change the specification. It seems clear on the point. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 13 11:07:10 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id LAA28200 for ipng-dist; Fri, 13 Mar 1998 11:01:56 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id LAA28193 for ; Fri, 13 Mar 1998 11:01:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA21989 for ; Fri, 13 Mar 1998 11:01:37 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA14961 for ; Fri, 13 Mar 1998 11:00:33 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA15004; Fri, 13 Mar 98 10:57:27 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA07241; Fri, 13 Mar 1998 11:01:45 -0800 Date: Fri, 13 Mar 1998 11:01:45 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803131901.LAA07241@feller.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 5358) Re: Advanced Sockets API Issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > All I'm arguing is that the answer to 2 should be YES. > I don't see enough benefit in designing an API where ancillary data can > be lost in the receiving node for no good reason since I think it is > easy (and efficient) enough to design a mechanism which is reliable. > > > But what I am proposing is substantially better than what we currently have. > > Under the current scheme the application gets no notification when things > > change. > > I agree. But while we are trying to fix it why not explore what we think > might be useful for TCP applications that would like to receive > ancillary data containing IPv6 extension headers. > > > > My instinct about this issue is that unless we can provide 100% reliability > > of option data, which we know we can't, then simply providing the latest > > option data we have received is the correct answer. > > We can (easily in my opinion) provide 100% reliability inside the receiving > node i.e. in the path from TCP to the application. So why not provide > that mechanism? I'd hate to have an application down the road which would > like to be reliably notified of changes to the extension header content > that fails occasionally because the receiving node occasionally drops > this information. > I, like you, don't have all the answers to what an application may or may not want to do down the road. My bias is to provide the simplest service we can invision to solve the problem at hand. The problem at hand, as I see it, is coming up with a single mechanism which will allow RAW, DGRAM and STREAM sockets to recieve option header content. I don't want to pay any extra overhead in anticipation of usages that are not immediately apparent. You are trying to anticipate potential uses for this API which may exist in the future. Assuming that we can get the document modified to something very close to what you, I and Mukesh have been discussing I won't mind implementing the higher overhead, forward looking approach you have suggested. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 13 14:00:28 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id NAA28564 for ipng-dist; Fri, 13 Mar 1998 13:55:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id NAA28557 for ; Fri, 13 Mar 1998 13:55:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA11385 for ; Fri, 13 Mar 1998 13:55:35 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA10482 for ; Fri, 13 Mar 1998 13:54:58 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA05312; Fri, 13 Mar 1998 15:54:11 -0600 Message-Id: <199803132154.PAA05312@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5359) IPv6 reverse lookups Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mimeprimaryboundary Date: Fri, 13 Mar 1998 15:54:11 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain With 12 minutes to spare, I have just submitted draft-ietf-ipngwg-dns-lookups-00.txt. The i-d editor seems to be keeping up amazingly well (applause), but it is Friday so I'll enclose a pointer to my copy here, for anyone who wants to read it right away. Note: this is indeed a "working document" and the mechanisms it relies on are themselves still at the internet-draft stage, so this document is not as refined as one might wish. Matt Crawford --mimeprimaryboundary Content-Type: message/external-body; access-type="anon-ftp"; site="berserk.fnal.gov"; directory="pub"; name="draft-ietf-ipngwg-dns-lookups-00.txt" Content-Description: draft-ietf-ipngwg-dns-lookups-00.txt Content-Type: text/plain --mimeprimaryboundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 13 19:04:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) id SAA29035 for ipng-dist; Fri, 13 Mar 1998 18:59:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id SAA29028 for ; Fri, 13 Mar 1998 18:59:23 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA13570 for ; Fri, 13 Mar 1998 18:59:21 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA12349 for ; Fri, 13 Mar 1998 18:59:22 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id VAA06772; Fri, 13 Mar 1998 21:59:21 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22774; Fri, 13 Mar 1998 21:58:24 -0500 Message-Id: <199803140258.AA22774@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 5361) Re: W.G. Last Call on "Neighbor Discovery and Stateless Address Autoconfiguration" In-Reply-To: Your message of "Thu, 12 Mar 1998 13:53:39 PST." <3.0.3.32.19980312135339.00a26100@mailhost.ipsilon.com> Date: Fri, 13 Mar 1998 21:58:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Did we decide what we want to do with the prefix issue? Seems we can say all prefixes are 64bits as we have no situations where EUI is not ussed. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 14 00:14:09 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id AAA29353 for ipng-dist; Sat, 14 Mar 1998 00:08:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id AAA29346 for ; Sat, 14 Mar 1998 00:08:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA08814 for ; Sat, 14 Mar 1998 00:08:29 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id AAA29360 for ; Sat, 14 Mar 1998 00:08:31 -0800 (PST) Received: from spruce.ipsilon.com ([205.226.22.78]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id AAA20011; Sat, 14 Mar 1998 00:05:57 -0800 Message-Id: <3.0.3.32.19980314000517.009e7100@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 14 Mar 1998 00:05:17 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 5363) Re: W.G. Last Call on "Neighbor Discovery and Stateless Address Autoconfiguration" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199803140258.AA22774@wasted.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >Did we decide what we want to do with the prefix issue? Seems we can >say all prefixes are 64bits as we have no situations where EUI is not >ussed. We decided to leave it as is. Two reasons. The first is that the IPv6 addressing architecture does not require EUI-64 based interface identifiers for all format prefixes. The other reasons is that I think that the code should not, except where it is unavoidable like actually creating interface identifiers, know about allocation boundaries in the addresses. It should deal with everything as prefix/length. I think was one of the important lessons learned with IPv4 and the address classes. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 14 20:27:32 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id UAA00117 for ipng-dist; Sat, 14 Mar 1998 20:21:31 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id UAA00110 for ; Sat, 14 Mar 1998 20:21:23 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA22303 for ; Sat, 14 Mar 1998 20:21:21 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA18541 for ; Sat, 14 Mar 1998 20:21:20 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id XAA18805; Sat, 14 Mar 1998 23:21:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA28067; Sat, 14 Mar 1998 23:21:17 -0500 Message-Id: <199803150421.AA28067@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5365) Re: W.G. Last Call on "Neighbor Discovery and Stateless Address Autoconfiguration" In-Reply-To: Your message of "Sat, 14 Mar 1998 00:05:17 PST." <3.0.3.32.19980314000517.009e7100@mailhost.ipsilon.com> Date: Sat, 14 Mar 1998 23:21:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, OK.... So that is nailed down. Good. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 15 13:29:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id NAA00537 for ipng-dist; Sun, 15 Mar 1998 13:21:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id NAA00530 for ; Sun, 15 Mar 1998 13:20:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA16965 for ; Sun, 15 Mar 1998 13:20:41 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA07446 for ; Sun, 15 Mar 1998 13:20:35 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id OAA09603; Sun, 15 Mar 1998 14:20:33 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id OAA00281; Sun, 15 Mar 1998 14:20:31 -0700 (MST) Message-Id: <199803152120.OAA00281@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Sun, 15 Mar 1998 14:20:31 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: thartric@mentat.com (Tim Hartrick), jinmei@backyard.wide.toshiba.co.jp Subject: (IPng 5366) Re: received packets on raw IPv6 sockets using advanced API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just reread Section 3 of RFC 2292, specifically > All fields in the IPv6 header that an application might want to > change (i.e., everything other than the version number) can be > modified using ancillary data and/or socket options by the > application for output. All fields in a received IPv6 header (other > than the version number and Next Header fields) and all extension > headers are also made available to the application as ancillary data > on input. Hence there is no need for a socket option similar to the > IPv4 IP_HDRINCL socket option. As Tim says, my reading is that the received header not be passed. My earlier comments to Jinmei were based on my experieces coding ping and traceroute (with at least the Solaris implemention), and the basic 40-byte IPv6 headers were passed back on the raw socket. Perhaps we should be even more specific about this in the planned update to the RFC? Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 15 18:24:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id SAA00743 for ipng-dist; Sun, 15 Mar 1998 18:18:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id SAA00736 for ; Sun, 15 Mar 1998 18:18:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA12442 for ; Sun, 15 Mar 1998 18:18:21 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA20531 for ; Sun, 15 Mar 1998 18:18:23 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA12410; Sun, 15 Mar 98 18:15:22 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id SAA09000; Sun, 15 Mar 1998 18:19:41 -0800 Date: Sun, 15 Mar 1998 18:19:41 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803160219.SAA09000@feller.mentat.com> To: rstevens@kohala.com Subject: (IPng 5367) Re: received packets on raw IPv6 sockets using advanced API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > As Tim says, my reading is that the received header not be passed. > My earlier comments to Jinmei were based on my experieces coding > ping and traceroute (with at least the Solaris implemention), and > the basic 40-byte IPv6 headers were passed back on the raw socket. > I believe that the early implementations of RAW sockets passed the IPv6 header all the way out to the user. Ours certainly did and apparently Solaris did as well. Ours has since been modified to con- form to section 3 of RFC 2292. > Perhaps we should be even more specific about this in the planned > update to the RFC? > Probably. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 06:06:28 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id FAA01285 for ipng-dist; Mon, 16 Mar 1998 05:57:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id FAA01274 for ; Mon, 16 Mar 1998 05:56:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA10082 for ; Mon, 16 Mar 1998 05:56:53 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA20365 for ; Mon, 16 Mar 1998 05:56:47 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA16398; Mon, 16 Mar 1998 08:56:40 -0500 (EST) Message-Id: <199803161356.IAA16398@ns.ietf.org> 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@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5369) I-D ACTION:draft-ietf-ipngwg-router-renum-03.txt Date: Mon, 16 Mar 1998 08:56:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Router Renumbering for IPv6 Author(s) : B. Hinden, M. Crawford Filename : draft-ietf-ipngwg-router-renum-03.txt Pages : 21 Date : 13-Mar-98 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering (''RR'') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. 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-ietf-ipngwg-router-renum-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-03.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980313113053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313113053.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 07:25:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id HAA01513 for ipng-dist; Mon, 16 Mar 1998 07:21:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id HAA01506 for ; Mon, 16 Mar 1998 07:21:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA26799 for ; Mon, 16 Mar 1998 07:21:42 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA29577 for ; Mon, 16 Mar 1998 07:20:49 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id QAA20994; Mon, 16 Mar 1998 16:20:37 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA12860; Mon, 16 Mar 1998 16:20:35 +0100 (MET) Message-Id: <199803161520.QAA12860@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6imp@munnari.oz.au, ipng@sunroof.eng.sun.com Subject: (IPng 5371) Re: received packets on raw IPv6 sockets using advanced API In-reply-to: Your message of Mon, 16 Mar 1998 22:59:45 +0900. <19980316225945S.jinmei@backyard.wide.toshiba.co.jp> Date: Mon, 16 Mar 1998 16:20:15 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Anyway, the most important thing is to keep portability on various implementations. Do you mind to change your implementation not to pass IPv6 headers to user? => yes but only when I'll do a major change in the API (raw sockets are used by too many tools (ping, traceroute, gated, ...)). Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 07:32:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id HAA01554 for ipng-dist; Mon, 16 Mar 1998 07:30:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id HAA01547 for ; Mon, 16 Mar 1998 07:29:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29310 for ; Mon, 16 Mar 1998 07:29:54 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id HAA02649 for ; Mon, 16 Mar 1998 07:27:30 -0800 (PST) Received: from spruce.ipsilon.com ([205.226.22.78]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id HAA01948; Mon, 16 Mar 1998 07:26:34 -0800 Message-Id: <3.0.3.32.19980316072624.00a5b760@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 16 Mar 1998 07:26:24 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5372) W.G. Last Call on "IPv6 over Point-to-Point ATM Link" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as an Proposed Standards: Title : IPv6 over Point-to-Point ATM Link Author(s) : K. Yamamoto, Y. Inoue, H. Esaki, Y. Atarashi, K. Cho, A. Hagiwara Filename : draft-yamamoto-ipv6-over-p2p-atm-01.txt Pages : 6 Date : 10-Feb-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 30, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 09:07:17 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id JAA01745 for ipng-dist; Mon, 16 Mar 1998 09:02:19 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with ESMTP id JAA01738 for ; Mon, 16 Mar 1998 09:02:14 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id JAA26149 for ; Mon, 16 Mar 1998 09:02:13 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02899; Mon, 16 Mar 1998 09:01:01 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta1+Sun/8.9.0.Beta1) with SMTP id SAA29010 for ; Fri, 13 Mar 1998 18:39:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA11669 for ; Fri, 13 Mar 1998 18:39:53 -0800 Received: from khms.westfalen.de (khms.westfalen.de [193.174.5.20]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA29706 for ; Fri, 13 Mar 1998 18:25:19 -0800 (PST) Received: from root by khms.westfalen.de with bsmtp (Exim 1.82 #1) id 0yDe9x-0001ig-00 (Debian); Sat, 14 Mar 1998 00:46:41 +0100 Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 14 Mar 1998 00:45:40 +0200 Date: 14 Mar 1998 00:34:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ipng@sunroof.eng.sun.com Message-ID: <6pqavRVXw-B@khms.westfalen.de> In-Reply-To: <199803120243.AA03381@wasted.zk3.dec.com> Subject: (IPng 5373) Re: Source Address Selection Issue and Scoping X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: <199803120243.AA03381@wasted.zk3.dec.com> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com wrote on 11.03.98 in <199803120243.AA03381@wasted.zk3.dec.com>: > I don't think using the NET 10 reasoning to keep site local addresses is > valid. That reasoning really was because the IPv4 address is > depleting. Also to do Net 10 we do not need site local addresses > anyway, if one was so inclined. One reason was address depletion. There's another reason, and it seems to me this is actually worse with IPv6 - unconnected sites. (There are lots of small unconnected sites around, and not all of them have only one link and can thus use link-local addresses.) Originally, unconnected sites could just apply for some IPv4 addresses, until people realized there weren't enough. Then, they could use net 10. What are they going to do in IPv6? All the "usual" addresses are handed down topologically, via providers. Unconnected sites aren't going to get any. They are going to want an IPv6 equivalent of net 10. MfG Kai -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 09:10:19 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id JAA01780 for ipng-dist; Mon, 16 Mar 1998 09:07:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with ESMTP id JAA01771 for ; Mon, 16 Mar 1998 09:07:13 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id JAA26873 for ; Mon, 16 Mar 1998 09:07:12 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02935; Mon, 16 Mar 1998 09:06:00 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id EAA29655 for ; Sat, 14 Mar 1998 04:52:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA28361 for ; Sat, 14 Mar 1998 04:52:10 -0800 Received: from ceres.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA23047 for ; Sat, 14 Mar 1998 04:52:06 -0800 (PST) Received: (from mailer@localhost) by ceres.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) id WAA19791; Sat, 14 Mar 1998 22:05:53 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by ceres.backyard.wide.toshiba.co.jp via smap (V1.3) id sma019789; Sat Mar 14 22:05:36 1998 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) with ESMTP id VAA02995; Sat, 14 Mar 1998 21:52:36 +0900 (JST) To: thartric@mentat.com, rstevens@kohala.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5374) Re: received packets on raw IPv6 sockets using advanced API In-Reply-To: Your message of "Fri, 13 Mar 1998 10:25:06 -0800" <199803131825.KAA07174@feller.mentat.com> References: <199803131825.KAA07174@feller.mentat.com> X-Mailer: Mew version 1.93b24 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980314214750K.jinmei@backyard.wide.toshiba.co.jp> Date: Sat, 14 Mar 1998 21:47:50 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980302 Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim and Richard, >>>>> On Fri, 13 Mar 1998 10:25:06 -0800, >>>>> thartric@mentat.com (Tim Hartrick) said: > My reading of draft-stevens-advanced-api-04.txt, specifically section > three, is that RAW sockets are not supposed to pass the IPv6 header to > the user. The section has reasoning similar to the reasoning you and I > have with respect to using ancillary data to receive all the relevent fields > of the header. In reading section three of the recently release RFC I don't > see any change which makes be believe that full IPv6 headers should be passed > to the user. > Is there some other section of RFC 2292 which contradicts section three? No. There is no essential difference between draft-stevens-advanced-api-04.txt and RFC 2292. But my point is that the author's (i.e. Richard's) intention is to pass IPv6 headers to the user, which is different from your(and my 1st) understanding of the draft and the RFC. So Richard, please let me ask you one more time. The draft and the RFC specify to pass IPv6 headers to the user, don't they? Or did I misread your mail? JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 09:46:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id JAA01904 for ipng-dist; Mon, 16 Mar 1998 09:40:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with ESMTP id JAA01897 for ; Mon, 16 Mar 1998 09:40:03 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id JAA01929 for ; Mon, 16 Mar 1998 09:40:02 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03010; Mon, 16 Mar 1998 09:38:50 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id GAA01348 for ; Mon, 16 Mar 1998 06:08:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA11092 for ; Mon, 16 Mar 1998 06:08:42 -0800 Received: from uh.wide.toshiba.co.jp (uh.wide.toshiba.co.jp [202.249.10.122]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA25474 for ; Mon, 16 Mar 1998 06:07:33 -0800 (PST) Received: from localhost (nat.camp.wide.ad.jp [203.178.143.3]) by uh.wide.toshiba.co.jp (8.8.8/8.8.8) with ESMTP id XAA09056; Mon, 16 Mar 1998 23:03:50 +0900 (JST) To: Francis.Dupont@inria.fr Cc: ipv6imp@munnari.oz.au, ipng@sunroof.eng.sun.com Subject: (IPng 5376) Re: received packets on raw IPv6 sockets using advanced API In-Reply-To: Your message of "Sat, 14 Mar 1998 16:43:35 +0100" <199803141543.QAA08112@givry.inria.fr> References: <199803141543.QAA08112@givry.inria.fr> X-Mailer: Mew version 1.93b24 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980316225945S.jinmei@backyard.wide.toshiba.co.jp> Date: Mon, 16 Mar 1998 22:59:45 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980302 Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 14 Mar 1998 16:43:35 +0100, >>>>> Francis Dupont said: > 1. At first, does your implementation follow the above rules? > => I have not fully finished the code (headers are not yet available > as ancillary data) but my current API uses same ideas. So there are at least two types of implementation. Yours passes IPv6 headers to users, but Tim's doesnt't. But as you see, after some discussions Richard said on the ipng ML that the intention of the RFC is not to pass IPv6 headers to user. I'd like to support it since it's more reasonable according to the specification. Anyway, the most important thing is to keep portability on various implementations. Do you mind to change your implementation not to pass IPv6 headers to user? Regards, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 09:46:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id JAA01895 for ipng-dist; Mon, 16 Mar 1998 09:38:59 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with ESMTP id JAA01888 for ; Mon, 16 Mar 1998 09:38:53 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id JAA01820 for ; Mon, 16 Mar 1998 09:38:53 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02983; Mon, 16 Mar 1998 09:37:41 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id XAA00968 for ; Sun, 15 Mar 1998 23:09:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA09205 for ; Sun, 15 Mar 1998 23:09:15 -0800 Received: from uh.wide.toshiba.co.jp (uh.wide.toshiba.co.jp [202.249.10.122]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA18377 for ; Sun, 15 Mar 1998 23:09:05 -0800 (PST) Received: from localhost (nat.camp.wide.ad.jp [203.178.143.3]) by uh.wide.toshiba.co.jp (8.8.8/8.8.8) with ESMTP id QAA07957; Mon, 16 Mar 1998 16:07:48 +0900 (JST) To: rstevens@kohala.com Cc: thartric@mentat.com, ipng@sunroof.eng.sun.com Subject: (IPng 5375) Re: received packets on raw IPv6 sockets using advanced API In-Reply-To: Your message of "Sun, 15 Mar 1998 14:20:31 -0700" <199803152120.OAA00281@kohala.kohala.com> References: <199803152120.OAA00281@kohala.kohala.com> X-Mailer: Mew version 1.93b24 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980316160347I.jinmei@backyard.wide.toshiba.co.jp> Date: Mon, 16 Mar 1998 16:03:47 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980302 Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, Thank you for clarification. >>>>> On Sun, 15 Mar 1998 14:20:31 -0700, >>>>> rstevens@kohala.com (W. Richard Stevens) said: > I just reread Section 3 of RFC 2292, specifically >> All fields in the IPv6 header that an application might want to >> change (i.e., everything other than the version number) can be >> modified using ancillary data and/or socket options by the >> application for output. All fields in a received IPv6 header (other >> than the version number and Next Header fields) and all extension >> headers are also made available to the application as ancillary data >> on input. Hence there is no need for a socket option similar to the >> IPv4 IP_HDRINCL socket option. > As Tim says, my reading is that the received header not be passed. > My earlier comments to Jinmei were based on my experieces coding > ping and traceroute (with at least the Solaris implemention), and > the basic 40-byte IPv6 headers were passed back on the raw socket. Ok. I think it's reasonable understanding, too. We should implement not to contain IPv6 headers on raw IPv6 sockes. > Perhaps we should be even more specific about this in the planned > update to the RFC? I think so. And I also hope to update examples of your book(Unix network programming 2nd edition), since many people to refer the book and implement their applications according to the examples. Regards, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 10:14:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id KAA02050 for ipng-dist; Mon, 16 Mar 1998 10:06:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id KAA02043 for ; Mon, 16 Mar 1998 10:06:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA22188 for ; Mon, 16 Mar 1998 10:06:36 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA02165 for ; Mon, 16 Mar 1998 10:05:49 -0800 (PST) Received: from spruce.ipsilon.com (spruce.ipsilon.com [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA07102; Mon, 16 Mar 1998 10:05:38 -0800 Message-Id: <3.0.3.32.19980316100528.00953350@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 16 Mar 1998 10:05:28 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5377) IPng web pages updated Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng web pages at http://playground.sun.com/ipng have been updated. Changes include current specifications, new implementations, minutes, etc. Corrections to me. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 13:49:29 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id NAA02536 for ipng-dist; Mon, 16 Mar 1998 13:41:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id NAA02529 for ; Mon, 16 Mar 1998 13:41:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA01736 for ; Mon, 16 Mar 1998 13:41:44 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA27974 for ; Mon, 16 Mar 1998 13:40:57 -0800 (PST) Received: from fleck.iol.unh.edu by iol.unh.edu (4.1/SMI-4.1) id AA10259; Mon, 16 Mar 98 16:37:53 EST Received: by fleck.iol.unh.edu (SMI-8.6/SMI-SVR4) id QAA06646; Mon, 16 Mar 1998 16:36:44 -0500 Date: Mon, 16 Mar 1998 16:36:44 -0500 Message-Id: <199803162136.QAA06646@fleck.iol.unh.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 5378) Source Address Selection From: Jeremy McCooey Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One rather important use of cross-scope communication is actually specified in the ND spec: if the source address of the packet prompting address resolution belongs to the "resolving" node, the node should use that address as the source of its NS. The reasoning behind this is also in the spec. For a node communicating with an off-link destination, this means the use of a global (or site-local) source when resolving the (link local) address of the next hop router. Likewise, it makes sense for a last-hop router that is forwarding traffic to the global address of a destination node to use a link-local source when performing resolution. Jeremy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 13:50:43 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id NAA02546 for ipng-dist; Mon, 16 Mar 1998 13:46:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id NAA02539 for ; Mon, 16 Mar 1998 13:46:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA02767 for ; Mon, 16 Mar 1998 13:45:54 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA00482 for ; Mon, 16 Mar 1998 13:45:06 -0800 (PST) Received: from fleck.iol.unh.edu by iol.unh.edu (4.1/SMI-4.1) id AA10284; Mon, 16 Mar 98 16:42:03 EST Received: by fleck.iol.unh.edu (SMI-8.6/SMI-SVR4) id QAA06648; Mon, 16 Mar 1998 16:40:54 -0500 Date: Mon, 16 Mar 1998 16:40:54 -0500 Message-Id: <199803162140.QAA06648@fleck.iol.unh.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 5379) correction From: Jeremy McCooey Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry.. "resolving" should be "soliciting." Hopefully this was clear from the context. Jeremy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 16 19:28:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id TAA03010 for ipng-dist; Mon, 16 Mar 1998 19:24:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id TAA03003 for ; Mon, 16 Mar 1998 19:24:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA25840 for ; Mon, 16 Mar 1998 19:24:31 -0800 Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id TAA23815 for ; Mon, 16 Mar 1998 19:24:33 -0800 (PST) Received: from localhost by ux6.sp.cs.cmu.edu id aa28630; 16 Mar 98 22:23 EST To: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com From: Dave Johnson Reply-To: Dave Johnson Subject: (IPng 5380) New version of Mobile IPv6 draft submitted Date: Mon, 16 Mar 1998 22:23:49 -0500 Message-ID: <28628.890105029@ux6.sp.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, I submitted a revised version of the Internet-Draft specifying Mobile IP for IPv6. This version of the draft is close to the final specification and represents the rough consensus of the Mobile IP working group. We expect to go to Last Call soon, although some minor issues still need to be addressed in the draft. The draft is now working its way through the Internet-Draft publication process and an official announcement for it will come out at some point, but here is an early unofficial announcement: Title : Mobility Support in IPv6 Author(s) : David B. Johnson, Charles Perkins Filename : draft-ietf-mobileip-ipv6-05.txt Pages : 72 Date : 13-Mar-98 This document specifies the operation of mobile computers using IPv6. Each 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 the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. Once the official announcement gets issued, copies of the draft will be available from the usual places. Until then, if you'd like a copy now, it is available by FTP on our server. The URL is: ftp://ftp.monarch.cs.cmu.edu/pub/internet-drafts/ draft-ietf-mobileip-ipv6-05.txt Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 01:49:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id BAA03415 for ipng-dist; Tue, 17 Mar 1998 01:45:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id BAA03396; Tue, 17 Mar 1998 01:41:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA01074; Tue, 17 Mar 1998 01:41:42 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id BAA17381; Tue, 17 Mar 1998 01:41:40 -0800 (PST) Received: from nestvx.kar.dec.com (nestvx.kar.dec.com [16.185.112.1]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id EAA20133; Tue, 17 Mar 1998 04:41:26 -0500 (EST) Received: from sand2.kar.dec.com by nestvx.kar.dec.com; (5.65/1.1.8.2/10Jul96-9.1MPM) id AA16095; Tue, 17 Mar 1998 10:42:06 +0100 Received: from localhost by sand2.kar.dec.com (5.65v3.2/1.1.10.5/15May97-1138AM) id AA09638; Tue, 17 Mar 1998 10:42:03 +0100 Message-Id: <9803170942.AA09638@sand2.kar.dec.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: ipng@sunroof.eng.sun.com Cc: ion@sunroof.eng.sun.com, jork@kar.dec.com Subject: (IPng 5381) Re: W.G. Last Call on "IPv6 over Point-to-Point ATM Link" In-Reply-To: Your message of "Mon, 16 Mar 98 07:26:24 PST." <3.0.3.32.19980316072624.00a5b760@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Mar 98 10:42:02 +0100 From: "Markus Jork" X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is a IPng working group last call for comments on advancing the > following document as an Proposed Standards: > > Title : IPv6 over Point-to-Point ATM Link > Author(s) : K. Yamamoto, Y. Inoue, H. Esaki, Y. Atarashi, > K. Cho, A. Hagiwara > Filename : draft-yamamoto-ipv6-over-p2p-atm-01.txt ??? I'm very surprised that this document is going into last call! I thought it was very clear that the ion group is taking care of IPv6 over ATM and other NBMA networks. I'm not saying I disagree with the contents of this draft. It's similar to what we have in draft-ietf-ion-ipv6-01.txt and draft-ietf-ion-ipv6-atm-01.txt. draft-ietf-ion-ipv6-01.txt defines a general framework for IPv6 over NBMA networks and draft-ietf-ion-ipv6-atm-01.txt is the ATM specific companion document. There is also a Frame Relay specific document draft-ietf-ion-ipv6-fr-00.txt. The ion architecture *explicitely* covers the ATM point-to-point (PVC) case and that pretty much results in what is being proposed in draft-yamamoto-ipv6-over-p2p-atm-01.txt. So it doesn't really make sense to advance this draft. Markus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 01:50:16 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id BAA03435 for ipng-dist; Tue, 17 Mar 1998 01:47:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id BAA03424 for ; Tue, 17 Mar 1998 01:47:04 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA01510 for ; Tue, 17 Mar 1998 01:47:03 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id BAA19514 for ; Tue, 17 Mar 1998 01:47:02 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id JAA01747; Tue, 17 Mar 1998 09:44:04 GMT Message-Id: <199803170944.JAA01747@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 17 Mar 1998 09:47:18 +0000 To: Dave Johnson From: Peter Curran Subject: (IPng 5382) Re: New version of Mobile IPv6 draft submitted Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com In-Reply-To: <28628.890105029@ux6.sp.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave I haven't been keeping up with this as well as I should. Can you tell me if mobile IPv6 still requires that all implementations support the mobile bindings cache, as was previously proposed. I remember that this cause some controversy at the time and wondered if it had ever been resolved? Peter TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 07:22:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id HAA03781 for ipng-dist; Tue, 17 Mar 1998 07:14:53 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id HAA03774 for ; Tue, 17 Mar 1998 07:14:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA06630 for ; Tue, 17 Mar 1998 07:14:41 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA05628 for ; Tue, 17 Mar 1998 07:13:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA01796; Tue, 17 Mar 1998 10:13:28 -0500 (EST) Message-Id: <199803171513.KAA01796@ns.ietf.org> 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@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5385) I-D ACTION:draft-ietf-ipngwg-dns-lookups-00.txt Date: Tue, 17 Mar 1998 10:13:28 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : DNS Lookups Keyed on IPv6 Addresses Author(s) : M. Crawford Filename : draft-ietf-ipngwg-dns-lookups-00.txt Pages : 7 Date : 16-Mar-98 This document defines a new structure for the zones which support DNS lookups keyed on IPV6 addresses. (Often called reverse lookups.) It allows address space to be delegated on arbitrary bit-boundaries. The delegation information can be be usefully cached. A zone describing delegated space can be used for multiple parallel copies of that address space, as for a dual-homed provider or site, and need not be modified if the space is renumbered at a higher level. The new structure can coexist with the old tree under the same name, IP6.INT. 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-ietf-ipngwg-dns-lookups-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-00.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980316125248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316125248.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 07:22:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id HAA03802 for ipng-dist; Tue, 17 Mar 1998 07:16:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id HAA03795 for ; Tue, 17 Mar 1998 07:15:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA06945 for ; Tue, 17 Mar 1998 07:15:55 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA05667 for ; Tue, 17 Mar 1998 07:13:39 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA01825; Tue, 17 Mar 1998 10:13:32 -0500 (EST) Message-Id: <199803171513.KAA01825@ns.ietf.org> 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@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5387) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-04.txt Date: Tue, 17 Mar 1998 10:13:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : An IPv6 Aggregatable Global Unicast Address Format Author(s) : B. Hinden, M. O'Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-04.txt Pages : 11 Date : 16-Mar-98 This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the ''IPv6 Addressing Architecture'' [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, ''An IPv6 Provider-Based Unicast Address Format''. RFC 2073 will become historic. The Aggregatable Global Unicast Address Format is an improvement over RFC 2073 in a number of areas. The major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology. 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-ietf-ipngwg-unicast-aggr-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-unicast-aggr-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-04.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980316125606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-aggr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316125606.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 08:39:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id IAA03920 for ipng-dist; Tue, 17 Mar 1998 08:30:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id IAA03913 for ; Tue, 17 Mar 1998 08:30:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27311 for ; Tue, 17 Mar 1998 08:30:14 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA15228 for ; Tue, 17 Mar 1998 08:29:16 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id IAA02301; Tue, 17 Mar 1998 08:29:14 -0800 Message-Id: <3.0.3.32.19980317082906.009b1bf0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 17 Mar 1998 08:29:06 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5388) W.G. Last Call on "Router Renumbering for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Router Renumbering for IPv6 Author(s) : M. Crawford, B. Hinden Filename : draft-ietf-ipngwg-router-renum-03.txt Pages : 21 Date : 13-Mar-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 31, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 09:02:26 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id IAA03998 for ipng-dist; Tue, 17 Mar 1998 08:53:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id IAA03991 for ; Tue, 17 Mar 1998 08:53:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA04162 for ; Tue, 17 Mar 1998 08:52:57 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA18798 for ; Tue, 17 Mar 1998 08:52:51 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA14747; Tue, 17 Mar 1998 10:52:46 -0600 Message-Id: <199803171652.KAA14747@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5389) Re: W.G. Last Call on "Router Renumbering for IPv6" In-reply-to: Your message of Tue, 17 Mar 1998 08:29:06 PST. <3.0.3.32.19980317082906.009b1bf0@mailhost.iprg.nokia.com> Date: Tue, 17 Mar 1998 10:52:46 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm going to get in the zeroth comment myself. After the deadline I realized I hadn't mentioned that replies to multicast commands should be sent after a random time delay. Consider it said. But I welcome opinions on whether the bound of the delay interval must be given in the command packets, as opposed to being a fixed value. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 09:30:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id JAA04045 for ipng-dist; Tue, 17 Mar 1998 09:25:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with ESMTP id JAA04038 for ; Tue, 17 Mar 1998 09:25:16 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id JAA24078 for ; Tue, 17 Mar 1998 09:25:15 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05028; Tue, 17 Mar 1998 09:24:03 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id FAA03688 for ; Tue, 17 Mar 1998 05:45:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA17736 for ; Tue, 17 Mar 1998 05:45:06 -0800 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA19949 for ; Tue, 17 Mar 1998 05:44:58 -0800 (PST) Message-Id: <199803171344.FAA19949@saturn.sun.com> Received: from gauss (LOCALHOST) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA279842342; Tue, 17 Mar 1998 08:45:42 -0500 To: ipng@sunroof.eng.sun.com Subject: (IPng 5390) Multicast Loopback in bsd-api-new-01 Date: Tue, 17 Mar 1998 08:45:40 -0500 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I feel that the following fragment of draft-ietf-ipngwg-bsd-api-new-01.txt is unclear: > IPV6_MULTICAST_LOOP > > Controls whether outgoing multicast packets sent should be > delivered back to the local application. A toggle. If the > option is set to 1, multicast packets are looped back. If it > is set to 0, they are not. Other option values return an | > error of EINVAL. It seems to me that this could mean at least three different things. Which of the following three categories of sockets does this option control loopback for (among sockets which are listeners for the appropriate multicast group): 1. The socket which is sending the packet. 2. Any sockets that the process ("local application") owns. 3. Any sockets on the sending machine. I'm guessing that (1) was the intention of the writers. But the way it's currently written, it sounds more like (2). If you wish, I can come up with a plausible example of when a process would have two sockets listening to the same multicast group. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 09:30:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id JAA04058 for ipng-dist; Tue, 17 Mar 1998 09:26:14 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with ESMTP id JAA04051 for ; Tue, 17 Mar 1998 09:26:07 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id JAA24268 for ; Tue, 17 Mar 1998 09:26:06 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05055; Tue, 17 Mar 1998 09:24:55 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id FAA03740 for ; Tue, 17 Mar 1998 05:56:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18718 for ; Tue, 17 Mar 1998 05:56:39 -0800 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA25477 for ; Tue, 17 Mar 1998 05:56:38 -0800 (PST) Message-Id: <199803171356.FAA25477@saturn.sun.com> Received: from gauss (LOCALHOST) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA282113042; Tue, 17 Mar 1998 08:57:22 -0500 To: ipng@sunroof.eng.sun.com Subject: (IPng 5391) Thread friendly in bsd-api-new-01 Date: Tue, 17 Mar 1998 08:57:21 -0500 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In draft-ietf-ipngwg-bsd-api-new-01.txt, getnodebyname() is designed (and specified) to be thread safe. But I think in one small respect it is not thread-friendly. Apparently it still returns error codes through the global variable h_errno. I realize that this variable could well be thread-specific, in which case there would not be a problem. Perhaps this should be specified. But in that case, note that the API would be depending on the threads implementation having thread-specific data. It might be cleaner to just avoid using a global variable for the error code. In any case, I do not think this is of much importance. After all, does it matter if there's a tiny chance of the wrong error code being reported? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 09:31:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) id JAA04078 for ipng-dist; Tue, 17 Mar 1998 09:28:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with ESMTP id JAA04071 for ; Tue, 17 Mar 1998 09:27:59 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id JAA24551 for ; Tue, 17 Mar 1998 09:27:58 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05084; Tue, 17 Mar 1998 09:26:47 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta2+Sun/8.9.0.Beta2) with SMTP id HAA03783 for ; Tue, 17 Mar 1998 07:15:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA06711 for ; Tue, 17 Mar 1998 07:15:06 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id HAA06233 for ; Tue, 17 Mar 1998 07:14:40 -0800 (PST) Received: from spruce.iprg.nokia.com ([205.226.22.78]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id HAA00300; Tue, 17 Mar 1998 07:14:37 -0800 Message-Id: <3.0.3.32.19980317071423.008a0730@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 17 Mar 1998 07:14:23 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5392) W.G. Last Call on "Router Renumbering for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Router Renumbering for IPv6 Author(s) : M. Crawford, B. Hinden Filename : draft-ietf-ipngwg-router-renum-03.txt Pages : 21 Date : 13-Mar-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on March 31, 1998. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 11:50:23 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA04479 for ipng-dist; Tue, 17 Mar 1998 11:45:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA04463 for ; Tue, 17 Mar 1998 11:44:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA00612 for ; Tue, 17 Mar 1998 11:44:49 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA25835 for ; Tue, 17 Mar 1998 11:41:06 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA27589; Tue, 17 Mar 98 11:38:07 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA10356; Tue, 17 Mar 1998 11:42:29 -0800 Date: Tue, 17 Mar 1998 11:42:29 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803171942.LAA10356@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5393) Advanced Sockets API X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, There have been a number of comments and questions regarding the Advanced Socket API draft (now RFC 2292) over the last six months or so. There was a desire I believe to let these things accumulate until there was sufficient implementation experience to warrant revising the document. Here is a non-exhaustive list of the problems which I have seen individuals comment about on this list and privately. The area which has seen the largest amount of comment is the methods used for the send- ing and receiving of ancillary data. Based on this list I would like to propose that we turn the crank on a revision of RFC 2292. 1) Routing header structures and library routine update. The strict/loose bits have been removed from the IPv6 type 0 routing header. At a minimum the structure and library calls need to be up- dated to reflect this change. There also was some sentiment, expressed by Mark Smith I believe, that the existing library functions are too closely tied to the type 0 routing header. 2) Section 9 appears to be unnecessary. Section 9 of RFC 2292 does not appear to be synchronized with the rest of the document. This section describes various ordering and padding transformations which the kernel might make on individual IPv6 destination or hop-by-hop options which had been passed into the kernel using ancillary data. The descriptions in section 9 are inconsistent with the methods described in earlier sections for specifying IPv6 destination and hop-by-hop options headers. 3) A question was raised as to why the IPV6_NEXTHOP ancillary data item was specified to use a sockaddr_in6 as its cmsg_data instead of an in6_addr. There doesn't seem to be any reason to carry the added information con- tained in a sockaddr_in6. 4) IPPROTO_IPV6 level ancillary data and options problems. It has been noted by me and others on the list that the current methods for enabling and disabling reception of ancillary data and receiving and sending ancillary data have a number of problems. Some of these problems are cosmetic but others are more fundamental. - The IPV6_PKTOPTIONS option is used in conjunction with setsockopt to pass a vector of IPPROTO_IPV6 level "sticky" options through to the kernel. The vector is formatted as a sequence of cmsghdr structures having a level of IPPROTO_IPV6 and a type specifiying on of the IPPROTO_IPV6 level sticky options. Those options are: IPV6_DSTOPTS IPV6_HOPLIMIT IPV6_HOPOPTS IPV6_NEXTHOP IPV6_PKTINFO IPV6_RTHDR The IPV6_PKTOPTIONS option is used in conjunction with getsockopt to retrieve a vector of IPPROTO_IPV6 level options which represent the last value of the options received by the socket from the peer. This definition makes it impossible to retrieve the settings of the "sticky" options on the local socket. A proposal was made to revise the definition of IPV6_PKTOPTIONS in as follows. The option would be renamed to something like SO_CMSG and would be an SOL_SOCKET level option rather than an IPPROTO_IPV6 option. The new more generic option would allow vectors of options to be passed to the kernel in exactly the same fashion as IPV6_PKT- OPTIONS. The difference being that the level and type of each option would be specified by the level and type in the cmsghdr structure associated with the option. The behavior of the SOL_SOCKET/SO_CMSG option when used in conjunction with getsockopt would be to return the local settings of the "sticky" options specified in the vector of cmsghdr structures. - The existing definition of IPV6_PKTOPTIONS was originally specified so that an application could retrieve the most recently received options from a STREAM socket. Unfortunately the IPV6_PKTOPTIONS option also had to work with RAW and DGRAM sockets. This left us with multiple mechanisms to receive ancillary data on non-STREAM sockets. A proposal has been made to change to the document to allow STREAM sockets to receive ancillary data using recvmsg in exactly the same way that RAW and DGRAM sockets receive ancillary data. By making this change we provide a single method for a receiving ancillary data items which works for STREAM, RAW and DGRAM sockets. The only difference between STREAM, RAW and DGRAM sockets would be that STREAM sockets could not used sendmsg to send ancillary data. This restriction could be removed as well at some price in efficiency and performance. - It has been noted that existing IPv4 BSD ancillary data options use different type name for specifying the sending versus receiving of an option. For example the IP_RECVOPTS is used to enable receiving of IPv4 options via ancillary data. The level and type of the cmsghdr structure associated with the IP_RECVOPTS ancillary data item is IPPROTO_IP and IP_RECVOPTS respectively. In order to send IPv4 options one must use setsockopt with a level of IPPROTO_IP and a name of IP_OPTIONS. A proposal has been made to make the IPv6 ancillary data handling more consistent with the way IPv4 ancillary data is handled. We would define the following IPPROTO_IPV6 level options for enabling and disabling the reception of IPv6 ancillary data. The specified types would also be used in the cmsghdr type field when the option was received via recvmsg. [set|get]sockopt data cmsg_data IPV6_RECVPKTINFO int struct in6_pktinfo IPV6_RECVHOPLIMIT int int IPV6_RECVHOPOPTS int buf/struct ip6_hbh IPV6_RECVDSTOPTS int buf/struct ip6_dest IPV6_RECVRTHDR int buf/struct ip6_rthdr On the sending side the existing IPPROTO_IPV6 level options could be set individually using setsockopt, set as a group using SO_CMSG, or specified as ancillary data with a sendmsg call. The first two would result in "sticky" settings while the last would be per-packet. The existing send side IPPROTO_IPV6 options are as follows. [set|get]sockopt data cmsg_data IPV6_PKTINFO struct in6_pktinfo struct in6_pktinfo IPV6_HOPLIMIT int int IPV6_NEXTHOP struct sockaddr_in6 struct sockaddr_in6 IPV6_HOPOPTS buf/struct ip6_hbh buf/struct ip6_hbh IPV6_DSTOPTS buf/struct ip6_dest buf/struct ip6_dest IPV6_RTHDR buf/struct ip6_rthdr buf/struct ip6_rthdr Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 16:41:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id QAA04808 for ipng-dist; Tue, 17 Mar 1998 16:34:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id QAA04801 for ; Tue, 17 Mar 1998 16:34:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA28564 for ; Tue, 17 Mar 1998 16:34:19 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA10510 for ; Tue, 17 Mar 1998 16:34:19 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id RAA14105; Tue, 17 Mar 1998 17:34:18 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id RAA19393; Tue, 17 Mar 1998 17:34:15 -0700 (MST) Message-Id: <199803180034.RAA19393@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 17 Mar 1998 17:34:14 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 5394) Re: Advanced Sockets API Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Mar 17, 11:42am you write:] > > Based on this list I would like to > propose that we turn the crank on a revision of RFC 2292. Agreed. > 3) A question was raised as to why the IPV6_NEXTHOP ancillary data item > was specified to use a sockaddr_in6 as its cmsg_data instead of an > in6_addr. > > There doesn't seem to be any reason to carry the added information con- > tained in a sockaddr_in6. Actually, its worded so that the next hop is *any* type of socket address structure. The intent was that someone might find a use for other socket address structures (e.g., sockaddr_dl{}s), so don't tie the option to just IPv6 addresses. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 16:42:06 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id QAA04818 for ipng-dist; Tue, 17 Mar 1998 16:38:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id QAA04811 for ; Tue, 17 Mar 1998 16:38:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA29707 for ; Tue, 17 Mar 1998 16:38:04 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA12508 for ; Tue, 17 Mar 1998 16:38:05 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id RAA14115; Tue, 17 Mar 1998 17:38:04 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id RAA19412; Tue, 17 Mar 1998 17:38:03 -0700 (MST) Message-Id: <199803180038.RAA19412@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 17 Mar 1998 17:38:03 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Steve Soule , ipng@sunroof.eng.sun.com Subject: (IPng 5395) Re: Thread friendly in bsd-api-new-01 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Mar 17, 8:57am you write:] > In draft-ietf-ipngwg-bsd-api-new-01.txt, getnodebyname() is designed > (and specified) to be thread safe. But I think in one small respect > it is not thread-friendly. Apparently it still returns error codes > through the global variable h_errno. Yes, you are right, and I think this should be corrected. Nothing was said at all about how errors are reported by this function (other than a null pointer return), until that one example was thrown in at the end. Suggestions? Many of the existing gethostbyname_r() implementations add another "int *" argument in which the error code is returned. Or some variable like h_errno could be specified as thread-specific. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 17:00:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id QAA04863 for ipng-dist; Tue, 17 Mar 1998 16:54:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id QAA04856 for ; Tue, 17 Mar 1998 16:54:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA05319 for ; Tue, 17 Mar 1998 16:54:38 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA21139 for ; Tue, 17 Mar 1998 16:54:37 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id RAA14141; Tue, 17 Mar 1998 17:54:35 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id RAA19466; Tue, 17 Mar 1998 17:54:35 -0700 (MST) Message-Id: <199803180054.RAA19466@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 17 Mar 1998 17:54:35 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Steve Soule , ipng@sunroof.eng.sun.com Subject: (IPng 5396) Re: Multicast Loopback in bsd-api-new-01 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Mar 17, 8:45am you write:] > > > IPV6_MULTICAST_LOOP > > > > Controls whether outgoing multicast packets sent should be > > delivered back to the local application. A toggle. If the > > option is set to 1, multicast packets are looped back. If it > > is set to 0, they are not. Other option values return an | > > error of EINVAL. > > It seems to me that this could mean at least three different things. It was intended to mean the same as the IP_MULTICAST_LOOP option means for IPv4. I agree that the above wording could be better. How about the following, "borrowed" somewhat from Steve Deering's 1989 writeup: IPV6_MULTICAST_LOOP If a multicast datagram is sent to a group to which the sending host itself belongs (on the outgoing interface), a copy of the datagram is looped back by the IP layer for local delivery if this option is set to 1. If this option is set to 0 a copy is not looped back. Other option values return an error of EINVAL. I also just realized that we do not specify any defaults for these three output multicast socket options. Should we explicitly say - if IPV6_MULTICAST_IF is not set, the kernel chooses the outgoing interface, - if IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 today), and - if IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as IPv4 today). Comments? Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 17:00:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id QAA04872 for ipng-dist; Tue, 17 Mar 1998 16:56:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id QAA04865 for ; Tue, 17 Mar 1998 16:56:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA05843 for ; Tue, 17 Mar 1998 16:56:05 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA21847 for ; Tue, 17 Mar 1998 16:56:03 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05123; Tue, 17 Mar 98 16:53:01 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA10637; Tue, 17 Mar 1998 16:57:22 -0800 Date: Tue, 17 Mar 1998 16:57:22 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803180057.QAA10637@feller.mentat.com> To: rstevens@kohala.com Subject: (IPng 5397) Re: Advanced Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > Actually, its worded so that the next hop is *any* type of socket address > structure. The intent was that someone might find a use for other socket > address structures (e.g., sockaddr_dl{}s), so don't tie the option to just > IPv6 addresses. > I get it. So shouldn't this option then be the SOL_SOCKET/SO_NEXTHOP option? Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 17:30:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id RAA04988 for ipng-dist; Tue, 17 Mar 1998 17:23:31 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id RAA04980 for ; Tue, 17 Mar 1998 17:23:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA13960 for ; Tue, 17 Mar 1998 17:23:17 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA06420 for ; Tue, 17 Mar 1998 17:23:19 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id SAA14214; Tue, 17 Mar 1998 18:23:18 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id SAA19574; Tue, 17 Mar 1998 18:23:17 -0700 (MST) Message-Id: <199803180123.SAA19574@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 17 Mar 1998 18:23:17 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: thartric@mentat.com (Tim Hartrick) Subject: (IPng 5398) Re: Advanced Sockets API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Mar 17, 4:57pm you write:] > > > Actually, its worded so that the next hop is *any* type of socket address > > structure. The intent was that someone might find a use for other socket > > address structures (e.g., sockaddr_dl{}s), so don't tie the option to just > > IPv6 addresses. > > I get it. So shouldn't this option then be the SOL_SOCKET/SO_NEXTHOP > option? We could, but the intent was not that this worked for other protocols (i.e., vendors didn't have to retrofit it to IPv4), so we made it an IPv6 option. But it might be "cleaner" as a generic option? Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 17:50:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id RAA05020 for ipng-dist; Tue, 17 Mar 1998 17:41:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id RAA05013 for ; Tue, 17 Mar 1998 17:41:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA17708 for ; Tue, 17 Mar 1998 17:41:01 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id RAA15325 for ; Tue, 17 Mar 1998 17:41:00 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA06130; Tue, 17 Mar 98 17:38:02 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA10654; Tue, 17 Mar 1998 17:42:24 -0800 Date: Tue, 17 Mar 1998 17:42:24 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803180142.RAA10654@feller.mentat.com> To: rstevens@kohala.com Subject: (IPng 5399) Re: Advanced Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > > > I get it. So shouldn't this option then be the SOL_SOCKET/SO_NEXTHOP > > option? > > We could, but the intent was not that this worked for other protocols > (i.e., vendors didn't have to retrofit it to IPv4), so we made it an > IPv6 option. But it might be "cleaner" as a generic option? > Changing the name would not imply that it had to work for any AF_xxx. Which AF_xxx it worked for would be an implementation decision. We would probably only implement it for AF_INET6 but other vendors may wish to implement it for AF_INET and AF_LINK or whatever. Just out of curiousity what is this option used for anyway. I noted that it can be used as a replacement for SO_DONTROUTE. Are there uses for this option which are not obvious. It is a real pain in the butt to implement. I hope it has some value to someone. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 18:09:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id SAA05040 for ipng-dist; Tue, 17 Mar 1998 18:00:52 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id SAA05033 for ; Tue, 17 Mar 1998 18:00:41 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id SAA17976; Tue, 17 Mar 1998 18:00:41 -0800 (PST) Date: Tue, 17 Mar 1998 17:58:51 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5400) Re: Multicast Loopback in bsd-api-new-01 To: Steve Soule Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803171344.FAA19949@saturn.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I feel that the following fragment of > draft-ietf-ipngwg-bsd-api-new-01.txt is unclear: > > > IPV6_MULTICAST_LOOP > > > > Controls whether outgoing multicast packets sent should be > > delivered back to the local application. A toggle. If the > > option is set to 1, multicast packets are looped back. If it > > is set to 0, they are not. Other option values return an | > > error of EINVAL. > > It seems to me that this could mean at least three different things. > Which of the following three categories of sockets does this option > control loopback for (among sockets which are listeners for the > appropriate multicast group): > 1. The socket which is sending the packet. > 2. Any sockets that the process ("local application") owns. > 3. Any sockets on the sending machine. > > I'm guessing that (1) was the intention of the writers. But the way > it's currently written, it sounds more like (2). And I would argue that the correct description based on what IP_MULTICAST_LOOP does in IPv4 is (3). Additionally I'd suspect that in many implementations the protocol stack does not know what processes have what sockets open - this is particularly true for implementations that allow sockets to be shared between different processes (for example, fork() in Unix). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 22:21:19 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id WAA05604 for ipng-dist; Tue, 17 Mar 1998 22:16:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id WAA05597 for ; Tue, 17 Mar 1998 22:16:26 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA23651 for ; Tue, 17 Mar 1998 22:16:16 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA03284 for ; Tue, 17 Mar 1998 22:16:17 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id BAA07174; Wed, 18 Mar 1998 01:16:15 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22892; Wed, 18 Mar 1998 01:16:09 -0500 Message-Id: <199803180616.AA22892@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: Steve Soule , ipng@sunroof.eng.sun.com Subject: (IPng 5402) Re: Thread friendly in bsd-api-new-01 In-Reply-To: Your message of "Tue, 17 Mar 1998 17:38:03 MST." <199803180038.RAA19412@kohala.kohala.com> Date: Wed, 18 Mar 1998 01:16:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, an int * argument is fine... I agree we should fix this... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 17 22:47:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id WAA05654 for ipng-dist; Tue, 17 Mar 1998 22:42:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id WAA05647 for ; Tue, 17 Mar 1998 22:42:20 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA26070 for ; Tue, 17 Mar 1998 22:42:18 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA12522 for ; Tue, 17 Mar 1998 22:42:19 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id BAA09331; Wed, 18 Mar 1998 01:42:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA23690; Wed, 18 Mar 1998 01:42:18 -0500 Message-Id: <199803180642.AA23690@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: Steve Soule , ipng@sunroof.eng.sun.com Subject: (IPng 5403) Re: Multicast Loopback in bsd-api-new-01 In-Reply-To: Your message of "Tue, 17 Mar 1998 17:54:35 MST." <199803180054.RAA19466@kohala.kohala.com> Date: Wed, 18 Mar 1998 01:42:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > IPV6_MULTICAST_LOOP >> > >> > Controls whether outgoing multicast packets sent should be >> > delivered back to the local application. A toggle. If the >> > option is set to 1, multicast packets are looped back. If it >> > is set to 0, they are not. Other option values return an | >> > error of EINVAL. >> >> It seems to me that this could mean at least three different things. >It was intended to mean the same as the IP_MULTICAST_LOOP option means >for IPv4. I agree that the above wording could be better. Yep.. >How about the following, "borrowed" somewhat from Steve Deering's 1989 >writeup: >IPV6_MULTICAST_LOOP > > If a multicast datagram is sent to a group to which the sending host > itself belongs (on the outgoing interface), a copy of the datagram is > looped back by the IP layer for local delivery if this option is set > to 1. If this option is set to 0 a copy is not looped back. Other > option values return an error of EINVAL. Fine for me. >I also just realized that we do not specify any defaults for these three >output multicast socket options. Should we explicitly say >- if IPV6_MULTICAST_IF is not set, the kernel chooses the outgoing >> interface, Yep. >- if IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 > today), and Don't really need this with scopes in IPv6. I think the multicast packet should exhaust the scope on the network. I am assuming above a robust IPv6 Multicast capability in routing protcols will happen --------------).............. I actually think this is an appendix from IPv4 we don't need anymore? >- if IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same > as IPv4 today). I would like to see default be clear. Don't loopback by default. It serves no purpose and takes up time, space, and cycles in an implementation. I could also see this going away completely too. If the sender wants the packet join the multicast group? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 18 00:08:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id AAA05946 for ipng-dist; Wed, 18 Mar 1998 00:03:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id AAA05939 for ; Wed, 18 Mar 1998 00:03:43 -0800 (PST) From: ishida@kansai.oki.co.jp Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA03549 for ; Wed, 18 Mar 1998 00:03:41 -0800 Received: from sim.potato.kansai.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA13827 for ; Wed, 18 Mar 1998 00:03:41 -0800 (PST) Received: from cmas.potato.kansai.oki.co.jp (cmas.potato.kansai.oki.co.jp [10.173.7.38]) by sim.potato.kansai.oki.co.jp (8.8.7/3.5Wpl7) with SMTP id RAA00493 for ; Wed, 18 Mar 1998 17:03:38 +0900 (JST) Message-Id: <199803180803.RAA00493@sim.potato.kansai.oki.co.jp> X-Sender: ishida@sim.potato.kansai.oki.co.jp X-Mailer: Windows Eudora Pro Version 2.2-J (32) Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Wed, 18 Mar 1998 05:01:28 +0900 To: ipng@sunroof.eng.sun.com Subject: (IPng 5404) Question of flow label in IPng Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All, I just started studying the IPng subject, so I hope my questions are not too trivial. (1) I think that the label switching on a network layer by using a flow label is interesting. Is the label switching by a flow label possible? (2)What range is a flow label unique in? It is unique in a port, or a router, or a domain, ...........? (3) Are there any documents or informations about IPng over Sonet/SDH? Regards, --------------------------- Hiroshi ISHIDA Kansai Laboratory Oki Electric Industry Co., Ltd. Email: ishida@kansai.oki.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 18 09:22:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA06550 for ipng-dist; Wed, 18 Mar 1998 09:17:04 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA06543 for ; Wed, 18 Mar 1998 09:16:59 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA05079 for ; Wed, 18 Mar 1998 09:16:57 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02324; Wed, 18 Mar 1998 09:15:45 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id UAA05317 for ; Tue, 17 Mar 1998 20:31:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA13611; Tue, 17 Mar 1998 20:31:57 -0800 Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA26169; Tue, 17 Mar 1998 20:31:58 -0800 (PST) Received: from mg137-081.ricochet.net (mg137-081.ricochet.net [204.179.137.81]) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id UAA22850; Tue, 17 Mar 1998 20:30:19 -0800 (PST) Message-Id: <3.0.5.16.19980317201148.1147ba04@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Tue, 17 Mar 1998 20:11:48 To: Erik Nordmark From: Ross Finlayson Subject: (IPng 5405) Re: Multicast Loopback in bsd-api-new-01 Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <199803171344.FAA19949@saturn.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:58 PM 3/17/98 -0800, Erik Nordmark wrote: ... >> 3. Any sockets on the sending machine. ... > >And I would argue that the correct description based on what >IP_MULTICAST_LOOP does in IPv4 is (3). While on the subject of loop-back: I would like to have the option of choosing between *two* slightly different forms of loopback: 1/ Loop back to all sockets, including the sending socket. (This is the current behavior in IPv4, and presumably (judging by Erik's response) in IPv6 as well.) 2/ Loop back to all sockets, *except* the sending socket. Option 2/ would be useful for those applications (IMHO, the majority of multicast applications) that would prefer not to receive their own outgoing multicast packets, but that want to make these packets available to other applications on the same node - e.g., applications that do monitoring, transcoding, and/or relaying. Is it too late to push for both kinds of loop-back in the IPv6 sockets API? Ross. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 18 16:01:33 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id PAA07229 for ipng-dist; Wed, 18 Mar 1998 15:55:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id PAA07222 for ; Wed, 18 Mar 1998 15:54:56 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id PAA18668; Wed, 18 Mar 1998 15:54:51 -0800 (PST) Date: Wed, 18 Mar 1998 15:54:48 -0800 (PST) From: Erik & Reply-To: Erik & Subject: (IPng 5406) Re: Multicast Loopback in bsd-api-new-01 To: bound@zk3.dec.com Cc: "W. Richard Stevens" , Steve Soule , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803180642.AA23690@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >- if IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 > > today), and > > Don't really need this with scopes in IPv6. I think the multicast > packet should exhaust the scope on the network. To reduce the probability of "programmer forgetfulness" causing unneeded network bandwidth consumption I think it makes sense to keep the default 1 in IPv6 as in IPv4. Thus the programmer needs to explicitly set the value to a larger value before the application starts sending video all over the site (assuming the programmer has decided to use site scope multicast addresses). > >- if IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same > > as IPv4 today). > > I would like to see default be clear. Don't loopback by default. > It serves no purpose and takes up time, space, and cycles in an > implementation. Why should the default be different than in IPv4? It would mean one extra thing to explain to the folks that are porting applications to IPv6. > I could also see this going away completely too. If the sender wants > the packet join the multicast group? It still has to join the group (in v4 and v6). The IP{,V6}_MULTICAST_LOOP flag is there e.g. for the applications that use a multicast group to communicate but where the sender doesn't want to see the packets it has sent to the group. I'd agree with Ross that the above might not be very useful unless the application knows that it is the only application on that node that is using the multicast group and UDP port. However, I don't know if that is a strong enough reason to make the IPv6 API slightly different than IPv4 API. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 18 20:37:42 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id UAA07497 for ipng-dist; Wed, 18 Mar 1998 20:34:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id UAA07490 for ; Wed, 18 Mar 1998 20:33:46 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA26560; Wed, 18 Mar 1998 20:33:46 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA03335; Wed, 18 Mar 1998 20:33:45 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id XAA20060; Wed, 18 Mar 1998 23:33:44 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA05530; Wed, 18 Mar 1998 23:33:43 -0500 Message-Id: <199803190433.AA05530@wasted.zk3.dec.com> To: Erik & Cc: bound@zk3.dec.com, "W. Richard Stevens" , Steve Soule , ipng@sunroof.eng.sun.com Subject: (IPng 5407) Re: Multicast Loopback in bsd-api-new-01 In-Reply-To: Your message of "Wed, 18 Mar 1998 15:54:48 PST." Date: Wed, 18 Mar 1998 23:33:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >> >- if IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 >> > today), and >> >> Don't really need this with scopes in IPv6. I think the multicast >> packet should exhaust the scope on the network. >To reduce the probability of "programmer forgetfulness" causing >unneeded network bandwidth consumption I think it makes sense >to keep the default 1 in IPv6 as in IPv4. >Thus the programmer needs to explicitly set the value to a larger >value before the application starts sending video all over the site >(assuming the programmer has decided to use site scope multicast >addresses). Ohhh OK... Feels like a security blanket though and as you know I like flying free with lots of risk --------------)...... But if the scope is site-local and hop-count is 1; why would not hop-count be ignored? I am (probably wrongly) that IPv6 multicast routing will ignore hop count and use our multicast scopes? If this is not the case then how does one know if the packet reached all nodes within that scope? So does it really matter to set the hop-count with scope? >> >- if IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same >> > as IPv4 today). >> >> I would like to see default be clear. Don't loopback by default. >> It serves no purpose and takes up time, space, and cycles in an >> implementation. >Why should the default be different than in IPv4? I thought this was wrong in IPv4. >It would mean one extra thing to explain to the folks that are porting >applications to IPv6. Got me there and it is an argument I would use too. But I thought it was wrong before and why bring that forward. No big deal I will go with consensus here, I am not fighting this one. Seems like a waste to me. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 18 22:03:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id VAA07633 for ipng-dist; Wed, 18 Mar 1998 21:57:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id VAA07626 for ; Wed, 18 Mar 1998 21:57:30 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA05961 for ; Wed, 18 Mar 1998 21:57:29 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id VAA04908 for ; Wed, 18 Mar 1998 21:57:29 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id AAA21043 for ; Thu, 19 Mar 1998 00:57:28 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07691; Thu, 19 Mar 1998 00:57:28 -0500 Message-Id: <199803190557.AA07691@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5408) DST OPTIONS Date: Thu, 19 Mar 1998 00:57:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can vendors request DST option codes for vendor specific extensions? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 04:30:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id EAA07852 for ipng-dist; Thu, 19 Mar 1998 04:24:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id EAA07845 for ; Thu, 19 Mar 1998 04:24:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA09053 for ; Thu, 19 Mar 1998 04:23:59 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA21202 for ; Thu, 19 Mar 1998 04:23:58 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id FAA17585; Thu, 19 Mar 1998 05:23:52 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id FAA22922; Thu, 19 Mar 1998 05:23:51 -0700 (MST) Message-Id: <199803191223.FAA22922@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 19 Mar 1998 05:23:51 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Ross Finlayson , bound@zk3.dec.com Subject: (IPng 5410) Re: Multicast Loopback in bsd-api-new-01 Cc: Steve Soule , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Mar 18, 10:37pm you write:] > > (However, as I noted in my last message, I would like the option of being > able to loop back to every socket *except* the sending socket (& have > *this* be the default behavior).) Wouldn't this be a pain to implement? The loopback occurs at the IP layer, with knowledge only of whether the host belongs to the group and whether the loopback option is set. BSD implementations then just put the packet onto the IP input queue and then UDP will eventually demultiplex the packet accordingly. Seems like you would have to add a flag to the packet somewhere telling UDP not to give this packet to the sending socket, and remember the sending socket. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 06:42:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA08066 for ipng-dist; Thu, 19 Mar 1998 06:33:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA08059 for ; Thu, 19 Mar 1998 06:33:41 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA22810 for ; Thu, 19 Mar 1998 06:33:33 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA15608 for ; Thu, 19 Mar 1998 06:33:33 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id JAA23243; Thu, 19 Mar 1998 09:33:30 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30732; Thu, 19 Mar 1998 09:33:08 -0500 Message-Id: <199803191433.AA30732@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: Ross Finlayson , bound@zk3.dec.com, Steve Soule , ipng@sunroof.eng.sun.com Subject: (IPng 5411) Re: Multicast Loopback in bsd-api-new-01 In-Reply-To: Your message of "Thu, 19 Mar 1998 05:23:51 MST." <199803191223.FAA22922@kohala.kohala.com> Date: Thu, 19 Mar 1998 09:33:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >Wouldn't this be a pain to implement? The loopback occurs at the IP >layer, with knowledge only of whether the host belongs to the group >and whether the loopback option is set. BSD implementations then just >put the packet onto the IP input queue and then UDP will eventually >demultiplex the packet accordingly. Seems like you would have to add >a flag to the packet somewhere telling UDP not to give this packet to >the sending socket, and remember the sending socket. Good point Rich. I think this is not worthwhile for our spec. Could be an API future spec and its own draft. It would have to deal with all these issues too. We want this to go to last call and be done I can't see holding up the conclusion of the base API spec for this feature. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 07:23:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id HAA08148 for ipng-dist; Thu, 19 Mar 1998 07:16:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id HAA08141 for ; Thu, 19 Mar 1998 07:16:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA04393 for ; Thu, 19 Mar 1998 07:16:32 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA08215 for ; Thu, 19 Mar 1998 07:15:07 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16023; Thu, 19 Mar 1998 10:15:01 -0500 (EST) Message-Id: <199803191515.KAA16023@ns.ietf.org> 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@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5412) I-D ACTION:draft-ietf-ipngwg-esd-analysis-02.txt Date: Thu, 19 Mar 1998 10:15:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 Author(s) : L. Zhang, A. Mankin, J. Stewart, T. Narten, M. Crawford Filename : draft-ietf-ipngwg-esd-analysis-02.txt Pages : 47 Date : 18-Mar-98 On February 27-28, 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's ''GSE - An Alternate Addressing Architecture for IPv6'' proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into distinct portions for global routing, local routing and end-point identification. GSE includes the feature of configuring a node internal to a site with only the local routing and end-point identfication portions of the address, thus hiding the full address from the node. When such a node generates a packet, only the low-order bytes of the source address are specified; the high-order bytes of the address are filled in by a border router when the packet leaves the site. There is a long history of a vague assertion in certain circles that IPv4 ''got it wrong'' by treating its addresses simultaneously as locators and identifiers. Despite these claims, however, there was never a complete proposal for a scaleable network protocol which separated the functions. As a result, it wasn't possible to do a serious analysis comparing and contrasting a ''separated'' architecture and an ''overloaded'' architecture. The GSE proposal serves as a vehicle for just such an analysis, and that is the purpose of this paper. We conclude that an architecture that clearly separates locators and indentifiers in addresses introduces new issues and problems that do not have an easy or clear solution. Indeed, the alleged disadvantages of overloading addresses turn out to provide some significant benefits over the non-overloaded approach. 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-ietf-ipngwg-esd-analysis-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-02.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <19980318113732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-esd-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980318113732.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 08:13:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA08317 for ipng-dist; Thu, 19 Mar 1998 08:05:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA08310 for ; Thu, 19 Mar 1998 08:05:26 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA19315 for ; Thu, 19 Mar 1998 08:05:12 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA17673 for ; Thu, 19 Mar 1998 08:05:11 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA18324; Thu, 19 Mar 98 08:02:09 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id IAA11927; Thu, 19 Mar 1998 08:06:32 -0800 Date: Thu, 19 Mar 1998 08:06:32 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803191606.IAA11927@feller.mentat.com> To: bound@zk3.dec.com, rstevens@kohala.com Subject: (IPng 5413) Re: Multicast Loopback in bsd-api-new-01 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, Jim, > > >Wouldn't this be a pain to implement? The loopback occurs at the IP > >layer, with knowledge only of whether the host belongs to the group > >and whether the loopback option is set. BSD implementations then just > >put the packet onto the IP input queue and then UDP will eventually > >demultiplex the packet accordingly. Seems like you would have to add > >a flag to the packet somewhere telling UDP not to give this packet to > >the sending socket, and remember the sending socket. > > Good point Rich. I think this is not worthwhile for our spec. Could be > an API future spec and its own draft. It would have to deal with all > these issues too. We want this to go to last call and be done I can't > see holding up the conclusion of the base API spec for this feature. > I am with you guys. The implementation details of the current definition of IP[V6]_MULTICAST_LOOP are enough of a pain. We shouldn't try and add extra frills at this late date. Bad and tag this document so we can move on to reworking the Advanced API document. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 08:31:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA08360 for ipng-dist; Thu, 19 Mar 1998 08:22:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA08353 for ; Thu, 19 Mar 1998 08:22:31 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA23991 for ; Thu, 19 Mar 1998 08:22:28 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA13202 for ; Thu, 19 Mar 1998 08:19:19 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id LAA25281; Thu, 19 Mar 1998 11:18:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09217; Thu, 19 Mar 1998 11:18:57 -0500 Message-Id: <199803191618.AA09217@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, rstevens@kohala.com, ipng@sunroof.eng.sun.com Subject: (IPng 5414) Re: Multicast Loopback in bsd-api-new-01 In-Reply-To: Your message of "Thu, 19 Mar 1998 08:06:32 PST." <199803191606.IAA11927@feller.mentat.com> Date: Thu, 19 Mar 1998 11:18:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk tim.. thanks I agree. I did the code for the multicast that was a bit of work and took thought to put it in and not break ipv4 thingees in the kernel part. it would get real messy as Richard stated. yes the adv api should be our next heavy work effort on the api and I think and know of some ISVs now that want to use the advapi for "advanced" stuff on our platforms with IPv6...in additon to its use for vendor platforms to do IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 09:15:10 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA08497 for ipng-dist; Thu, 19 Mar 1998 09:08:33 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA08490 for ; Thu, 19 Mar 1998 09:08:28 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA17574 for ; Thu, 19 Mar 1998 09:08:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA02254 for ipng@sunroof.eng.sun.com; Thu, 19 Mar 1998 09:08:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id WAA07688 for ; Wed, 18 Mar 1998 22:46:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA10510 for ; Wed, 18 Mar 1998 22:46:43 -0800 Received: from proxy3.ba.best.com (proxy3.ba.best.com [206.184.139.14]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA23018 for ; Wed, 18 Mar 1998 22:46:40 -0800 (PST) Received: from mg139-003.ricochet.net (mg139-003.ricochet.net [204.179.139.3]) by proxy3.ba.best.com (8.8.8/8.8.BEST) with SMTP id WAA12683; Wed, 18 Mar 1998 22:43:55 -0800 (PST) Message-Id: <3.0.5.16.19980318223704.37b771f2@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Wed, 18 Mar 1998 22:37:04 To: bound@zk3.dec.com From: Ross Finlayson Subject: (IPng 5416) Re: Multicast Loopback in bsd-api-new-01 Cc: "W. Richard Stevens" , Steve Soule , ipng@sunroof.eng.sun.com In-Reply-To: <199803180642.AA23690@wasted.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>- if IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same >> as IPv4 today). > >I would like to see default be clear. Don't loopback by default. >It serves no purpose and takes up time, space, and cycles in an >implementation. I disagree. Multicast loopback is useful if you want to have monitoring, tunneling, transcoding, etc., applications running on the same node. In general, an application writer can't be sure that there won't be some other processes, running on the same node, that will need to receive copies of outgoing multicasts. That's why loopback should be ON by default. (However, as I noted in my last message, I would like the option of being able to loop back to every socket *except* the sending socket (& have *this* be the default behavior).) Ross. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 09:51:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA08657 for ipng-dist; Thu, 19 Mar 1998 09:43:56 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA08650 for ; Thu, 19 Mar 1998 09:43:50 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA24324 for ; Thu, 19 Mar 1998 09:43:49 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA02364 for ipng@sunroof.eng.sun.com; Thu, 19 Mar 1998 09:43:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA08411 for ; Thu, 19 Mar 1998 08:38:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28168; Thu, 19 Mar 1998 08:38:36 -0800 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA22871; Thu, 19 Mar 1998 08:37:36 -0800 (PST) Message-Id: <199803191637.IAA22871@saturn.sun.com> Received: from gauss (LOCALHOST) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA257115370; Thu, 19 Mar 1998 11:36:10 -0500 To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, finlayson@lvn.com, bound@zk3.dec.com, Erik.Nordmark@Eng Subject: (IPng 5417) Re: Multicast Loopback in bsd-api-new-01 In-Reply-To: Your message of "Tue, 17 Mar 1998 17:54:35 EST." <199803180054.RAA19466@kohala.kohala.com> Date: Thu, 19 Mar 1998 11:36:09 -0500 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that the best thing to do is have IP_MULTICAST_LOOP only control looping back to the socket that sent the packet. I don't think a process should have any control over whether other processes on the machine receive the multicast packets it sends. They should always receive the packets, whether the sending process wants them to or not. So I would suggest the following description for the IP_MULTICAST_LOOP option in draft-ietf-ipngwg-bsd-api-new: IPV6_MULTICAST_LOOP Controls whether outgoing multicast packets sent should be delivered back to the socket that sent them. A toggle. If the option is set to 1, multicast packets are looped back. If it is set to 0, they are not. Other option values return an error of EINVAL. This option is set to 1 by default. Other sockets on the machine that are members of the multicast group a packet is being sent to (and satisfy any other conditions necessary for receiving the packet, such as being bound to a particular UDP port) receive that packet regardless of how this option is set. This option only controls loopback to the sending socket itself. Of course, if the sending socket is not a member of the multicast group (or is not listening on the appropriate port), it will not receive a copy of any packet it sends to that multicast group even if this option is set to 1. In message <199803180054.RAA19466@kohala.kohala.com>, W. Richard Stevens writes : > It was intended to mean the same as the IP_MULTICAST_LOOP option means > for IPv4. I agree that the above wording could be better. It's been a couple of years since I wrote a program that used multicast, but I clearly remember having the same confusion then. I had to experiment to find out how this option worked (this was on Solaris 2.5). I don't remember clearly what I found out, but it was one of the following two possibilities: 1. The option only controlled loopback to the sending socket; all other sockets received the packets regardless. This matches my preference stated above. 2. The option controlled loopback to the sending machine. In order to make my program work properly with other programs on the machine, I had to leave the loopback option on, and carefully throw out received packets that matched ones I had sent. Erik Nordmark wrote: > And I would argue that the correct description based on what > IP_MULTICAST_LOOP does in IPv4 is (3). Though that may be what the IPv4 multicast specification says, is that what the implementations do? > Additionally I'd suspect that in many implementations the protocol > stack does not know what processes have what sockets open - this > is particularly true for implementations that allow sockets to be > shared between different processes (for example, fork() in Unix). So it sounds like (2) would not be a workable possibility. Jim Bound wrote: > >- if IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 > > today), and > > Don't really need this with scopes in IPv6. I think the multicast > packet should exhaust the scope on the network. > ... > I actually think this is an appendix from IPv4 we don't need anymore? I agree in principle. Since the purpose of the hop limit in IPv4 multicast was to specify the scope, and multicast scope is part of the address in IPv6, setting the hop limit for multicast packets should be of no more concern for IPv6 applications than setting the hop limit for unicast packets. Perhaps this option should be absorbed into the corresponding unicast option. That way outgoing packets would have the default hop limit unless specifically overridden by the application for all packets leaving on the socket. Ross Finlayson wrote: > While on the subject of loop-back: I would like to have the option of > choosing between *two* slightly different forms of loopback: > 1/ Loop back to all sockets, including the sending socket. (This is the > current behavior in IPv4, and presumably (judging by Erik's response) in > IPv6 as well.) > 2/ Loop back to all sockets, *except* the sending socket. > > Option 2/ would be useful for those applications (IMHO, the majority of > multicast applications) that would prefer not to receive their own outgoing > multicast packets, but that want to make these packets available to other > applications on the same node - e.g., applications that do monitoring, > transcoding, and/or relaying. I agree that option 2 is useful. I see no need for option 1 at all. In fact, as I said above, I don't think applications should be able to control whether packets loop back to other sockets. Erik Nordmark wrote: > > Don't really need this with scopes in IPv6. I think the multicast > > packet should exhaust the scope on the network. > > To reduce the probability of "programmer forgetfulness" causing > unneeded network bandwidth consumption I think it makes sense > to keep the default 1 in IPv6 as in IPv4. > Thus the programmer needs to explicitly set the value to a larger > value before the application starts sending video all over the site > (assuming the programmer has decided to use site scope multicast > addresses). I don't think programs should have to mess with the hop limit by default. I think that by default, it should be set to the machine's default hop limit. Suppose, for example, that I write an IPv6 multicast program today, and guess that 32 is a good hop limit for reaching the whole Internet. Suppose that ten years from now, a hop limit of 32 would not be sufficient for reaching the majority of nodes. The machine on which my program is running may very well know this, and have a higher hop limit set. But if my program overrides this with the value 32, my program won't work right. Jim Bound wrote: > But if the scope is site-local and hop-count is 1; why would not > hop-count be ignored? > > I am (probably wrongly) that IPv6 multicast routing will ignore hop > count and use our multicast scopes? If this is not the case then how > does one know if the packet reached all nodes within that scope? Perhaps I'm misunderstanding you. I don't think hop limit should ever be ignored by routers, since it protects against packets wandering around the Internet forever. rstevens@kohala.com (W. Richard Stevens) wrote: > > (However, as I noted in my last message, I would like the option of being > > able to loop back to every socket *except* the sending socket (& have > > *this* be the default behavior).) > > Wouldn't this be a pain to implement? The loopback occurs at the IP > layer, with knowledge only of whether the host belongs to the group > and whether the loopback option is set. BSD implementations then just > put the packet onto the IP input queue and then UDP will eventually > demultiplex the packet accordingly. Seems like you would have to add > a flag to the packet somewhere telling UDP not to give this packet to > the sending socket, and remember the sending socket. If this is so, then I would favor removing the IPV6_MULTICAST_LOOP option altogether. I don't think an application should be able to control loopback to any sockets but its own. If the consensus is that the IPV6_MULTICAST_LOOP option should control loopback to the sending machine, and not just the sending socket, then I suggest that wording similar to the following be added to draft-ietf-ipngwg-bsd-api-new: Since this option controls loopback to the sending machine, an application should not set it to 0 unless it has reason to believe that no other process on the machine wants to receive the multicast packets it sends. Since it is unlikely that a program would know this, a decision to use this option should be made with great care--convenience is not sufficient reason. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 19 11:48:22 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA08952 for ipng-dist; Thu, 19 Mar 1998 11:44:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA08945 for ; Thu, 19 Mar 1998 11:44:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA25958 for ; Thu, 19 Mar 1998 11:43:56 -0800 Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA25843 for ; Thu, 19 Mar 1998 11:42:26 -0800 (PST) Received: from localhost by ux6.sp.cs.cmu.edu id aa05466; 19 Mar 98 14:40 EST To: Peter Curran Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Tue, 17 Mar 1998 09:47:18 GMT" <199803170944.JAA01747@gate.ticl.co.uk> From: Dave Johnson Reply-To: Dave Johnson Subject: (IPng 5418) Re: New version of Mobile IPv6 draft submitted Date: Thu, 19 Mar 1998 14:40:40 -0500 Message-ID: <5463.890336440@ux6.sp.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Dave > >I haven't been keeping up with this as well as I should. Can you tell me >if mobile IPv6 still requires that all implementations support the mobile >bindings cache, as was previously proposed. I remember that this cause >some controversy at the time and wondered if it had ever been resolved? > > >Peter >TICL Peter, The complete MAY/SHOULD/MUST requirements for Mobile IPv6 are specified in Section 7 of the draft (draft-ietf-mobileip-ipv6-05.txt). In the case of the Binding Cache, we have - Every IPv6 node SHOULD be able to process a Binding Update option received in a packet, and to return a Binding Acknowledgement option if requested. - Every IPv6 node SHOULD be able to maintain a Binding Cache of the bindings received in accepted Binding Updates. The only MUST requirement that applies to ALL IPv6 nodes is - Every IPv6 node MUST be able to process a Home Address option received in a packet. Note that this requirement applies to ALL IPv6 nodes, whether host or router, whether mobile or stationary. This is required in order to receive a packet sent by a mobile node while the sender is away from home. Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 21 21:27:21 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id VAA11531 for ipng-dist; Sat, 21 Mar 1998 21:23:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id VAA11524 for ; Sat, 21 Mar 1998 21:23:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA07920 for ; Sat, 21 Mar 1998 21:23:16 -0800 Received: from vsnl-relay.iucaa.ernet.in (vsnl-relay.iucaa.ernet.in [202.141.155.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id VAA14504 for ; Sat, 21 Mar 1998 21:23:14 -0800 (PST) Received: by vsnl-relay.iucaa.ernet.in; id AA14059; Sun, 22 Mar 1998 10:53:26 +0500 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id KAA19213; Sun, 22 Mar 1998 10:51:05 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA06117; Sun, 22 Mar 98 10:51:05+0530 Date: Sun, 22 Mar 1998 10:47:22 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5419) IPv6 Jumbo Payload Option. To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All Can any one please tell me what is the maximum packet size that can be transmitted using the Jumbo payload option.( using the present transmission technologies ). Are there any documents discussing the issues realted to routing table size isssues with the emergence of IPv6. With Regards -Raghu. I.I.Sc. Bangalore INDIA. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 22 02:20:54 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id CAA11668 for ipng-dist; Sun, 22 Mar 1998 02:17:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id CAA11661 for ; Sun, 22 Mar 1998 02:17:08 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA20478 for ; Sun, 22 Mar 1998 02:17:07 -0800 Received: from vsnl-relay.iucaa.ernet.in (vsnl-relay.iucaa.ernet.in [202.141.155.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id CAA21494 for ; Sun, 22 Mar 1998 02:17:04 -0800 (PST) Received: by vsnl-relay.iucaa.ernet.in; id AA19329; Sun, 22 Mar 1998 15:47:39 +0500 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id PAA05713; Sun, 22 Mar 1998 15:46:45 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA04258; Sun, 22 Mar 98 15:46:45+0530 Date: Sun, 22 Mar 1998 15:44:22 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5420) IPVv6 Addressing Architecture. To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All Can anybody please tell what is special meaning of "site address" and "link address" in the context of IPv6 context. With Regards -Raghu I.I.Sc. BANGALORE. INDIA. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 22 04:16:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id EAA11775 for ipng-dist; Sun, 22 Mar 1998 04:12:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id EAA11768 for ; Sun, 22 Mar 1998 04:12:40 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA23946 for ; Sun, 22 Mar 1998 04:12:37 -0800 Received: from seralph22.essex.ac.uk (seralph22.essex.ac.uk [155.245.240.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id EAA15764 for ; Sun, 22 Mar 1998 04:12:36 -0800 (PST) Received: by seralph22.essex.ac.uk; id AA15290; Sun, 22 Mar 1998 12:12:21 GMT Message-Id: <9803221212.AA15290@seralph22.essex.ac.uk> Received: from th7-4(155.245.117.52) by seralph22.essex.ac.uk via smap (V2.0beta) id xma023149; Sun, 22 Mar 98 12:11:36 GMT Reply-To: From: "Y K Tan" To: Subject: (IPng 5421) IPv6 Simulation~~ Date: Sun, 22 Mar 1998 12:15:43 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All, Does anyone know any existing program which could simulate how IPv6 and mobile IP work? Thank you and best regards. Yours sincerely, Ken Tan Toshiba Singapore -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 23 04:17:02 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id EAA12779 for ipng-dist; Mon, 23 Mar 1998 04:13:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id EAA12772 for ; Mon, 23 Mar 1998 04:13:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA28066 for ; Mon, 23 Mar 1998 04:13:02 -0800 Received: from mti6000.zfm.com (mti6000.zfm.com [206.0.67.254]) by earth.sun.com (8.8.8/8.8.8) with SMTP id EAA15503 for ; Mon, 23 Mar 1998 04:13:01 -0800 (PST) Received: from mtint.zfm.com by mti6000.zfm.com with smtp (Smail3.1.28.1 #4) id m0yH5tY-0004LYC; Mon, 23 Mar 98 09:00 GRNLNDST Received: by MTINT with Internet Mail Service (5.0.1458.49) id ; Mon, 23 Mar 1998 09:12:12 -0300 Message-ID: <5D4FD0036882D011A9400060940A770D0364FD@MTINT> From: Alberto Abudara To: "'ipng@sunroof.eng.sun.com.'" Date: Mon, 23 Mar 1998 09:12:11 -0300 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I need to download a free or evaluation version of IPv6 implementation from the Web . I've only found a Linux implementation. Is there any other ( other O.S ) anywhere. ? Thank you. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 23 08:39:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA13155 for ipng-dist; Mon, 23 Mar 1998 08:34:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA13148 for ; Mon, 23 Mar 1998 08:34:29 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA09344 for ; Mon, 23 Mar 1998 08:34:27 -0800 Received: from mti6000.zfm.com (mti6000.zfm.com [206.0.67.254]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA20461 for ; Mon, 23 Mar 1998 08:34:25 -0800 (PST) Received: from mtint.zfm.com by mti6000.zfm.com with smtp (Smail3.1.28.1 #4) id m0yH9ye-0004LYC; Mon, 23 Mar 98 13:21 GRNLNDST Received: by MTINT with Internet Mail Service (5.0.1458.49) id ; Mon, 23 Mar 1998 13:33:45 -0300 Message-ID: <5D4FD0036882D011A9400060940A770D036500@MTINT> From: Alberto Abudara To: "'ipng@sunroof.eng.sun.com.'" Subject: (IPng 5423) IPv6 implementations Date: Mon, 23 Mar 1998 13:33:44 -0300 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for your answers. I knew that page. I am interested in the Novell version but I send mails to the address mentioned there and I've received no answer. Has anyone got the Novell version ? Regards, Alberto -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 23 11:46:02 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA13425 for ipng-dist; Mon, 23 Mar 1998 11:38:33 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id LAA13418 for ; Mon, 23 Mar 1998 11:38:26 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id LAA17863 for ; Mon, 23 Mar 1998 11:38:25 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id LAA07188 for ipng@sunroof.eng.sun.com; Mon, 23 Mar 1998 11:38:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA13406 for ; Mon, 23 Mar 1998 11:36:34 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA07458 for ; Mon, 23 Mar 1998 11:36:22 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA20557 for ; Mon, 23 Mar 1998 11:36:19 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA24568; Mon, 23 Mar 1998 14:36:07 -0500 (EST) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03932; Mon, 23 Mar 1998 14:34:07 -0500 Date: Mon, 23 Mar 1998 14:34:07 -0500 From: Jack McCann Message-Id: <199803231934.AA03932@wasted.zk3.dec.com> To: crawdad@fnal.gov, hinden@ipsilon.com Subject: (IPng 5425) Re: Router Renumbering Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Bob, Please find attached some comments on draft-ietf-ipngwg-router-renum-03.txt, Router Renumbering for IPv6. This is a compilation of comments received from several members of the DIGITAL UNIX IPv6 team: Jim Bound, Mary Clouter, Gerri Harter, Jack McCann, Yanick Pouffary, Ken Powell, Ravi Shankar, Sowmini Varadhan, and Eric Wong. - A table of contents would be helpful. - Section 2 typo "If subnetting information is in the same portion of of the" ^^^^^ - Section 2 makes statements regarding idempotency of an "elementary RR operation", and the potential non-idempotency of combinations of "elementary RR operations". We were discussing the idempotency issue when we realized there were differing views of what constitutes an "elementary RR operation". Please define "elementary RR operation", preferably before the statements regarding their idempotency properties. - Section 2 "All RR packets which have a Sequence Number equal to the highest value seen (for each valid key), and which pass the authentication check, are equally valid and must be processed." Packets with sequence number "greater than" are also valid, why are these not included in this statement? - Section 2 talks about why we have segment numbers. Do segment numbers have to be processed in order? (e.g. segment number 3 arrives before segment numbers 1 and 2, do I wait for segments 1 and 2 before processing segment 3?) A statement somewhere about processing order for segment numbers would help. - Section 3.1 "Prefix Control Operation, Match-Prefix, Use-Prefix These are defined section 2." Explicit definitions of these important terms in this section (as opposed to referring back to section 2) would be helpful. - Section 3.1 "Matched Prefix The existing prefix or address which matched a Match-Prefix. New Prefix A prefix constructed from a Use-Prefix, possibly including some of the Matched-Prefix." Should the definition of "Matched Prefix" be "Matched-Prefix", or should the definition of "New Prefix" use the term "Matched Prefix"? (And if you change the definition to "Matched-Prefix" there are several instances of "Matched Prefix" that might also have to change.) - Section 3.1 The term "Matched Prefix" includes both prefixes and addresses. Some thought that explicitly defining and using the term "Matched Address" might be more clear. - Section 3.1 "Note that "matches" is a transitive relation but not reflexive. If two prefixes match each other, they are identical." We agreed that "matches" is transitive, but think it is reflexive and is not symetric (it looks antisymetric). (After spending some time discussing this we wondered was it really necessary to make that statement in this spec, the properties of the matches relation are not referred to other than in this one note.) - Section 4.1 "S This flag MUST be ignored unless the router treats interfaces as belonging to different "sites"." Please define "site". - Section 4.1 "If the destination address is appropriate for interfaces belonging to more than one site, Is this to catch the case of multicast destination address with scope greater than "site-local"? Are there any other cases to consider? - Section 4.1 "SequenceNumber An unsigned 32-bit sequence number. The sequence number MUST be non-decreasing for all messages sent with the same KeyID." Can the same sequence number be reused with the same KeyID provided the KeyID has expired and been reused? Or asked another way, is my router renumbering implementation allowed to forget about sequence numbers associated with a given KeyID when that KeyID expires? - Section 4.2.1.2 Use-Prefix Part Do we really need a separate KeepLen field? Can't it be derived from the Interface ID length as specified in a given "IPv6 over foo" spec? If you keep KeepLen shouldn't there be a validity check such as: (UseLen + KeepLen) == (128 - Interface_ID_length) KeepLen may also be a problem if we ever have Interface_ID_length not equal to 64 bits for some link type X, but is 64 bits for some other link type Y, and the router has both type X and Y links: KeepLen would need to be different depending on the link type, which means whoever creates the RR command would need to know in advance what link types were on the router. - Section 4.2.1.2 Use-Prefix Part We thought a more detailed explanation of how the Valid and Preferred lifetimes and the P and V bits relate back to ND and SAA would be helpful, e.g. by describing the "Router Configuration Variables" [ND] affected by the operation (e.g. AdvPrefixList, AdvValidLifetime, AdvOnLinkFlag, AdvPreferredLifetime, AdvAutonomousFlag). As an aside, it would be helpful in this instance for ND to define "Router Configuration Variable" names to associate with the P and V flags. - Section 4.2.1.2 Use-Prefix Part "UsePrefix The 128-bit Use-prefix which either becomes or is used in forming (if KeepLen is nonzero) the New Prefix. It MUST NOT have the form of a multicast or link-local address [AARCH]." Should we also prohibit loopback, IPv4-mapped, and IPv4-compatible? - Section 4.3. Message Body -- Result Message "MatchedLen The length of the existing prefix which was matched by the MatchPrefix." Can we replace "existing prefix which was matched by the MatchPrefix" with "Matched Prefix", i.e. "MatchedLen The length of the Matched Prefix." - Section 4.4.1. HMAC-MD5 These two statements are not specific to HMAC-MD5, and so should be stated as a generic rule prior to section 4.4.1: "Before generating the AuthData, all fields of the RR header and all the PCOs are filled in, except that the ICMPv6 checksum field is set to zero." "When checking the AuthData, the ICMPv6 checksum must be effectively set to zero." - Section 4.4.1. HMAC-MD5 "AuthLen will be 16 and AuthOffset will be equal to the length in octets of the RR message, not including the AuthData, the IPv6 header or any extension headers, but including the ICMPv6 header." Everything after "RR message" is already said at that start of section 4.4, you could just say: "AuthLen will be 16 and AuthOffset will be equal to the length in octets of the RR message body." - Section 5 Message Processing If we do decide that segments must be processed in order by increasing segment number value as opposed to order received, we'll need some additions in this section to handle that. - Section 5.1. Header Check You should also discard if ICMP checksum not valid, ICMP code not 0, ICMP length not feasable (as is done in ND spec). - Section 5.1. Header Check "Next, if the router is multi-sited, and the S flag is set and the destination address of the Command is appropriate for interfaces belonging to more than one site, but is not appropriate for the interface on which the Command was received, this is an error." Can you give an example of such a destination address, and clarify what you mean by "not appropriate"? - Section 5.1. Header Check "Finally, if the SequenceNumber in the message is greater than the Recorded Sequence Number or the T flag is not set, skip to the Authentication Check." Did you really mean to say "or the T flag is not set"? This means we skip to Authentication Check when the SequenceNumber in the message equal to the Recorded Sequence Number and the T flag is not set (i.e. skip the segment number check for different segments of the same non-test message). - Section 5.1. Header Check "body of that Result message MUST either be empty or be a saved copy" Why allow an empty Result message? - Section 5.2. Authentication Check "The authentication check is performed over the RR message, without any IPv6 or extension headers." Section 4.4 says IPv6 src/dst are included. Can you instead refer back to section 4.4 here (only say how to do the authentication check in one place to avoid conflicting definitions). - Section 5.3. Execution "If any such address does match M, process the PCO as if P matched M, but when forming New Prefixes, if KeepLen is non-zero, bits are copied from the address." See KeepLen issue mentioned above. - Section 5.3. Execution "A copy of the Result message MAY be saved to be retransmitted in response to a duplicate Command." If we disallow empty Result messages (see above), this "MAY" would change to "MUST". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 23 20:38:34 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id UAA14110 for ipng-dist; Mon, 23 Mar 1998 20:32:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id UAA14103 for ; Mon, 23 Mar 1998 20:32:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA14916 for ; Mon, 23 Mar 1998 20:32:48 -0800 Received: from vsnl-relay.iucaa.ernet.in (vsnl-relay.iucaa.ernet.in [202.141.155.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id UAA02428 for ; Mon, 23 Mar 1998 20:32:46 -0800 (PST) Received: by vsnl-relay.iucaa.ernet.in; id AA00994; Tue, 24 Mar 1998 10:03:58 +0500 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id KAA09280; Tue, 24 Mar 1998 10:02:32 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA08412; Tue, 24 Mar 98 10:02:31+0530 Date: Tue, 24 Mar 1998 09:52:36 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5426) IPv6 Route Alert Option. To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All I was reading the internet draft on IPv6 route alert option. Can anyone please answer my following questions. The main purpose of the Route alert option in IPv4 is to avoid the parsing the upper layer headers in the IPv4 packet. But IPv6 provides extension headers. If we want have IPv6 route alert option for the purpose of RSVP messages we have the extension headers in the order of -IPv6 header -Mod.Ho-by-Hop option header. -RSVP header ( In case of Raw IPv6 datagrams interface) else -UDP encapsulated RSVP messages. So why don't we use NEXT HEADER FIELD of the IPv6 header for identifying the "special packets". In case of UDP encapsulted message we can assign another PROTOCOL ID and identify the IPv6 for special processing, rather than parsing the IPv6 header, Modified Hop-by-Hop option header, and then RSVP header. I am new to IPNGWG and IPv6 specification. So if there any mistakes let me know. Thank you one and all With Regards -Raghu. I.I.Sc. Bangalore. INDIA. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 23 20:40:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id UAA14121 for ipng-dist; Mon, 23 Mar 1998 20:36:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id UAA14114 for ; Mon, 23 Mar 1998 20:36:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA15182 for ; Mon, 23 Mar 1998 20:36:01 -0800 Received: from vsnl-relay.iucaa.ernet.in (vsnl-relay.iucaa.ernet.in [202.141.155.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id UAA03469 for ; Mon, 23 Mar 1998 20:35:56 -0800 (PST) Received: by vsnl-relay.iucaa.ernet.in; id AA01173; Tue, 24 Mar 1998 10:07:03 +0500 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id KAA09443; Tue, 24 Mar 1998 10:05:32 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA08527; Tue, 24 Mar 98 10:05:31+0530 Date: Tue, 24 Mar 1998 10:03:14 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5427) IPv6 SITE Address To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All Is the "site" in the context of IPv6 specification related to Autonoumous system. With Regards -Raghu. I.I.Sc. Banglaore INDIA. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 06:27:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA14548 for ipng-dist; Tue, 24 Mar 1998 06:20:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA14541 for ; Tue, 24 Mar 1998 06:20:44 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA03364 for ; Tue, 24 Mar 1998 06:20:41 -0800 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA18858 for ; Tue, 24 Mar 1998 06:20:42 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA06363; Tue, 24 Mar 1998 14:22:47 GMT Received: from mailhome [192.153.166.5] by mailgate.rdg.opengroup.org via smtpd ; Tue Mar 24 14:22 GMT 1998 Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA27914; Tue, 24 Mar 1998 14:07:35 GMT Received: from unknown(192.153.166.111) by mailhome.rdg.opengroup.org via smap (V1.3) id sma027907; Tue Mar 24 14:07:24 1998 Message-Id: <3.0.3.32.19980324122628.007bd390@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 24 Mar 1998 12:26:28 +0000 To: gilligan@freegate.net, set@thumper.bellcore.com, bound@zk3.dec.com, rstevens@kohala.com From: Chris Harding Subject: (IPng 5428) Clarification of Basic Sockets API to IPv6 Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - I am framing a change to the Open Group networking services specification (XNS) based on the emerging IETF Basic IPv6 Socket Interface extensions. In reading the following two paragraphs of ftp://ietf.org/internet-drafts/draft-ietf-ipngwg-bsd-api-new-01.txt - > - If the AI_V4MAPPED flag is specified along with an af of | > AF_INET6, then the caller will accept IPv4-mapped IPv6 addresses. | > That is, if no AAAA records are found then a query is made for A | > records and any found are returned as IPv4-mapped IPv6 addresses | > (h_length will be 16). The AI_V4MAPPED flag is ignored unless af | > equals AF_INET6. > > - If the AI_ALL flag is specified along with an af of AF_INET6, | > then the caller wants all addresses: IPv6 and IPv4-mapped IPv6. | > A query is first made for AAAA records and if successful, the | > IPv6 addresses are returned. Another query is then made for A | > records and any found are returned as IPv4-mapped IPv6 addresses. | > h_length will be 16. Only if both queries fail does the function | > return a NULL pointer. This flag is ignored unless af equals | > AF_INET6. If both AI_ALL and AI_V4MAPPED are specified, AI_ALL | > takes precedence. | > - I assumed when reading "That is, if no AAAA records are found" in the first paragraph that a search for AAAA records should be made when the AI_V4MAPPED flag is specified along with an af of AF_INET6. However, this would make AI_V4MAPPED equivalent to AI_ALL as defined in the second paragraph. The example under AI_ADDRCONFIG does not shed any light on this point, as the outcomes in cases b) and c) are the same. > For example, if the node has no IPv6 source addresses configured, | > and af equals AF_INET6, and the node name being looked up has | > both AAAA and A records, then: (a) if only AI_ADDRCONFIG is | > specified, the function returns a NULL pointer; (b) if | > AI_ADDRCONFIG | AI_V4MAPPED is specified, the A records are | > returned as IPv4-mapped IPv6 addresses; (c) if AI_ADDRCONFIG | | > AI_ALL is specified, the A records are returned as IPv4-mapped | > IPv6 addresses. > Can someone clarify this, please? Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 06:59:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA14624 for ipng-dist; Tue, 24 Mar 1998 06:54:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA14617 for ; Tue, 24 Mar 1998 06:54:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA12268 for ; Tue, 24 Mar 1998 06:54:23 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA07382 for ; Tue, 24 Mar 1998 06:54:24 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA25471; Tue, 24 Mar 1998 08:49:53 -0600 Message-Id: <199803241449.IAA25471@gungnir.fnal.gov> To: "Vadapalli.V.V.J.Raghu" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5429) Re: IPv6 SITE Address In-reply-to: Your message of Tue, 24 Mar 1998 10:03:14 +0530. Date: Tue, 24 Mar 1998 08:49:53 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is the "site" in the context of IPv6 specification related to > Autonoumous system. My own unofficial answer: No. In a number of cases they will coincide, but I think this will occur much less than 1/2 the time. ___________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 08:13:54 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA14926 for ipng-dist; Tue, 24 Mar 1998 08:08:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA14919 for ; Tue, 24 Mar 1998 08:08:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA05796 for ; Tue, 24 Mar 1998 08:08:02 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA23126 for ; Tue, 24 Mar 1998 08:07:58 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id JAA28403; Tue, 24 Mar 1998 09:07:30 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id JAA20997; Tue, 24 Mar 1998 09:07:28 -0700 (MST) Message-Id: <199803241607.JAA20997@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 24 Mar 1998 09:07:28 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Chris Harding , gilligan@freegate.net, set@thumper.bellcore.com, bound@zk3.dec.com Subject: (IPng 5430) Re: Clarification of Basic Sockets API to IPv6 Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Chris. The difference between AI_V4MAPPED and AI_ALL is that the former is an *or* (search for A records and return them as IPv4-mapped only if no AAAA are found) and the latter is an *and* (always search for A records and return them as IPv4-mapped). If AI_V4MAPPED is specified, and one or more AAAA records are found, then no query is made for A records. So the three flags choices (0, AI_V4MAPPED, and AI_ALL) cover three of the four possible scenarios. The fourth scenario is "search for only A records and return them as IPv4-mapped, don't even search for AAAA records) and if an application really wants this (it should be rare for an IPv6-aware application not to want any AAAA records) it can specify AI_ALL and then go through the returned list of addresses and ignore all for which IN6_IS_ADDR_V4MAPPED() is false. All of this assumes af = AF_INET6, of course. Also note that we specify that if both AI_ALL and AI_V4MAPPED are specified, the former takes precedence. > The example under AI_ADDRCONFIG does not shed any light on this point, as > the outcomes in cases b) and c) are the same. > > > For example, if the node has no IPv6 source addresses configured, | > > and af equals AF_INET6, and the node name being looked up has | > > both AAAA and A records, then: (a) if only AI_ADDRCONFIG is | > > specified, the function returns a NULL pointer; (b) if | > > AI_ADDRCONFIG | AI_V4MAPPED is specified, the A records are | > > returned as IPv4-mapped IPv6 addresses; (c) if AI_ADDRCONFIG | | > > AI_ALL is specified, the A records are returned as IPv4-mapped | > > IPv6 addresses. The purpose of this example was to show that in case b), even though the node has AAAA records, they are not returned since AI_ADDRCONFIG is specified, hence the search for A records must take place since AI_V4MAPPED is specified. (One could interpret this as "I searched for AAAA records and found some, therefore I don't even look at AI_V4MAPPED", but we wanted to note that AI_ADDRCONFIG takes precedence.) Case c) yields the same result but since AI_ALL was specified it searches for the A records regardless of whether AI_ADDRCONFIG was specified or not. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 10:31:48 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA15393 for ipng-dist; Tue, 24 Mar 1998 10:20:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA15386 for ; Tue, 24 Mar 1998 10:20:28 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA10143 for ; Tue, 24 Mar 1998 10:20:25 -0800 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA24503 for ; Tue, 24 Mar 1998 10:20:25 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA10227; Tue, 24 Mar 1998 18:22:31 GMT Received: from mailhome [192.153.166.5] by mailgate.rdg.opengroup.org via smtpd ; Tue Mar 24 18:22 GMT 1998 Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA07116; Tue, 24 Mar 1998 18:07:20 GMT Received: from unknown(192.153.166.111) by mailhome.rdg.opengroup.org via smap (V1.3) id sma007080; Tue Mar 24 18:07:14 1998 Message-Id: <3.0.3.32.19980324181254.007efb10@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 24 Mar 1998 18:12:54 +0000 To: "W. Richard Stevens" , gilligan@freegate.net, set@thumper.bellcore.com, bound@zk3.dec.com From: Chris Harding Subject: (IPng 5431) Re: (c.harding 17153) Re: Clarification of Basic Sockets API to IPv6 Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org In-Reply-To: <199803241607.JAA20997@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - Thanks, Rich, for clearing this up. To make it plain in the Internet Draft, how about adding to the example the cases where AI_ADDRCONFIG is not specified but AI_V4MAPPED or AI_ALL is? (d) if only AI_V4MAPPED is specified then the AAAA records are returned; (e) if only AI_ALL is specified then the A records are returned as IPv4-mapped IPv6 addresses together with the AAAA records. At 09:07 24/03/98 -0700, W. Richard Stevens wrote: >Hi Chris. The difference between AI_V4MAPPED and AI_ALL is that the >former is an *or* (search for A records and return them as IPv4-mapped >only if no AAAA are found) and the latter is an *and* (always search >for A records and return them as IPv4-mapped). If AI_V4MAPPED is >specified, and one or more AAAA records are found, then no query is >made for A records. > >So the three flags choices (0, AI_V4MAPPED, and AI_ALL) cover three of >the four possible scenarios. The fourth scenario is "search for only >A records and return them as IPv4-mapped, don't even search for AAAA >records) and if an application really wants this (it should be rare >for an IPv6-aware application not to want any AAAA records) it can >specify AI_ALL and then go through the returned list of addresses and >ignore all for which IN6_IS_ADDR_V4MAPPED() is false. > >All of this assumes af = AF_INET6, of course. Also note that we specify >that if both AI_ALL and AI_V4MAPPED are specified, the former takes >precedence. > >> The example under AI_ADDRCONFIG does not shed any light on this point, as >> the outcomes in cases b) and c) are the same. >> >> > For example, if the node has no IPv6 source addresses configured, | >> > and af equals AF_INET6, and the node name being looked up has | >> > both AAAA and A records, then: (a) if only AI_ADDRCONFIG is | >> > specified, the function returns a NULL pointer; (b) if | >> > AI_ADDRCONFIG | AI_V4MAPPED is specified, the A records are | >> > returned as IPv4-mapped IPv6 addresses; (c) if AI_ADDRCONFIG | | >> > AI_ALL is specified, the A records are returned as IPv4-mapped | >> > IPv6 addresses. > >The purpose of this example was to show that in case b), even though >the node has AAAA records, they are not returned since AI_ADDRCONFIG >is specified, hence the search for A records must take place since >AI_V4MAPPED is specified. (One could interpret this as "I searched >for AAAA records and found some, therefore I don't even look at >AI_V4MAPPED", but we wanted to note that AI_ADDRCONFIG takes precedence.) >Case c) yields the same result but since AI_ALL was specified it >searches for the A records regardless of whether AI_ADDRCONFIG was >specified or not. > > Rich Stevens > > Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 14:59:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA15943 for ipng-dist; Tue, 24 Mar 1998 14:54:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA15936 for ; Tue, 24 Mar 1998 14:54:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA26654 for ; Tue, 24 Mar 1998 14:53:57 -0800 Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA17000 for ; Tue, 24 Mar 1998 14:53:56 -0800 (PST) Received: by INET-IMC-01 with Internet Mail Service (5.5.2166.0) id ; Tue, 24 Mar 1998 14:53:56 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81002399135@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'IPng List'" Cc: "'MSR IPv6 Discussion'" Subject: (IPng 5432) Microsoft Research IPv6 Release Date: Tue, 24 Mar 1998 14:53:51 -0800 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Microsoft Research, in partnership with USC/ISI East, is pleased to announce our IPv6 implementation for Windows NT. Due to external interest, we have decided to make an early release of the implementation publicly available in both source and binary forms. Please note that this is not a product release and it is not intended for commercial use. Our release is for research, educational, and testing purposes. The Windows networking group is working on a product-quality IPv6 implementation. Our implementation is a work-in-progress and does not yet support all of the features of the IPv6 protocol. Our next major release will have at least the minimum required mobility support as well as partial authentication and security support. We have tested at the UNH InterOperability Lab, and we have a machine on the 6bone. Please see our web site, http://www.research.microsoft.com/msripv6, for more information and to download the release. The release is copyrighted software and there is a license agreement that you must review and agree to before downloading. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 15:42:29 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id PAA16012 for ipng-dist; Tue, 24 Mar 1998 15:36:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id PAA16005 for ; Tue, 24 Mar 1998 15:36:48 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA08067 for ; Tue, 24 Mar 1998 15:36:46 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA10631 for ; Tue, 24 Mar 1998 15:36:47 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id SAA31466; Tue, 24 Mar 1998 18:36:43 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01108; Tue, 24 Mar 1998 18:36:42 -0500 Message-Id: <199803242336.AA01108@wasted.zk3.dec.com> To: Richard Draves Cc: "'IPng List'" , "'MSR IPv6 Discussion'" Subject: (IPng 5433) Re: Microsoft Research IPv6 Release In-Reply-To: Your message of "Tue, 24 Mar 1998 14:53:51 PST." <4D0A23B3F74DD111ACCD00805F31D81002399135@red-msg-50.dns.microsoft.com> Date: Tue, 24 Mar 1998 18:36:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Congrats this is great news for IPv6... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 16:20:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id QAA16120 for ipng-dist; Tue, 24 Mar 1998 16:15:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id QAA16113 for ; Tue, 24 Mar 1998 16:15:16 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA16450 for ; Tue, 24 Mar 1998 16:15:14 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id QAA00488 for ; Tue, 24 Mar 1998 16:15:14 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id SAA26794; Tue, 24 Mar 1998 18:08:29 -0600 Message-Id: <199803250008.SAA26794@gungnir.fnal.gov> To: Jack McCann Cc: hinden@ipsilon.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5434) Re: Router Renumbering In-reply-to: Your message of Mon, 23 Mar 1998 14:34:07 EST. <199803231934.AA03932@wasted.zk3.dec.com> Date: Tue, 24 Mar 1998 18:08:29 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is a compilation of comments ... Great! It's a much handier format than a dozen separate messages. > - A table of contents would be helpful. Agreed. I'll add one to the next rev. > - Section 2 typo "If subnetting information is in the same portion of of the" > ^^^^^ Fixed. > - Section 2 makes statements regarding idempotency of an "elementary RR > operation", and the potential non-idempotency of combinations of > "elementary RR operations". We were discussing the idempotency issue > when we realized there were differing views of what constitutes an > "elementary RR operation". Please define "elementary RR operation", > preferably before the statements regarding their idempotency properties. How about if I delete everything about elementary operations and just justify the reprocessing protection requirement on the grounds that a complete command message may not be idempotent? I already took out a further paragraph which didn't seem useful: .\" Note: the thing generated by all PCOs under composition is .\" a "monoid" -- a semigroup with identity. Commutativity of the .\" generators of the monoid (the elementary RR operations) would be .\" sufficient to make all combinations idempotent, but clearly such .\" commutativity is impossible to require while still keeping any .\" useful power in this mechanism. > - Section 2 > > "All RR packets which have a Sequence Number equal > to the highest value seen (for each valid key), and which pass the > authentication check, are equally valid and must be processed." > > Packets with sequence number "greater than" are also valid, why are > these not included in this statement? The way I look at it, this never happens. Once you SEE a sequence number it can't be higher than the highest value SEEN. I could have said "greater than or equal to the Recorded Sequence Number", but that term hasn't been introduced by this point. > - Section 2 talks about why we have segment numbers. Do segment numbers > have to be processed in order? (e.g. segment number 3 arrives before > segment numbers 1 and 2, do I wait for segments 1 and 2 before processing > segment 3?) A statement somewhere about processing order for segment > numbers would help. Hmm. Section 5.1 does not mention any sequencing based on the SegmentNumber, but it can't hurt to make it explicit. I'll do so in sections 2 and 4.1. Section 2: + The Segment Number does not impose an ordering on packet + processing. If a specific sequence of operations is desired, it + may be achieved by ordering the PCOs in a single RR Command + message or through the Sequence Number field. Section 4.1: SegmentNumber An unsigned 8-bit field which enumerates different valid RR messages having the same SequenceNumber and KeyID. + No ordering among RR messages is imposed by the + SegmentNumber. > - Section 3.1 > > "Prefix Control Operation, Match-Prefix, Use-Prefix > These are defined section 2." > > Explicit definitions of these important terms in this section (as > opposed to referring back to section 2) would be helpful. I'll consider that and probably do it. > - Section 3.1 > > "Matched Prefix > The existing prefix or address which matched a Match-Prefix. > > New Prefix > A prefix constructed from a Use-Prefix, possibly including some > of the Matched-Prefix." > > Should the definition of "Matched Prefix" be "Matched-Prefix", or > should the definition of "New Prefix" use the term "Matched Prefix"? > (And if you change the definition to "Matched-Prefix" there are several > instances of "Matched Prefix" that might also have to change.) The second hyphen should not be in the definition of New Prefix. > - Section 3.1 > > The term "Matched Prefix" includes both prefixes and addresses. > Some thought that explicitly defining and using the term "Matched > Address" might be more clear. I think it's better as it is. An address is a limiting case of a prefix (length = 128), as reflected in the first two Definitions, but a prefix with length < 128 is not an address at all. I'll make a note in my working copy, but unless there's more demand, I'll leave it as is. "Matched Prefix Or Address" is a mouthful, and has an unfortunate acronym. :-/ > - Section 3.1 > > "Note that "matches" is a transitive relation but not reflexive. If > two prefixes match each other, they are identical." > > We agreed that "matches" is transitive, but think it is reflexive > and is not symetric (it looks antisymetric). I'll check my old math books for the proper term. No, those may be *too* old. Finding some current course notes through Altavista indicates that you are correct (modulo an m). I will fix it. > (After spending some time discussing this we wondered was it really > necessary to make that statement in this spec, the properties of the > matches relation are not referred to other than in this one note.) The purpose of that note is to forearm the reader for the fifth paragraph of section 5.3. > - Section 4.1 > > "S This flag MUST be ignored unless the router treats > interfaces as belonging to different "sites"." > > Please define "site". Ah, there's there rub. All I want to say is that the router uses the S flag only if it has a definition of site. If the IPNG WG had a definition of site, then I'd cite or include it. But if I can't sight it, I can't cite it. (Sorry.) I'm just trying to allow for it, if the concept has use. In a similar vein, I presume up to 8 Router Advertisement flags, even though only two are defined as yet. A definition of site might not be necessary. Slipping one in here would sort of be sneaky. If "site" needs defining, let's make that a separate topic. > - Section 4.1 > > "If the destination address is appropriate for > interfaces belonging to more than one site, > > Is this to catch the case of multicast destination address with scope > greater than "site-local"? Are there any other cases to consider? There are no all-nodes addresses with scope greater than link, and no all-routers addresses with scope greater than site. (And site scope all-routers was added at my request for router renumbering.) But a router could be a member of some arbitrary global multicast group. How about inserting a step before checking the auth. key: 5.1. Header Check First, + the IPv6 destination address is checked. If it is neither an + All Routers multicast address [AARCH] nor one of the receiving + router's unicast addresses, the message MUST be discarded and SHOULD + be logged to network management. + + Then, the existence and validity of the key indicated by the KeyID > - Section 4.1 > > "SequenceNumber > An unsigned 32-bit sequence number. The sequence number > MUST be non-decreasing for all messages sent with the > same KeyID." > > Can the same sequence number be reused with the same KeyID provided > the KeyID has expired and been reused? Or asked another way, is my > router renumbering implementation allowed to forget about sequence > numbers associated with a given KeyID when that KeyID expires? OK, sure. I'll make it so: An unsigned 32-bit sequence number. The sequence number MUST be non-decreasing for all messages sent with a given KeyID, for the lifetime of that key. > - Section 4.2.1.2 Use-Prefix Part > > Do we really need a separate KeepLen field? Can't it be derived from > the Interface ID length as specified in a given "IPv6 over foo" spec? > If you keep KeepLen shouldn't there be a validity check such as: > > (UseLen + KeepLen) == (128 - Interface_ID_length) Neighbor discovery & addrconf do not rule out the possible existence of a prefix which is not the right length for configuring an address, so I don't want to rule it out either. If it were to be forbidden, this isn't the place to dictate it. > KeepLen may also be a problem if we ever have Interface_ID_length not > equal to 64 bits for some link type X, but is 64 bits for some other > link type Y, and the router has both type X and Y links: KeepLen would > need to be different depending on the link type, which means whoever > creates the RR command would need to know in advance what link types > were on the router. Well, yes. The network manager would have to know the network. But if there's consensus that this is a problem which needs to be solved, I'd rather add a match-condition on the length of the existing prefix than pur in a sanity check on the result. Half the "reserved" field of a Match-Prefix part could hold, say, a MinLen and MaxLen which would bound the length of an existing prefix to be tested for matching. A "Points for Discussion" section in the -00 through -02 drafts alluded to something along those lines, but no such discussion was provoked. Consider this a concrete suggestion: should such a MinLen & MaxLen, or some equivalent, be inserted? > - Section 4.2.1.2 Use-Prefix Part > > We thought a more detailed explanation of how the Valid and Preferred > lifetimes and the P and V bits relate back to ND and SAA would be > helpful, e.g. by describing the "Router Configuration Variables" [ND] > affected by the operation (e.g. AdvPrefixList, AdvValidLifetime, > AdvOnLinkFlag, AdvPreferredLifetime, AdvAutonomousFlag). > > As an aside, it would be helpful in this instance for ND to define > "Router Configuration Variable" names to associate with the P and V > flags. OK, I'll do that at a later date. The properties to be affected by the P & V flags didn't exist when I began, but they do now. > - Section 4.2.1.2 Use-Prefix Part > > "UsePrefix The 128-bit Use-prefix which either becomes or is used > in forming (if KeepLen is nonzero) the New Prefix. It > MUST NOT have the form of a multicast or link-local > address [AARCH]." > > Should we also prohibit loopback, IPv4-mapped, and IPv4-compatible? Multicast and loopback can be deterined form the first 8-10 bits. Those other forms are long and prohibiting them would belong elsewhere, probably in section 5.3. That would lead to something new: errors which can arise during the execution phase. (Although with a sufficiently short UseLen the formation of a link-local or multicast address might not have been detectable until then.) Should we prohibit loopback? Yes. Mapped? I suppose. Compatible? Maybe not. > - Section 4.3. Message Body -- Result Message > > "MatchedLen The length of the existing prefix which was matched by > the MatchPrefix." > > Can we replace "existing prefix which was matched by the MatchPrefix" > with "Matched Prefix", i.e. > > "MatchedLen The length of the Matched Prefix." Uh, yeah, that would read much better. > - Section 4.4.1. HMAC-MD5 > > These two statements are not specific to HMAC-MD5, and so should be > stated as a generic rule prior to section 4.4.1: > > "Before generating the AuthData, all fields of the RR header and all > the PCOs are filled in, except that the ICMPv6 checksum field is set > to zero." > > "When checking the AuthData, the ICMPv6 checksum must be effectively > set to zero." Another good point. > - Section 4.4.1. HMAC-MD5 > > "AuthLen will be 16 and AuthOffset will be equal to the > length in octets of the RR message, not including the AuthData, the > IPv6 header or any extension headers, but including the ICMPv6 > header." > > Everything after "RR message" is already said at that start of section > 4.4, you could just say: > > "AuthLen will be 16 and AuthOffset will be equal to the > length in octets of the RR message body." Uh, no, AuthOffset includes the length of the ICMPv6/RR header, but this will get taken care of by the edit induce by the previous comment. > - Section 5 Message Processing > > If we do decide that segments must be processed in order by increasing > segment number value as opposed to order received, we'll need some > additions in this section to handle that. Moot, I hope. > - Section 5.1. Header Check > > You should also discard if ICMP checksum not valid, ICMP code not 0, > ICMP length not feasable (as is done in ND spec). Ah, OK. > - Section 5.1. Header Check > > "Next, if the router is multi-sited, and the S flag is set and the > destination address of the Command is appropriate for interfaces > belonging to more than one site, but is not appropriate for the > interface on which the Command was received, this is an error." > > Can you give an example of such a destination address, and clarify > what you mean by "not appropriate"? Well, if we forbid sending RR commands to multicast addresses other than All Routers, then I can no longer come up with such an example. If other multicast addresses are permitted, then such an address which the router has joined on two other interfaces, but not the interface which received the command would do the trick. > - Section 5.1. Header Check > > "Finally, if the SequenceNumber in the message is greater than the > Recorded Sequence Number or the T flag is not set, skip to the > Authentication Check." > > Did you really mean to say "or the T flag is not set"? This means > we skip to Authentication Check when the SequenceNumber in the message > equal to the Recorded Sequence Number and the T flag is not set (i.e. > skip the segment number check for different segments of the same non-test > message). Uh-oh. It should be "or the T flag is set". But you have the other part wrong. If the sequence number has increased OR it's a test message, we don't need to check the segment number. I re-wrote these sentences so many times trying to get them readable (without resorting to pseudo-code) that I wound up with a stray not. > - Section 5.1. Header Check > > "body of that Result message MUST either be empty or be a saved copy" > > Why allow an empty Result message? To carry the "P" flag, sequence and segment numbers back for reliable notification of processing. > - Section 5.2. Authentication Check > > "The authentication check is performed over the RR message, without > any IPv6 or extension headers." > > Section 4.4 says IPv6 src/dst are included. Can you instead refer back > to section 4.4 here (only say how to do the authentication check in one > place to avoid conflicting definitions). Yes, that would be better. > - Section 5.3. Execution > > "If any such address > does match M, process the PCO as if P matched M, but when forming > New Prefixes, if KeepLen is non-zero, bits are copied from the > address." > > See KeepLen issue mentioned above. And same answer. > - Section 5.3. Execution > > "A copy of the Result message MAY be saved > to be retransmitted in response to a duplicate Command." > > If we disallow empty Result messages (see above), this "MAY" would > change to "MUST". Yes, if. Ah, so was the "why allow an empty Result message" question meant to indicate a preference for always saving the Rsult body for retransmission? I would argue that for full protection you'd need to keep the Results in non-volatile memory and you might eat up a lot more of that than just the 32-byte bitmap of sequence numbers would require. I balk at making that a MUST. However, you prompted me to add the saved Results to the list of sequence numbers as something to be cleared when the sequence number increases. Again, thanks to your group for the very careful reading and discussion. Anything I didn't agree to I'm willing to argXXX continue discussing, here or in LA. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 20:51:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id UAA16629 for ipng-dist; Tue, 24 Mar 1998 20:47:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id UAA16622 for ; Tue, 24 Mar 1998 20:47:27 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA00703 for ; Tue, 24 Mar 1998 20:47:27 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA05704 for ; Tue, 24 Mar 1998 20:47:27 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id XAA03012 for ; Tue, 24 Mar 1998 23:47:27 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10005; Tue, 24 Mar 1998 23:47:23 -0500 Message-Id: <199803250447.AA10005@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5435) What is a site in IPv6 ??? Date: Tue, 24 Mar 1998 23:47:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Not sure if we want to get into this in L.A. but we need for implementation to define what a "site" means to an implementation. The prefix don't help as that could be duplicated (SLA ID can be duplicated) as things are written now. One quick fix is that a subscriber SHOULD not duplicate SLA-ID's for a given TLA+RES+NLA prefix, or else they run the risk of not being able to differentiate multiple sites within a given prefix. Comments ??? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 21:03:32 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id UAA16648 for ipng-dist; Tue, 24 Mar 1998 20:59:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id UAA16641 for ; Tue, 24 Mar 1998 20:59:20 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA01871 for ; Tue, 24 Mar 1998 20:59:20 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA10225 for ; Tue, 24 Mar 1998 20:59:20 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id XAA20030 for ; Tue, 24 Mar 1998 23:59:20 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10293; Tue, 24 Mar 1998 23:59:20 -0500 Message-Id: <199803250459.AA10293@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5436) Multicast Scope vs Hop-Limit Date: Tue, 24 Mar 1998 23:59:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This came out of the API discussions. If a sender transmits a packet to site-local multicast, but Hop Limit is '1', the packet will not reach receivers past Hop Limit '1'. Also there is no metric now to determine if that Hop Limit should be 2, 4, 8, or 10 (I suggest below ICMPv6 time-exceeded is not optimal). Seems to be a discrepancy between Hop Limit and Multicast Scope. Ignoring the Hop Limit completely is probably not wise. One solution is that for multicast: is that a router is configured when the Hop Limit decrements to zero, it can have the option for a multicast dst address, permission to increment the Hop Limit to get it to additional receivers. The Hop Limit is a mutable field for AH and ESP, and not part of the pseudo checksum, so that is not a problem. Otherwise receivers within the first Hop Limit will have to hear it again and each time until the sender does not hit the Hop Limit for a given scope (from processing ICMPv6 time-exceeded messages). Seems rude to me? Comments ?? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 22:11:57 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id WAA16846 for ipng-dist; Tue, 24 Mar 1998 22:07:53 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id WAA16839 for ; Tue, 24 Mar 1998 22:07:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA08814 for ; Tue, 24 Mar 1998 22:07:42 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id WAA07167 for ; Tue, 24 Mar 1998 22:07:43 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA27999; Tue, 24 Mar 1998 22:01:01 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199803250459.AA10293@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Mar 1998 22:02:11 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 5437) Re: Multicast Scope vs Hop-Limit Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Multicast scope allows for admistrative bounds on how far a multicast packet can propogate. Hop-limit allows for finer-grain distance control within a multicast scope, for example, for performing an "expanding-ring search". It's a good question to ask what the default hop limit should be, both for global-scope and less-than-global-scope multicasts. For IPv4, we chose a default hop limit (TTL) of 1, mainly for safety reasons, so that a programmers didn't accidentally start sending multicasts to the world -- they at least had to think about tthe issue in order to get multicasts to go further than one hop. That was particularly important in the early days of IP multicast when the only available routing protocol didn't yet do "pruning" of multicast trees, so all multicasts were effectively broadcasts. I don't think that's an issue any more, and I would be comfortable with specifying that the default hop limit for all multicast scopes is exactly the same as the default unicast hop limit, i.e., the value that hosts learn from Neighbor Advertisements. > Ignoring the Hop Limit completely is probably not wise. I certainly agree with that. > One solution is that for multicast: is that a router is configured when > the Hop Limit decrements to zero, it can have the option for a > multicast dst address, permission to increment the Hop Limit to get it to > additional receivers. No, that would defeat the ability to do expanding ring searches. If a host originates a packet with a hop limit of N, the packet should never be forwarded more than N hops. > Otherwise receivers within the first Hop Limit will have to hear it > again and each time until the sender does not hit the Hop Limit for a > given scope (from processing ICMPv6 time-exceeded messages). ICMP Time Exceeded messages are not allowed to be sent in response to multicast packets. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 24 22:39:34 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id WAA16912 for ipng-dist; Tue, 24 Mar 1998 22:35:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id WAA16905 for ; Tue, 24 Mar 1998 22:35:09 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA11319 for ; Tue, 24 Mar 1998 22:35:09 -0800 Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [204.203.96.101]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id WAA18442 for ; Tue, 24 Mar 1998 22:35:10 -0800 (PST) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.16.5.253]) by slafw.enet.sharplabs.com (8.8.4/8.7.3) with ESMTP id WAA26012 for ; Tue, 24 Mar 1998 22:29:07 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.0.1458.49) id ; Tue, 24 Mar 1998 22:35:09 -0800 Message-ID: From: "Turner, Randy" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5438) Re: Multicast Scope vs Hop-Limit Date: Tue, 24 Mar 1998 22:35:08 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ...snip... > Otherwise receivers within the first Hop Limit will have to hear it > again and each time until the sender does not hit the Hop Limit for a > given scope (from processing ICMPv6 time-exceeded messages). ICMP Time Exceeded messages are not allowed to be sent in response to multicast packets. Is this true for both IPV4 and IPV6 ? Randy Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 05:36:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id FAA17253 for ipng-dist; Wed, 25 Mar 1998 05:27:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id FAA17246 for ; Wed, 25 Mar 1998 05:26:57 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA17531 for ; Wed, 25 Mar 1998 05:26:54 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA28613 for ; Wed, 25 Mar 1998 05:26:56 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id IAA22477 for ; Wed, 25 Mar 1998 08:26:55 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25967; Wed, 25 Mar 1998 08:26:53 -0500 Message-Id: <199803251326.AA25967@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5439) Link-Local Address, more than one on an interface.... Date: Wed, 25 Mar 1998 08:26:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The spec is not crystal clear here that an interface should only support one LL address per interface. For example a node creates an LL address using IPv6 over Ethernet as FE80::EUI_64 address and it passses DAD. But then the user creates an LL address with ifconfig as FE80::1. First I don't think we should support two LL addreses on an interface. Second I think the attached points in the arch and IPv6 over Ether specs also support that is not permitted. I bring this up because if it were permitted it would affect the code base for IPv6 in many places. I don't think we need to change the specs because we have this covered below. But I thought sending this out to the list to check would be a good logic check. From: draft-ietf-ipngwg-addr-arch-v2-06.txt 2.1 Addressing Model (2cnd paragraph) All interfaces are required to have at least one link-local unicast address (see section 2.8 for additional required addresses). A single interface may also be assigned multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope. The above specifically did not mention LL address. The scope is for unicast, anycast, or multicast. Not LL.. Here in section 2.8. 2.8 A Node's Required Addresses A host is required to recognize the following addresses as identifying itself: o Its Link-Local Address for each interface o Assigned Unicast Addresses o Loopback Address o All-Nodes Multicast Addresses o Solicited-Node Multicast Address for each of its assigned unicast and anycast addresses o Multicast Addresses of all other groups to which the host belongs. Note the singular and plural references above. LL and Loopback are singular. From: draft-ietf-ipngwg-trans-ethernet-04.txt 5. Link-Local Addresses The IPv6 link-local address [AARCH] for an Ethernet interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ I would claim from the above FE80::1 is an invalid LL address. And, as an adapter only has one mfg address as specified for EUI-64 a node cannot create two LL addresses for that reason too. Comments ?? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 05:56:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id FAA17274 for ipng-dist; Wed, 25 Mar 1998 05:51:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id FAA17267 for ; Wed, 25 Mar 1998 05:51:39 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA20367 for ; Wed, 25 Mar 1998 05:51:36 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA09870 for ; Wed, 25 Mar 1998 05:51:36 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id IAA25949; Wed, 25 Mar 1998 08:51:35 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA27729; Wed, 25 Mar 1998 08:51:27 -0500 Message-Id: <199803251351.AA27729@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5440) Re: Multicast Scope vs Hop-Limit In-Reply-To: Your message of "Tue, 24 Mar 1998 22:02:11 PST." Date: Wed, 25 Mar 1998 08:51:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >Multicast scope allows for admistrative bounds on how far a multicast packet >can propogate. Hop-limit allows for finer-grain distance control within a >multicast scope, for example, for performing an "expanding-ring search". Agreed.... but.......and I understood why and how this works in IPv4... >> the Hop Limit decrements to zero, it can have the option for a >> multicast dst address, permission to increment the Hop Limit to get it to >> additional receivers. >No, that would defeat the ability to do expanding ring searches. If a >host originates a packet with a hop limit of N, the packet should never >be forwarded more than N hops. So then how can a node, and more importantly an application know, that a message reached all intended recipients for a particular scope? Leaving this up to admin control in a router seems unelegant and now I would think we need an IPv6 Multicast scope discovery protocol to be developed. Expanded ring search is a nice theoretical ability, but without knowing results I am not sure of what value it has practically, from an applications perspective to deliver an urgent message thru multicast, unless we believe multicast is a limited use idea and should not be used in that manner. Personally I don't believe that, and believe this is a problem in IPv4 and should be fixed in IPv6. So the Expanded Ring search argument is not working for me.... >> Otherwise receivers within the first Hop Limit will have to hear it >> again and each time until the sender does not hit the Hop Limit for a >> given scope (from processing ICMPv6 time-exceeded messages). > >ICMP Time Exceeded messages are not allowed to be sent in response to >multicast packets. OK I just found this again in the ICMP spec, for some reason I thought we permitted it for IPv6 when I did not see it specifically in Section 3.3. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 06:44:25 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA17360 for ipng-dist; Wed, 25 Mar 1998 06:35:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA17353 for ; Wed, 25 Mar 1998 06:35:16 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA26040 for ; Wed, 25 Mar 1998 06:35:13 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA03787 for ; Wed, 25 Mar 1998 06:35:16 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA26514; Wed, 25 Mar 1998 06:28:37 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199803251326.AA25967@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Mar 1998 06:29:48 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 5441) Re: Link-Local Address, more than one on an interface.... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:26 AM -0800 3/25/98, bound@zk3.dec.com wrote: > First I don't think we should support two LL addreses on an interface. Jim, I hate to keep disagreeing with you, but I don't think we should forbid the assignment of multiple LL adresses to an interface. That would prevent the implementation of multiple "logical nodes" in a single box, sharing the same physical interface. (One example might be a multiprocessor machine, where each processor acts as a separately addressable IPv6 node, sharing a single physical interface.) > All interfaces are required to have at least one link-local unicast > address (see section 2.8 for additional required addresses). A > single interface may also be assigned multiple IPv6 addresses of any > type (unicast, anycast, and multicast) or scope. > > The above specifically did not mention LL address... The first line of the above *does* mention link-local addresses, and it says that each interface requires *at least* one, which implies the possibility of more than one. > 2.8 A Node's Required Addresses > > A host is required to recognize the following addresses as > identifying itself: > > o Its Link-Local Address for each interface > o Assigned Unicast Addresses > o Loopback Address > o All-Nodes Multicast Addresses > o Solicited-Node Multicast Address for each of its assigned > unicast and anycast addresses > o Multicast Addresses of all other groups to which the host > belongs. > > Note the singular and plural references above. > > LL and Loopback are singular. That's because a host is *required* to have at least one of each of those types; it was not meant to imply there can be *at most* one. > 5. Link-Local Addresses > > The IPv6 link-local address [AARCH] for an Ethernet interface is > formed by appending the Interface Identifier, as defined above, to > the prefix FE80::/64. > > 10 bits 54 bits 64 bits > +----------+-----------------------+----------------------------+ > |1111111010| (zeros) | Interface Identifier | > +----------+-----------------------+----------------------------+ > > I would claim from the above FE80::1 is an invalid LL address. And, > as an adapter only has one mfg address as specified for EUI-64 a node > cannot create two LL addresses for that reason too. In the vast majority of cases, an interface will only have one LL address, but I don't see a compelling reason to forbid assignmen of more than one (either using multiple factory-assigned IDs or through manual configuration) for unusual or unanticipated siuations; it would limit the flexibility of the architecture unncessarily. A particular implementation could choose not to support multiple LLs per interface, but I wouldn't want the specs to forbid it. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 06:58:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA17406 for ipng-dist; Wed, 25 Mar 1998 06:54:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA17399 for ; Wed, 25 Mar 1998 06:54:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA01196 for ; Wed, 25 Mar 1998 06:54:00 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA14018 for ; Wed, 25 Mar 1998 06:54:02 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA27642; Wed, 25 Mar 1998 08:47:18 -0600 Message-Id: <199803251447.IAA27642@gungnir.fnal.gov> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5442) Re: Link-Local Address, more than one on an interface.... In-reply-to: Your message of Wed, 25 Mar 1998 08:26:53 EST. <199803251326.AA25967@wasted.zk3.dec.com> Date: Wed, 25 Mar 1998 08:47:18 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The spec is not crystal clear here that an interface should only support > one LL address per interface. I think it is clear that multiple LL addrs are allowed. I think you & I disagree on that because of different understandings of the word "scope". You say ... > From: draft-ietf-ipngwg-addr-arch-v2-06.txt > 2.1 Addressing Model (2cnd paragraph) > All interfaces are required to have at least one link-local unicast > address (see section 2.8 for additional required addresses). A > single interface may also be assigned multiple IPv6 addresses of any > type (unicast, anycast, and multicast) or scope. > > The above specifically did not mention LL address. The scope is for > unicast, anycast, or multicast. Not LL.. But the very next sentence makes it clear that "scope" means link/ site/global: Unicast addresses with scope greater than link-scope are not needed for interfaces that are not used as the origin or destination of any IPv6 packets to or from non-neighbors. 2.0 makes "type" clear, but it's true that the term "scope" was not explicitly defined for unicast addresses, and its meaning when applied to unicast addresses is a little bit different from its meaning when applied to multicast. I'd REALLY hate to make up a separate word to replace scope in one of those cases, so how about using the term "unicast scope" to mean link/site/global and "multicast scope" to mean node/link/site/org/global with several reserved and unassigned values. > Here in section 2.8. [...] > Note the singular and plural references above. Yup, that's inconsistent with 2.1. > From: draft-ietf-ipngwg-trans-ethernet-04.txt > 5. Link-Local Addresses > The IPv6 link-local address [AARCH] for an Ethernet interface is[...] > I would claim from the above FE80::1 is an invalid LL address. And, > as an adapter only has one mfg address as specified for EUI-64 a node > cannot create two LL addresses for that reason too. Obviously the author of trans-ethernet was remiss in not reading addr-arch-v2 as carefully as you did! However, the use of FE80::1 only violates a "should not", since it does have the correct value of the U/L bit. I think we have to allow multiple LL addresses per interface unless we have very good reasons for forbidding it. I don't see any such reasons. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 06:58:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA17415 for ipng-dist; Wed, 25 Mar 1998 06:55:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA17408 for ; Wed, 25 Mar 1998 06:55:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA01552 for ; Wed, 25 Mar 1998 06:55:06 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA14627 for ; Wed, 25 Mar 1998 06:55:08 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA27577; Wed, 25 Mar 1998 06:48:27 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199803251351.AA27729@wasted.zk3.dec.com> References: Your message of "Tue, 24 Mar 1998 22:02:11 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Mar 1998 06:49:38 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 5443) Re: Multicast Scope vs Hop-Limit Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:51 AM -0800 3/25/98, bound@zk3.dec.com wrote: > >No, that would defeat the ability to do expanding ring searches. If a > >host originates a packet with a hop limit of N, the packet should never > >be forwarded more than N hops. > > So then how can a node, and more importantly an application know, that a > message reached all intended recipients for a particular scope? The goal of an application performing an expanding ring search is explicitly *not* to reach all listeners within the specified scope, but rather to reach *only* the nearby ones, i.e., the ones within the application-specified hop limit. If the goal of the application is to reach all listeners within a scope, the application should use a big hop limit (the same as the unicast default). I said in my previous message that I think that should be the default behavior, so the unsurprising thing will happen in the normal case. Only those applications doing something more sophisticated (like expanding- ring search) will have to worry about fiddling with the hop limit. > Leaving this up to admin control in a router seems unelegant... I don't understand what that means. Are you objecting to the notion of scope in multicast addresses? > Expanded ring search is a nice theoretical ability, but without knowing > results I am not sure of what value it has practically, from an > applications perspective to deliver an urgent message thru multicast, > unless we believe multicast is a limited use idea and should not be > used in that manner. Personally I don't believe that, and believe > this is a problem in IPv4 and should be fixed in IPv6. Who said anything about "urgent"? If an application wants to "urgently" reach a particular set of receivers by multicast, it should use a hop-limit big enough to reach those receivers. The ability to use smaller hop limits is not a "problem", it is a "feature", a capability that falls naturally out of the architecture. It takes zero code to implement that feature (in fact it takes extra code to prevent it), and if an application doesn't want to use it, it doesn't have to. > So the Expanded Ring search argument is not working for me.... Fine. But that's no reason to break that capability for those who consider it useful. > >ICMP Time Exceeded messages are not allowed to be sent in response to > >multicast packets. > > OK I just found this again in the ICMP spec, for some reason I thought we > permitted it for IPv6 when I did not see it specifically in Section 3.3. The only ICMP error-class message permitted in response to multicasts is the Packet Too Big message (to allow PMTU discovery for multicast). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 07:03:04 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA17443 for ipng-dist; Wed, 25 Mar 1998 06:59:31 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA17436 for ; Wed, 25 Mar 1998 06:59:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA02772 for ; Wed, 25 Mar 1998 06:59:16 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA16864 for ; Wed, 25 Mar 1998 06:59:18 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA27676; Wed, 25 Mar 1998 08:52:33 -0600 Message-Id: <199803251452.IAA27676@gungnir.fnal.gov> To: bound@zk3.dec.com Cc: Steve Deering , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5444) Re: Multicast Scope vs Hop-Limit In-reply-to: Your message of Wed, 25 Mar 1998 08:51:27 EST. <199803251351.AA27729@wasted.zk3.dec.com> Date: Wed, 25 Mar 1998 08:52:33 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > So then how can a node, and more importantly an application know, that a > message reached all intended recipients for a particular scope? Unless all the recipients can ACK or NAK, you can never know. But to answer the looser question, since you already rely on routers to tell you the a HL value sufficient to reach anything on the internet, and a site is a subset (and probably a proper subset) of the internet, using that same HL value is all right. Sure, for unicast you can get a time exceeded to alert you that the router was wrong about the HL ... but you can't distinguish between the case of an internet larger than your network admin thought and the case of a routing loop on the way to your destination. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 07:18:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id HAA17478 for ipng-dist; Wed, 25 Mar 1998 07:10:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id HAA17471 for ; Wed, 25 Mar 1998 07:10:48 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA06121 for ; Wed, 25 Mar 1998 07:10:47 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA23922 for ; Wed, 25 Mar 1998 07:10:47 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: ipng@sunroof.eng.sun.com In-reply-to: <199803251326.AA25967@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5445) Re: Link-Local Address, more than one on an interface.... Date: Wed, 25 Mar 98 10:10:46 -0500 Message-ID: <9803251010.aa10282@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, >The spec is not crystal clear here that an interface should only support >one LL address per interface. For example a node creates an LL address >using IPv6 over Ethernet as FE80::EUI_64 address and it passses DAD. >But then the user creates an LL address with ifconfig as FE80::1. > >First I don't think we should support two LL addreses on an interface. Sorry to disagree again, but I think that the specifications should (and do) allow for the existence of more than one LL address per interface. I agree that, in most cases, hosts will not have more than one link local address per interface, but I see no reason why this should be limited in the specifications. It would be perfectly reasonable if a given implementation could not be configured to have more than one LL address on a given interface, but I don't think that the specification should forbid all implementations from allowing this (or even recommend against it). Currently, in IPv4, some customers use multiple IP addresses on a single interface for various purposes (usually multiple cards in a single box, etc.), and some of these purposes may map well to using multiple LL addresses in IPv6. Even though some nodes support this, there are also many implementations that do not allow multiple IPv4 addresses to be assigned to the same interface. I would expect this same situation to exist for LL adresses in IPv6; the ability to configure multiple LL addresses for a particular interface (automatically or manually) might only be available on certain special-purpose stacks. >I bring this up because if it were permitted it would affect the code >base for IPv6 in many places. Would this only affect the code base of a node that actually allowed configuration of multiple link-local addresses on a single interface, or would the existence of such nodes have an affect on all IPv6 code bases? If the former, then that is the cost that those stacks will pay for allowing this feature. If the latter, then could you please explain what you believe the affects are/will be? My implementation currently allows multiple LL addresses to be assigned to an ethernet interface (although I'll only autoconfigure one). >I don't think we need to change the specs because we have this covered >below. But I thought sending this out to the list to check would be a >good logic check. By my reading of the specs, they quite clearly allow more than one link-local address per interface. So, there is obviously some ambiguity here that should be cleared up once it is decided which way things are intended/agreed to work. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 07:29:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id HAA17526 for ipng-dist; Wed, 25 Mar 1998 07:22:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id HAA17519 for ; Wed, 25 Mar 1998 07:21:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09097 for ; Wed, 25 Mar 1998 07:21:48 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA00229 for ; Wed, 25 Mar 1998 07:21:48 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: deering@cisco.com, ipng@sunroof.eng.sun.com In-reply-to: <199803251351.AA27729@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5446) Re: Multicast Scope vs Hop-Limit Date: Wed, 25 Mar 98 10:21:46 -0500 Message-ID: <9803251021.aa10342@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So then how can a node, and more importantly an application know, that a >message reached all intended recipients for a particular scope? Couldn't an application that wanted a multicast message to be sent to all listening nodes (regardless of how many hops away) within the given site just send to a site-scoped multicast address using a hop-limit of 255? Or am I missing something? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 09:49:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA17970 for ipng-dist; Wed, 25 Mar 1998 09:44:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA17963 for ; Wed, 25 Mar 1998 09:44:43 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA17581 for ; Wed, 25 Mar 1998 09:44:41 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with SMTP id JAA03303 for ; Wed, 25 Mar 1998 09:44:43 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id JAA08130; Wed, 25 Mar 1998 09:44:42 -0800 Message-Id: <3.0.5.32.19980325094237.0097b860@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 25 Mar 1998 09:42:37 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5447) IPng web pages updated Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng web pages at http://playground.sun.com/ipng have been updated. Changes include current specifications and the new Microsoft Research implementation. Corrections to me. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 10:07:17 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA18180 for ipng-dist; Wed, 25 Mar 1998 10:01:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA18173 for ; Wed, 25 Mar 1998 10:01:29 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA22940 for ; Wed, 25 Mar 1998 10:01:24 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA14871 for ; Wed, 25 Mar 1998 10:01:17 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id KAA08881; Wed, 25 Mar 1998 10:01:13 -0800 Message-Id: <3.0.5.32.19980325100048.009be100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 25 Mar 1998 10:00:48 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5448) Implementation Reports for IPv6, ICMPv6, and Path MTU for IPv6 Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As part of submitting the IPv6 protocol, ICMPv6, and Path MTU Discovery for IPV6 specifications to the IESG for Draft Standard we are required to document current implementations. Many thanks to Jeremy McCooey and Bill Lenharth of UNH for their help in putting this information together. The current reports can be found at: ftp://playground.sun.com/pub/ipng/implementation-reports/ Please send me corrections and additions. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 10:27:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA18244 for ipng-dist; Wed, 25 Mar 1998 10:17:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA18237 for ; Wed, 25 Mar 1998 10:17:00 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA28409 for ; Wed, 25 Mar 1998 10:16:58 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA26105 for ; Wed, 25 Mar 1998 10:16:58 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id NAA06248; Wed, 25 Mar 1998 13:16:57 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA15546; Wed, 25 Mar 1998 13:16:56 -0500 Message-Id: <199803251816.AA15546@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5449) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 06:29:48 PST." Date: Wed, 25 Mar 1998 13:16:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Well thank goodness you or I are not the one true answer. I would like to hear WG discussion on this, and esp from other implementors. You keep disagreeing with me I think because our views are vastly different. I have to ship a product and I don't want to put a lot of code in an implementation without good reason. A good reason to me is not one case that may or may not happen. Another issue is if doing something introduces more bugs, then it has to be questioned, which 2 LL addresses could do if not done with some order and thought on our part before it is permitted if the WG wants it done. >I hate to keep disagreeing with you, but I don't think we should forbid the >assignment of multiple LL adresses to an interface. That would prevent the >implementation of multiple "logical nodes" in a single box, sharing the >same physical interface. (One example might be a multiprocessor machine, >where each processor acts as a separately addressable IPv6 node, sharing >a single physical interface.) I am quite familiar with the multiple processor scenario and it is a real issue. But I see no reason for multiple LL addresses. The interface is a communications mechansims to the processor and for each processor I would have my own stack essentially. At the application it would be transparent. So I don't see that as an issue. >> All interfaces are required to have at least one link-local unicast >> address (see section 2.8 for additional required addresses). A >> single interface may also be assigned multiple IPv6 addresses of any >> type (unicast, anycast, and multicast) or scope. >> >> The above specifically did not mention LL address... >The first line of the above *does* mention link-local addresses, and it says >that each interface requires *at least* one, which implies the possibility >of more than one. Then the paren should include Link-Local. But I read the two sentences as distinct. The first applies to Link-Local. The second to non-Link-Local. That is my interpretation. The phrase "A single interface may also" to me means it is distinct from the previous sentence and not inclusive from the paren's. >> 2.8 A Node's Required Addresses >> >> A host is required to recognize the following addresses as >> identifying itself: >> >> o Its Link-Local Address for each interface >> o Assigned Unicast Addresses >> o Loopback Address >> o All-Nodes Multicast Addresses >> o Solicited-Node Multicast Address for each of its assigned >> unicast and anycast addresses >> o Multicast Addresses of all other groups to which the host >> belongs. >> >> Note the singular and plural references above. >> >> LL and Loopback are singular. >That's because a host is *required* to have at least one of each of those >types; it was not meant to imply there can be *at most* one. It says above "recognize" not "at least one". How many I read based on the singularity or plurality of the bullet. I see no reason for two loopback interfaces. In the MP case I answered that above. >> 5. Link-Local Addresses >> >> The IPv6 link-local address [AARCH] for an Ethernet interface is >> formed by appending the Interface Identifier, as defined above, to >> the prefix FE80::/64. >> >> 10 bits 54 bits 64 bits >> +----------+-----------------------+----------------------------+ >> |1111111010| (zeros) | Interface Identifier | >> +----------+-----------------------+----------------------------+ >> >> I would claim from the above FE80::1 is an invalid LL address. And, >> as an adapter only has one mfg address as specified for EUI-64 a node >> cannot create two LL addresses for that reason too. >In the vast majority of cases, an interface will only have one LL address, >but I don't see a compelling reason to forbid assignmen of more than one >(either using multiple factory-assigned IDs or through manual configuration) >for unusual or unanticipated siuations; it would limit the flexibility of >the architecture unncessarily. If a LL must use EUI-64 how can it create two LL's. That would not pass DAD. To permit a user to config FE80::1 would be invalid per the EUI format rules. So I don't see with the present wording how 2 LL's can be permitted in this spec either. >A particular implementation could choose not to support multiple LLs per >interface, but I wouldn't want the specs to forbid it. I would cause I see no clear example of the use that I could not solve with one LL address. If one can solve the problem there is no reason to complicate implementations with supporting two of them, "just in case". /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 10:38:17 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA18285 for ipng-dist; Wed, 25 Mar 1998 10:31:10 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id KAA18278 for ; Wed, 25 Mar 1998 10:31:05 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id KAA17304 for ; Wed, 25 Mar 1998 10:31:03 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA15249 for ipng@sunroof.eng.sun.com; Wed, 25 Mar 1998 10:30:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA18252 for ; Wed, 25 Mar 1998 10:25:57 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA01532 for ; Wed, 25 Mar 1998 10:25:54 -0800 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA02332 for ; Wed, 25 Mar 1998 10:25:39 -0800 (PST) Message-Id: <199803251825.KAA02332@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA197930355; Wed, 25 Mar 1998 13:25:55 -0500 To: ipng@sunroof.eng.sun.com Subject: (IPng 5451) Transparent Renumbering? Date: Wed, 25 Mar 1998 13:25:54 -0500 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is anyone working on a "Transparent Renumbering" draft? That is, a system by which a node's (or group of nodes) IP address may change without losing any of its connections, TCP, UDP, or other? I don't mean MobileIP; I mean a permanent change. If the answer is no, no one's working on this: I have some ideas on this subject. Would anyone be interested in discussing them with me at length? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 10:54:50 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA18404 for ipng-dist; Wed, 25 Mar 1998 10:48:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA18384 for ; Wed, 25 Mar 1998 10:48:01 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA08137 for ; Wed, 25 Mar 1998 10:47:58 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA17998 for ; Wed, 25 Mar 1998 10:47:59 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id NAA01726; Wed, 25 Mar 1998 13:47:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA16076; Wed, 25 Mar 1998 13:47:54 -0500 Message-Id: <199803251847.AA16076@wasted.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5452) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 08:47:18 CST." <199803251447.IAA27642@gungnir.fnal.gov> Date: Wed, 25 Mar 1998 13:47:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think we have to allow multiple LL addresses per interface unless >we have very good reasons for forbidding it. I don't see any such >reasons. I take a different view and this is at the crux of many of my issues with the spec's when I impelement them. " I think we MUST not allow multiple LL addresses per interface unless a real-world reason (and in most cases more than one) can be provided and justified". We look at things much differently. Anyway we need WG discussion I think. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:01:09 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA18555 for ipng-dist; Wed, 25 Mar 1998 10:57:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA18548 for ; Wed, 25 Mar 1998 10:57:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA11057 for ; Wed, 25 Mar 1998 10:57:18 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA24530 for ; Wed, 25 Mar 1998 10:57:19 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA25759; Wed, 25 Mar 98 10:54:14 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA01264; Wed, 25 Mar 1998 10:58:41 -0800 Date: Wed, 25 Mar 1998 10:58:41 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199803251858.KAA01264@feller.mentat.com> To: deering@cisco.com, bound@zk3.dec.com Subject: (IPng 5454) Re: Link-Local Address, more than one on an interface.... Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > Well thank goodness you or I are not the one true answer. I would like to > hear WG discussion on this, and esp from other implementors. > Our implementation does not have a problem with assigning multiple LL addresses to the same interface. We will perform DAD on the assigned address. If DAD does not detect a duplicate the address can be used as a source address just like any other address assigned to the interface. I don't have a clear idea what the facility would be used for but I don't feel a need to add code to disable the facility just because I lack imagination.:-) tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:05:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18590 for ipng-dist; Wed, 25 Mar 1998 11:00:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA18571 for ; Wed, 25 Mar 1998 10:59:27 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA11562 for ; Wed, 25 Mar 1998 10:59:23 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA25875 for ; Wed, 25 Mar 1998 10:59:23 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id NAA05197; Wed, 25 Mar 1998 13:59:17 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA18126; Wed, 25 Mar 1998 13:59:15 -0500 Message-Id: <199803251859.AA18126@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5456) Re: Multicast Scope vs Hop-Limit In-Reply-To: Your message of "Wed, 25 Mar 1998 06:49:38 PST." Date: Wed, 25 Mar 1998 13:59:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If the goal of the application is to reach all listeners within a scope, >the application should use a big hop limit (the same as the unicast default). >I said in my previous message that I think that should be the default >behavior, so the unsurprising thing will happen in the normal case. >Only those applications doing something more sophisticated (like expanding- >ring search) will have to worry about fiddling with the hop limit. But the application does not know what "big" is and then no way of knowing if in fact Hop Limit = 29 was in fact big enough. It is not a sure thing to set the Hop Limit and be sure all apps were reached. Of course always setting it to 254 would probably work. But I never bought into the 255 diameter is enough math either. >> Leaving this up to admin control in a router seems unelegant... >I don't understand what that means. Are you objecting to the notion of >scope in multicast addresses? This was in response to your comment ND can provide the hop-limit as a default. An admin sets that on the router. >> Expanded ring search is a nice theoretical ability, but without knowing >> results I am not sure of what value it has practically, from an >> applications perspective to deliver an urgent message thru multicast, >> unless we believe multicast is a limited use idea and should not be >> used in that manner. Personally I don't believe that, and believe >> this is a problem in IPv4 and should be fixed in IPv6. >Who said anything about "urgent"? If an application wants to "urgently" >reach a particular set of receivers by multicast, it should use a hop-limit >big enough to reach those receivers. The ability to use smaller hop >limits is not a "problem", it is a "feature", a capability that falls >naturally out of the architecture. It takes zero code to implement >that feature (in fact it takes extra code to prevent it), and if an >application doesn't want to use it, it doesn't have to. Huh... OK ... What application that is developed for profit reasons to solve a business problem wants to only reach a "certain" member of the multicast group with the packet. If that was the case just reduce the scope which is possible in IPv6 between link-local and site for example, like dept, org, etc.. By urgent I mean't it was a mail message the sender wanted all to see for that scope. >> So the Expanded Ring search argument is not working for me.... >Fine. But that's no reason to break that capability for those who consider >it useful. I did not say break it or eliminate it, but I am saying it should not drive other uses for multicast. >> >ICMP Time Exceeded messages are not allowed to be sent in response to >> >multicast packets. >> >> OK I just found this again in the ICMP spec, for some reason I thought we >> permitted it for IPv6 when I did not see it specifically in Section 3.3. >The only ICMP error-class message permitted in response to multicasts is >the Packet Too Big message (to allow PMTU discovery for multicast). e.2) a packet destined to an IPv6 multicast address (there are two exceptions to this rule: (1) the Packet Too Big Message - Section 3.2 - to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 - Section 3.4 - reporting an unrecognized IPv6 option that has the Option Type highest-order two bits set to 10), or Two messages are permitted. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:05:26 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA18569 for ipng-dist; Wed, 25 Mar 1998 10:58:46 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id KAA18562 for ; Wed, 25 Mar 1998 10:58:39 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id KAA29867 for ; Wed, 25 Mar 1998 10:58:38 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA15373 for ipng@sunroof.eng.sun.com; Wed, 25 Mar 1998 10:58:33 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka-105 [129.146.105.47]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA18467 for ; Wed, 25 Mar 1998 10:50:42 -0800 (PST) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02236; Wed, 25 Mar 1998 10:50:35 -0800 Message-Id: <199803251850.KAA02236@hsmpka.eng.sun.com> Date: Wed, 25 Mar 1998 10:50:27 -0800 (PST) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 5455) Re: Transparent Renumbering? To: soule@math.brown.edu Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iCQnQs5CoF09e6/dyB+CwQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Jim Bound and I have discussed modifying Mobile IPv6's "Binding Update" destination option to perform exactly this function. It seems like a good thing to revive. There are a number of issues around robustness and security, however, which are tricky. And then there is always Erik Nordmark's question about what happens when two nodes renumber permanently and simultaneously. Christian Huitema also contributed earlier ideas about how to fix TCP to handle such renumbering. Lastly, Mobile IPv6's Home Address destination option may also help here. In any case, I think it works a lot better when there is a required transition period when a node has both addresses valid. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:09:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18617 for ipng-dist; Wed, 25 Mar 1998 11:03:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA18610 for ; Wed, 25 Mar 1998 11:02:57 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA12546 for ; Wed, 25 Mar 1998 11:02:54 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA28362 for ; Wed, 25 Mar 1998 11:02:55 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA10205; Wed, 25 Mar 1998 14:02:54 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA18419; Wed, 25 Mar 1998 14:02:51 -0500 Message-Id: <199803251902.AA18419@wasted.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5457) Re: Multicast Scope vs Hop-Limit In-Reply-To: Your message of "Wed, 25 Mar 1998 08:52:33 CST." <199803251452.IAA27676@gungnir.fnal.gov> Date: Wed, 25 Mar 1998 14:02:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I think having scope is the solution and exhausting it as much as it can. If that can not happen the router that cannot forward it further can send back a ***new defined icmp message*** that would probably have multiple codes within its type, describing what happened. Hop Limit can be honored for Expanded Ring Search but something should turn that on and I am thinking on that now. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:13:09 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18660 for ipng-dist; Wed, 25 Mar 1998 11:07:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA18653 for ; Wed, 25 Mar 1998 11:07:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA13743 for ; Wed, 25 Mar 1998 11:07:26 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA01298 for ; Wed, 25 Mar 1998 11:07:25 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA21379; Wed, 25 Mar 1998 11:00:47 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199803251816.AA15546@wasted.zk3.dec.com> References: Your message of "Wed, 25 Mar 1998 06:29:48 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Mar 1998 11:01:55 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 5458) Re: Link-Local Address, more than one on an interface.... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:16 AM -0800 3/25/98, bound@zk3.dec.com wrote: > Well thank goodness you or I are not the one true answer. I would like to > hear WG discussion on this, and esp from other implementors. Of course. > You keep disagreeing with me I think because our views are vastly > different. I have to ship a product and I don't want to put a lot of > code in an implementation without good reason. A good reason to me is > not one case that may or may not happen. A good reason is not constraining the architecture if not necessary. As Margaret pointed out, many IPv4 implementations included a limitation of one address per interface, and that turned out to cause unanticipated problems later on. Let's learn from that and not make the same mistake again. > I am quite familiar with the multiple processor scenario and it is a > real issue. But I see no reason for multiple LL addresses. The > interface is a communications mechansims to the processor and for each > processor I would have my own stack essentially. At the application it > would be transparent. So I don't see that as an issue. That was just one example of where allowing multiple LLs per interface would be useful. In IPv6, we conciously decided *not* to limit the number of addresses per interface, and for consistenxy that should apply to addresses of any scope, including link-local. > >The first line of the above *does* mention link-local addresses, and it says > >that each interface requires *at least* one, which implies the possibility > >of more than one. > > Then the paren should include Link-Local. > > But I read the two sentences as distinct. The first applies to > Link-Local. The second to non-Link-Local. That is my interpretation. OK, we'll try to make the language clearer. > >That's because a host is *required* to have at least one of each of those > >types; it was not meant to imply there can be *at most* one. > > It says above "recognize" not "at least one". How many I read based on > the singularity or plurality of the bullet. OK, we'll clean that up too. > I see no reason for two loopback interfaces. I see no reason to forbid it. Just because you can't think of a use for multiple LLs or multiple loopback interfaces/addresses doesn't mean there are no, and will never be any, valid uses. > If a LL must use EUI-64 how can it create two LL's. That would not pass > DAD. If the node has more than one assigned EUI-64 or IEEE-802 address, either wired into a single interface or into multiple interfaces, it can legitimately create distinct link-local addresses out of them. > To permit a user to config FE80::1 would be invalid per the EUI format > rules. Where do you see that? That address can safely be assigned to one interface on any link. > I would cause I see no clear example of the use that I could not solve > with one LL address. If one can solve the problem there is no reason to > complicate implementations with supporting two of them, "just in case". You've already had to make your implementation handle multiple addresses for the other two scopes, so allowing multiple LLs ought to be straight- forward (and I could imagine that in some implementations it would take *more* code to restruct LLs to only one per interface). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:19:10 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18703 for ipng-dist; Wed, 25 Mar 1998 11:11:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA18695 for ; Wed, 25 Mar 1998 11:11:30 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA14814 for ; Wed, 25 Mar 1998 11:11:27 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA03983 for ; Wed, 25 Mar 1998 11:11:28 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA23506; Wed, 25 Mar 1998 14:11:27 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA18697; Wed, 25 Mar 1998 14:11:22 -0500 Message-Id: <199803251911.AA18697@wasted.zk3.dec.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5459) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 10:10:46 EST." <9803251010.aa10282@khitomer.epilogue.com> Date: Wed, 25 Mar 1998 14:11:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I knew you would agree we should have them, and Steve too. Let me keep this short as my responses to Steve can apply to your mail too. Give me one reason to have two of them that is useful to solve a customer problem on a network, other than debug because I can counter any debug in another matter and first I would like to hear the use of them. Not because it seems and feels like we should... As far as implementation it affects all the ifnet lists in any implementation, and then any data structures used to search interfaces up the stack. As far as IPv4 providing multiple addresses. I agree we do this too but that is a different issue and I am not arguing against multiple non LL addresses for an interface. So that argument does not apply. I view an LL address as a Link address for control, admin operations in the protocol, and as a means to get the node up and running. Not as a means to differentiate the functions of an interface. For the dentist office it also is valuable as an IP address too for applications. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:19:10 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18729 for ipng-dist; Wed, 25 Mar 1998 11:13:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA18722 for ; Wed, 25 Mar 1998 11:13:34 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA15463 for ; Wed, 25 Mar 1998 11:13:31 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA05346 for ; Wed, 25 Mar 1998 11:13:24 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA14428; Wed, 25 Mar 1998 14:13:21 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19042; Wed, 25 Mar 1998 14:13:21 -0500 Message-Id: <199803251913.AA19042@wasted.zk3.dec.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5460) Re: Multicast Scope vs Hop-Limit In-Reply-To: Your message of "Wed, 25 Mar 1998 10:21:46 EST." <9803251021.aa10342@khitomer.epilogue.com> Date: Wed, 25 Mar 1998 14:13:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Couldn't an application that wanted a multicast message to be sent to >all listening nodes (regardless of how many hops away) within the >given site just send to a site-scoped multicast address using a >hop-limit of 255? > >Or am I missing something? Yes. If it is global scope and the hops needed are 400. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:29:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18820 for ipng-dist; Wed, 25 Mar 1998 11:24:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA18813 for ; Wed, 25 Mar 1998 11:24:22 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA18258 for ; Wed, 25 Mar 1998 11:24:18 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA12684 for ; Wed, 25 Mar 1998 11:24:20 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA28084; Wed, 25 Mar 1998 14:24:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19430; Wed, 25 Mar 1998 14:24:12 -0500 Message-Id: <199803251924.AA19430@wasted.zk3.dec.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5461) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 10:10:46 EST." <9803251010.aa10282@khitomer.epilogue.com> Date: Wed, 25 Mar 1998 14:24:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Here is another issue on LL addresses a colleague just sent me as I am trying to resolve this not win a debate: Specifically, don't multiple link local addresses increase the complexity of the following assertions from rfc 1970. "The use of link-local addresses to uniquely identify routers (for Router Advertisement and Redirect messages) makes it possible for hosts to maintain the router associations in the event of the site renumbering to use new global prefixes." "Source Address MUST be the link-local address assigned to the interface from which this message is sent." "6.2.8. Link-local Address Change The link-local address on a router SHOULD change rarely, if ever. Nodes receiving Neighbor Discovery messages use the source address to identify the sender. If multiple packets from the same router contain different source addresses, nodes will assume they come from different routers, leading to undesirable behavior. " etc. I am sure there are many more instances, but it seems to me that there's a strong assumption that there is only one link-local address on a router's interface. Either the assumption is incorrect, in which case a router must keep track of what link-local address is to be used in which advertisement, or we need to explicitly state that only 1 link-local address is allowed on an interface. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:31:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18848 for ipng-dist; Wed, 25 Mar 1998 11:27:53 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id LAA18841 for ; Wed, 25 Mar 1998 11:27:40 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA13839; Wed, 25 Mar 1998 11:27:37 -0800 (PST) Date: Wed, 25 Mar 1998 11:27:33 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5462) Re: Link-Local Address, more than one on an interface.... To: bound@zk3.dec.com Cc: Matt Crawford , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803251847.AA16076@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > " I think we MUST not allow multiple LL addresses per interface unless a > real-world reason (and in most cases more than one) can be provided and > justified". Jim, How many address are allowed on an IPv4 interface? If you read the specification (e.g. RFC 791) you'll find it notable silent on the issue. For many years after RFC 791 was written most (all?) implementations only allowed one IP address per interface. Today many implementations allow more than one IP address per interface but there are probably a fair number of implementations that don't. The lesson: Leave the specifications as open as needed and don't articifically constrain them since they are supposed to last for about 20 years. Implementations can and will adjust based on the reality of using IPv6 over time. But if we artificially constrain the specification today as you propose above we loose that flexibility. Just because we don't see (at least in your opinion) multiple link-local address per interfaces as solving a customer problem today doesn't mean that they will be useful 10 years from now (or sooner). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:50:36 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18913 for ipng-dist; Wed, 25 Mar 1998 11:45:31 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA18906 for ; Wed, 25 Mar 1998 11:45:22 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA24556 for ; Wed, 25 Mar 1998 11:45:18 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA26815 for ; Wed, 25 Mar 1998 11:45:18 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA16062; Wed, 25 Mar 1998 14:45:15 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21474; Wed, 25 Mar 1998 14:45:12 -0500 Message-Id: <199803251945.AA21474@wasted.zk3.dec.com> To: Steve Soule Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5463) Re: Transparent Renumbering? In-Reply-To: Your message of "Wed, 25 Mar 1998 13:25:54 EST." <199803251825.KAA02332@earth.sun.com> Date: Wed, 25 Mar 1998 14:45:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, yes I am working on this and will just ship it. trying to do this in the ietf is next to impossible. be glad to talk to you at the ietf if your there. my solution will work for udp and tcp. the masses at the ietf usually don't care about udp when discussing these sorts of needs, udp is the harder problem. if your not at the ietf we can talk on the phone as we are both on the least coast. all I need to ship is a vendor dst option and then I will go work with host vendors to adopt it too, it can be done without this but a vendor extension would be better... my solution will permit the dynamic renumbering of connections on the fly. customers want it and when they all want it and all the vendors do it, it will be a standard, regardless of what the IETF or associated factions think or not think (lots of folks are starting to think like this on a lot of topics like diff services). and mobile IP won't work your right, that binding solves a different problem space. i also give them a valid and preferred life time when the address changes if they want it. also ESP or AH can secure it...just like the mobile binding update. and lastly there is no affect to tcp or udp because of it, it just keeps on ticking and breaks no architectural purities at the transport. one of the problems with this is there are multiple ways to do this in the stack. that I don't intend to tell anyone how I do it. but folks ask that question and I say go figure it out and look at the code in your own stack. if you can convince me this is worth doing in the ietf I would ge glad to share............. it is too much work for one author that is for sure including the defense of the idea and working thru all the chaf... in the ietf, and esp those who believe they are superior beings to us normal WG grunts, will jump right into this topic and they are not fun. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 11:57:34 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA18964 for ipng-dist; Wed, 25 Mar 1998 11:54:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA18948 for ; Wed, 25 Mar 1998 11:54:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA26415 for ; Wed, 25 Mar 1998 11:54:15 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA02192 for ; Wed, 25 Mar 1998 11:54:16 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA28475; Wed, 25 Mar 1998 13:47:32 -0600 Message-Id: <199803251947.NAA28475@gungnir.fnal.gov> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5464) Re: Link-Local Address, more than one on an interface.... In-reply-to: Your message of Wed, 25 Mar 1998 14:24:12 EST. <199803251924.AA19430@wasted.zk3.dec.com> Date: Wed, 25 Mar 1998 13:47:32 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Either > the assumption is incorrect, in which case a router must keep track of > what link-local address is to be used in which advertisement, > or > we need to explicitly state that only 1 link-local address is allowed > on an interface. ... on a ROUTER interface, anyway. Matt (There exists in Scotland a sheep which is black on at least one side.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 12:37:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id MAA19069 for ipng-dist; Wed, 25 Mar 1998 12:27:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id MAA19062 for ; Wed, 25 Mar 1998 12:26:56 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id MAA27294; Wed, 25 Mar 1998 12:26:53 -0800 (PST) Date: Wed, 25 Mar 1998 12:26:50 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5465) Re: Link-Local Address, more than one on an interface.... To: bound@zk3.dec.com Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803251924.AA19430@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am sure there are many more instances, but it seems to me that > there's a strong assumption that there is only one link-local > address on a router's interface. The (perhaps too silent) assumption in RFC 1970 is that each ROUTER must have a designated link-local address per interface. This designated link-local address is used to uniquely identify the router based on the Router Advertisement and Redirect messages it is sending. And to get Redirects to work properly this designated link-local address must be the NEXT_HOP that other routers on the link use when sending redirects. This implies that the designeded link-local address must be exchanged in the routing protocols as is specified for RIPng and OSPF. But note that RFC 1970 says "the router's link local address" and does not include the word "designated". But there is nothing that would break in RFC 1970 if a router has additional (non-designated) link-local addresses. However, there is even more flexibility. You can build a router node which has multiple link-layer (Ethernet) addresses on a given interface and a link-local address for each link-layer address. Such a router could be built to essentially be a separate router instance for each Ethernet address without causing any problems with the assumptions in RFC 1970. > Either > > the assumption is incorrect, in which case a router must keep track of > what link-local address is to be used in which advertisement, Actually, it would need to use one designated link-local address in Router Advertisements, Redirects, and in the routing protocols nothion of NEXT HOP for it to work in a sensible manner. > or > > we need to explicitly state that only 1 link-local address is allowed > on an interface. Should we add the notion of a "Designated link-local address" to RFC 1970? What about my example with multiple link-layer addresses and separate router "instances" for each? Do we need to specify this complexity? Or should we say that RFC 1970 assumes that a router has exactly one link-local address per interface? (Which, in my opinion is rather different than modifying the addressing architecture to say that no node can have more than one link-local address per interface.) How about adding this to RFC 1970: In order to simplify the description of the protocol the description (NOT the protocol) assumes that a router has a single link-local address per interface. This is needed so that hosts can "match" the source address of Router Advertisement messages and the source and target addresses of Redirect messages so that a host can be redirected "away" from a router it was previously redirected "to". Routers can implement this by only allowing a single link-local address per interface, or by using a single designated link-local address per interface for all ND and routing protocol exchanges. In addition, routers which have multiple link-layer addresses per interface can have one link-local address per link-layer address if the implementation ensures enough separation between what is essentially different instances of the router for each link-layer address. Amazingly clear, isn't it? :-) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 12:45:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id MAA19137 for ipng-dist; Wed, 25 Mar 1998 12:40:53 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id MAA19127 for ; Wed, 25 Mar 1998 12:40:41 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA07232 for ; Wed, 25 Mar 1998 12:40:37 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA00719 for ; Wed, 25 Mar 1998 12:40:38 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id PAA22179; Wed, 25 Mar 1998 15:40:31 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA27777; Wed, 25 Mar 1998 15:40:27 -0500 Message-Id: <199803252040.AA27777@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5466) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 11:01:55 PST." Date: Wed, 25 Mar 1998 15:40:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Fine... On the EUI comment an adapter only had 1 ID. How can you get uniqueness once you create an address from the adpater. My point is a question of correctness to be able to take FE80:: architecture token and add anything you like to it in the low order 64bits. My impression is no? Anyway using the thinking from you, tim, margaret and matt. -----------------).......... Nothing should prevent me from having in my host don't look at prefix 3FFE because I know that prefix is bad.... I don't know why but I won't look at it anymore from ND prefix options. -----------------).............. Same for adding preferences to my default routers. The argument for the IPv4 address problem of multiple interfaces I don't take issue with. We need to support multiple addresses for unicast, anycast, and multicast. I can find reasons for all of them just like IPv4 customers did. I can't find one for LL addresses. And I am not clear the spec says we have to support them. Its not a question of work and how much its a question of extra work and is it really necessary and why would a customer use it? I got this bad habit except for coming to the IETF not doing things as an engineer customers won't use or pay for. Right now every minute and hour is precious. Putting IPng in products is a lot of work and far different than prototyping and I don't want to waste any cycles. If the WG wants to do this then thats fine, but lets make the specs very clear, so this cannot be debated again, and changed. I would like to hear from IBM, Sun, HP, SGI, Microsoft, and some other host vendors as implementors. And based on my last mail from router implementors too as it affects ND on the router too. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 13:02:29 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id MAA19165 for ipng-dist; Wed, 25 Mar 1998 12:51:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id MAA19158 for ; Wed, 25 Mar 1998 12:50:52 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA09434; Wed, 25 Mar 1998 12:50:48 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA07361; Wed, 25 Mar 1998 12:50:50 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id PAA26747; Wed, 25 Mar 1998 15:50:49 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA29008; Wed, 25 Mar 1998 15:50:47 -0500 Message-Id: <199803252050.AA29008@wasted.zk3.dec.com> To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5467) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 11:27:33 PST." Date: Wed, 25 Mar 1998 15:50:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thats valid and the best answer I got on this.......... But I do think we need to fix the specs and see the message I sent on ND and that is just one case I think ND needs fixing then. I am not going to win this battle...but I give up thinking this is bad and LL addresses are not the same architecturally as unicast, anycast, or multicast in purpose or use. Not a big deal to add it but would have been later. So better now to decide to do something bad IMO than later. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 13:17:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id NAA19379 for ipng-dist; Wed, 25 Mar 1998 13:11:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id NAA19372 for ; Wed, 25 Mar 1998 13:11:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14432 for ; Wed, 25 Mar 1998 13:11:04 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA20798 for ; Wed, 25 Mar 1998 13:11:01 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA17490; Thu, 26 Mar 1998 08:08:16 +1100 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5468) Re: Link-Local Address, more than one on an interface.... In-Reply-To: A message of "Wed, 25 Mar 1998 15:40:27 -0500." References: <199803252040.AA27777@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Mar 1998 08:08:15 +1100 Message-Id: <10717.890860095@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Mar 1998 15:40:27 -0500 From: bound@zk3.dec.com Message-ID: <199803252040.AA27777@wasted.zk3.dec.com> | How can you get | uniqueness once you create an address from the adpater. If your interface has two EUI-64's associated with it (or 3, or 32)... And in any case, link locals only need be unique on the link, I can also make them unique simply by manually assigning the things. Allow more than one, which isn't to say that implementations need necessarily support that (more than one is not a requirement). | The argument for the IPv4 address problem of multiple interfaces I don't | take issue with. We need to support multiple addresses for unicast, | anycast, and multicast. Sure, and a link-local is typically just a unicast address, though I see no reason one could not also be an anycast address (multicast has different ways of scoping). The sets link local, site local, and global (one set), and unicast, anycast, and multicast, (other set) are orthogonal. Don't attempt to make linkages between the two. | And I am not clear the spec says we have to support them. I think you're probably right, but earlier you were trying to read the spec as saying you were to be prohibited from supporting them. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 13:17:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id NAA19392 for ipng-dist; Wed, 25 Mar 1998 13:12:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id NAA19385 for ; Wed, 25 Mar 1998 13:12:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14678 for ; Wed, 25 Mar 1998 13:12:08 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA21591 for ; Wed, 25 Mar 1998 13:12:08 -0800 (PST) From: Margaret Wasserman To: bound@zk3.dec.com CC: ipng@sunroof.eng.sun.com In-reply-to: <199803251911.AA18697@wasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 5469) Re: Link-Local Address, more than one on an interface.... Date: Wed, 25 Mar 98 16:12:07 -0500 Message-ID: <9803251612.aa12891@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Give me one reason to have two of them that is useful to solve a >customer problem on a network, other than debug because I can counter >any debug in another matter and first I would like to hear the use of >them. Not because it seems and feels like we should... This is a good set of criteria to use for whether or not to include a feature in a particular implementation/product. It doesn't make sense to do extra work to implement a product feature if the target audience has no use for the feature. However, I don't think that it follows from this reasoning that all features that are not useful for a particular, well-defined, currently understood, business purpose should be forbidden by the IPv6 specifications. If there is never any reason for using multiple LL's per interface, they will never be used that way. If a use arises for them (say on a network other than ethernet, or in a special-purpose case), they can be used for that purpose. If the current specifications said "all hosts MUST allow an arbitrary number of LL addresses to be configured per interface", I would agree with you that the requirement should be removed. However, I do not agree that having multiple LL addresses per interface should be forbidden (or even recommended against) just because we can't think of a specific use for this today. What is wrong with allowing implementors to choose based upon their expected interface types, target audience, etc.? As things stand now, I believe that an implementor can decide whether or not to allow multiple LL addresses per interface. If the cost is too high for the expected return, you can only allow one LL address per interface in your implementation. If a particular product or market has a use for more than one LL address on an interface, products for that market can allow more than one. This trade-off can be made by the producers and consumers of individual products. >As far as implementation it affects all the ifnet lists in any >implementation, and then any data structures used to search interfaces >up the stack. I believe that allowing multiple LL addresses per interface will only affect the local stack, at most. Other hosts on the network (which may only allow one LL address per interface) are not required to do anything special to allow some other implementation to use two (or more) LL addresses for the same interface. Do you know of any reason why this is not the case? If not, why forbid a particular configuration choice that makes no additional requirements of a minimal stack? Since all interfaces need to support more than one address, though, allowing more than one LL address per interface hasn't actually caused any additional complexity in my particular implementation. I think it would actually cause more complexity to forbid the assignment of an additional link-local address to an interface, although that wouldn't be particularly difficult, either. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 13:57:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id NAA19655 for ipng-dist; Wed, 25 Mar 1998 13:49:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id NAA19648 for ; Wed, 25 Mar 1998 13:49:39 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA23558; Wed, 25 Mar 1998 13:49:35 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA16512; Wed, 25 Mar 1998 13:49:35 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id QAA31055; Wed, 25 Mar 1998 16:49:35 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA02577; Wed, 25 Mar 1998 16:49:33 -0500 Message-Id: <199803252149.AA02577@wasted.zk3.dec.com> To: Erik Nordmark Cc: bound@zk3.dec.com, Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: (IPng 5471) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 12:26:50 PST." Date: Wed, 25 Mar 1998 16:49:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 13:57:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id NAA19630 for ipng-dist; Wed, 25 Mar 1998 13:47:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id NAA19621 for ; Wed, 25 Mar 1998 13:47:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA22773 for ; Wed, 25 Mar 1998 13:46:59 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA14714 for ; Wed, 25 Mar 1998 13:47:00 -0800 (PST) Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3) id ; Wed, 25 Mar 1998 13:47:01 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF111229@red-msg-52.dns.microsoft.com> From: Brian Zill To: "'bound@zk3.dec.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5470) Re: Link-Local Address, more than one on an inte rface.... Date: Wed, 25 Mar 1998 13:46:56 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > I would like to hear from IBM, Sun, HP, SGI, Microsoft, and some other > host vendors as implementors. > Well, nothing in our implementation (unless we missed something) prohibits an interface from having more than one link-local address (but there currently isn't any way to set more than one). Link-local addresses are considered to be of type anycast and scope link-local (note that type anycast *is* listed in the parenthesis of the disputed clause you quoted in your earlier mail. I think this is where some of the confusion is coming from -- you seem to think of link-local addresses as being a separate type). However, I agree with Margaret that this shouldn't be a MUST, but instead implementers MAY allow for more than one link-local address per interface. That's how I read the spec now, and I don't think supporting (or not) multiple link-local addresses per interface has effects beyond the individual node that would cause interoperability problems. We should probably all think about this a moment to be sure. You're right, however, that some of the specs are written with an implicit implication that there will only be one, and we should definitely make the spec clearer on this issue. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:16:19 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA19730 for ipng-dist; Wed, 25 Mar 1998 14:05:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA19723 for ; Wed, 25 Mar 1998 14:05:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA27397 for ; Wed, 25 Mar 1998 14:05:15 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA26596 for ; Wed, 25 Mar 1998 14:05:16 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA28761; Wed, 25 Mar 1998 16:05:15 -0600 Message-Id: <199803252205.QAA28761@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5472) Re: Link-Local Address, multicast hop limit, etc Date: Wed, 25 Mar 1998 16:05:14 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is it time to start the v6 versions of 1122, 1123, and 1812 *already*? I hope not ... but some of this thread sounds like an RFC 1812 overture. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:16:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA19739 for ipng-dist; Wed, 25 Mar 1998 14:05:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA19732 for ; Wed, 25 Mar 1998 14:05:35 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA27486 for ; Wed, 25 Mar 1998 14:05:33 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA26764 for ; Wed, 25 Mar 1998 14:05:33 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id RAA13439; Wed, 25 Mar 1998 17:05:33 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04070; Wed, 25 Mar 1998 17:05:30 -0500 Message-Id: <199803252205.AA04070@wasted.zk3.dec.com> To: Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5473) Re: Link-Local Address, more than one on an inte rface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 13:46:56 PST." <4FD6422BE942D111908D00805F3158DF111229@red-msg-52.dns.microsoft.com> Date: Wed, 25 Mar 1998 17:05:30 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Brian....I have to look at that... I do view anycast and link-local as different types.... In fact anycast is not allowed for hosts right now... and if LL addresses are anycast we got big problems. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:23:29 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA19848 for ipng-dist; Wed, 25 Mar 1998 14:14:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA19841 for ; Wed, 25 Mar 1998 14:13:44 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA29524 for ; Wed, 25 Mar 1998 14:13:41 -0800 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA02396 for ; Wed, 25 Mar 1998 14:13:42 -0800 (PST) Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3) id ; Wed, 25 Mar 1998 14:08:32 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF11122A@red-msg-52.dns.microsoft.com> From: Brian Zill To: "'bound@zk3.dec.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5474) Re: Link-Local Address, more than one on an inte rface.... Date: Wed, 25 Mar 1998 14:08:29 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oops, I meant "unicast" not "anycast" here... Thanks Jim for catching that. Link-local addresses are considered to be of type anycast and scope link-local (note that type anycast *is* listed in the parenthesis of the disputed clause you quoted in your earlier mail. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:23:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA19883 for ipng-dist; Wed, 25 Mar 1998 14:17:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA19876 for ; Wed, 25 Mar 1998 14:17:22 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA00627 for ; Wed, 25 Mar 1998 14:17:20 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA04874 for ; Wed, 25 Mar 1998 14:17:19 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id RAA24573 for ; Wed, 25 Mar 1998 17:17:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA05853; Wed, 25 Mar 1998 17:17:19 -0500 Message-Id: <199803252217.AA05853@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5476) ipng mail list is kind of hosed... Date: Wed, 25 Mar 1998 17:17:19 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk folks, i sent mail in response to erik and I listed 4 ways to use multiple LL addresses... the mail came back to me but with no body only header? Anyone else actually get the mail...or is it just me? If not I will reconstruct from memory... thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:23:33 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA19857 for ipng-dist; Wed, 25 Mar 1998 14:15:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA19850 for ; Wed, 25 Mar 1998 14:14:54 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA29963 for ; Wed, 25 Mar 1998 14:14:52 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA03251 for ; Wed, 25 Mar 1998 14:14:53 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id RAA14477; Wed, 25 Mar 1998 17:14:52 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA05604; Wed, 25 Mar 1998 17:14:46 -0500 Message-Id: <199803252214.AA05604@wasted.zk3.dec.com> To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5475) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 16:12:07 EST." <9803251612.aa12891@khitomer.epilogue.com> Date: Wed, 25 Mar 1998 17:14:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is a good set of criteria to use for whether or not to include >a feature in a particular implementation/product. It doesn't >make sense to do extra work to implement a product feature if the >target audience has no use for the feature. >However, I don't think that it follows from this reasoning that all >features that are not useful for a particular, well-defined, currently >understood, business purpose should be forbidden by the IPv6 >specifications. If there is never any reason for using multiple LL's >per interface, they will never be used that way. If a use arises for >them (say on a network other than ethernet, or in a special-purpose >case), they can be used for that purpose. Well this could just be me. I am not to interested in things if they don't solve a business problem. So I don't agree with the above. But thats just me. But I will do things to help solve future business problems if I can perceive them. It is just with multiple LLs I can't see them. If others can see it fine, I would love to hear them. THe IETF is not a research effort nor the IRTF it is to solve real problems and catch any future problems if we can. I don't see that with multiple LL addresses is what I am saying. Put another way if you came to me as an engineer to get funding to work on something I would want to know what I was getting for my money. What will anyone get from multiple LL addresses. I think the answer I am hearing to me is insurance via flexibility. Well I am just checking anything these days that is insurance funded and no ROI in site (by the way we got to define what the heck a site is too in another thread)......... I did just send eric and the list cases where they can be used but that could be a bad thing. And some mail on the evils of flexibility. But I am seeing some of the mail get chopped up on this list now???? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:44:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA20001 for ipng-dist; Wed, 25 Mar 1998 14:34:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA19994 for ; Wed, 25 Mar 1998 14:34:09 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA04756 for ; Wed, 25 Mar 1998 14:34:07 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA15491 for ; Wed, 25 Mar 1998 14:34:08 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id XAA12122; Wed, 25 Mar 1998 23:34:07 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA31648; Wed, 25 Mar 1998 23:34:05 +0100 (MET) Message-Id: <199803252234.XAA31648@givry.inria.fr> From: Francis Dupont To: bound@zk3.dec.com cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: (IPng 5477) Re: Link-Local Address, more than one on an inte rface.... In-reply-to: Your message of Wed, 25 Mar 1998 17:05:30 EST. <199803252205.AA04070@wasted.zk3.dec.com> Date: Wed, 25 Mar 1998 23:34:04 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: thanks Brian....I have to look at that... I do view anycast and link-local as different types.... In fact anycast is not allowed for hosts right now... and if LL addresses are anycast we got big problems. => but the main example of an anycast address is a LL one (fe80::) ?! Francis.Dupont@inria.fr PS: about link-local, I believe it SHOULD be only one (or one MUST have a way to say which one is the "designated" one) but I don't see a good reason to add a "MUST NOT" for multiple LL addresses per interface (it should work even it is not useful (ie just annoying :-) in the general case). Note if you use a MAC address bank as some Cisco routers and many ATM NICs it is possible to have many EUI-64 per physical interfaces (for instance a DEC DGLPB ATM interface has 8 MAC addresses :-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:55:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA20123 for ipng-dist; Wed, 25 Mar 1998 14:46:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA20115 for ; Wed, 25 Mar 1998 14:46:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA07790 for ; Wed, 25 Mar 1998 14:46:03 -0800 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA22846 for ; Wed, 25 Mar 1998 14:46:04 -0800 (PST) Received: from red.juniper.net (localhost.juniper.net [127.0.0.1]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id OAA07443; Wed, 25 Mar 1998 14:44:32 -0800 (PST) Message-Id: <199803252244.OAA07443@red.juniper.net> To: bound@zk3.dec.com cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: (IPng 5478) Re: Link-Local Address, more than one on an inte rface.... In-reply-to: Your message of "Wed, 25 Mar 1998 17:05:30 EST." <199803252205.AA04070@wasted.zk3.dec.com> X-Phone: +1 650 526 7924 Date: Wed, 25 Mar 1998 14:44:31 -0800 From: "John W. Stewart III" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > thanks Brian....I have to look at that... I do view anycast and > link-local as different types.... In fact anycast is not allowed for > hosts right now... and if LL addresses are anycast we got big problems. I don't understand why a link-local would be considered anycast. Scope and uni/multi/any-cast are different dimensions. Besides, the addressing architecture precludes an anycast address from being used as a source address. Not being able to put the link-local address in the source address field of a packet destined for an on-link node would be, err, problematic. Confused, /jws -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:55:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA20132 for ipng-dist; Wed, 25 Mar 1998 14:46:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA20125 for ; Wed, 25 Mar 1998 14:46:27 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA07888 for ; Wed, 25 Mar 1998 14:46:25 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA23068 for ; Wed, 25 Mar 1998 14:46:25 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id RAA08424; Wed, 25 Mar 1998 17:46:24 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03252; Wed, 25 Mar 1998 17:46:24 -0500 Message-Id: <199803252246.AA03252@wasted.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5479) Re: Link-Local Address, multicast hop limit, etc In-Reply-To: Your message of "Wed, 25 Mar 1998 16:05:14 CST." <199803252205.QAA28761@gungnir.fnal.gov> Date: Wed, 25 Mar 1998 17:46:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Yep... you got it. 1122, 1123, 1812... are all IMO moot for IPv6 and I have said this about 1122 and 1123 4 years ago. this is a big job............. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 14:55:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id OAA20149 for ipng-dist; Wed, 25 Mar 1998 14:48:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id OAA20138 for ; Wed, 25 Mar 1998 14:47:54 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA08271 for ; Wed, 25 Mar 1998 14:47:51 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA23975 for ; Wed, 25 Mar 1998 14:47:52 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id RAA04040; Wed, 25 Mar 1998 17:47:51 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09939; Wed, 25 Mar 1998 17:47:51 -0500 Message-Id: <199803252247.AA09939@wasted.zk3.dec.com> To: Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5480) Re: Link-Local Address, more than one on an inte rface.... In-Reply-To: Your message of "Wed, 25 Mar 1998 17:05:30 EST." <199803252205.AA04070@wasted.zk3.dec.com> Date: Wed, 25 Mar 1998 17:47:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, that is a good point... LL = unicast, next sentence has unicast inclusive. good catch... still have to look at all the specs....to see affect what we have learned from this....... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 15:11:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id PAA20369 for ipng-dist; Wed, 25 Mar 1998 15:05:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id PAA20361 for ; Wed, 25 Mar 1998 15:05:24 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA14368; Wed, 25 Mar 1998 15:04:53 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA04435; Wed, 25 Mar 1998 15:04:37 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id SAA22314; Wed, 25 Mar 1998 18:04:35 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10548; Wed, 25 Mar 1998 18:04:29 -0500 Message-Id: <199803252304.AA10548@wasted.zk3.dec.com> To: Erik Nordmark Cc: bound@zk3.dec.com, Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: (IPng 5481) Re: Link-Local Address, more than one on an interface In-Reply-To: Your message of "Wed, 25 Mar 1998 12:26:50 PST." Date: Wed, 25 Mar 1998 18:04:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RECONSTRUCTED as I best I can recall (yes it got lost in the cosmic bit bucket)............. >How about adding this to RFC 1970: In order to simplify the description of the protocol the description (NOT the protocol) assumes that a router has a single link-local address per interface. This is needed so that hosts can "match" the source address of Router Advertisement messages and the source and target addresses of Redirect messages so that a host can be redirected "away" from a router it was previously redirected "to". Routers can implement this by only allowing a single link-local address per interface, or by using a single designated link-local address per interface for all ND and routing protocol exchanges. In addition, routers which have multiple link-layer addresses per interface can have one link-local address per link-layer address if the implementation ensures enough separation between what is essentially different instances of the router for each link-layer address. >Amazingly clear, isn't it? :-) Yep... We have now deprecated to supporting IPv4 primary and aliases addresses for IPv6 ------------)........... But this is what we have to say. We need to check all of ND and Addrconf and I think most specs to make sure of the behavior now if multiple LLs are in fact permitted. Also when a host becomes a router then a host and then a router in ND needs thought too and the affect to LL addresses. Four examples of multiple LL addresses use: 1. wall socket - one LL for 100Watts and one LL for 220Watts 2. icbm - one LL for failsafe and one LL for not failsafe (let it rip). 3. cable receiver - one LL for video and one LL for audio 4. cable programming - one LL for PG and one LL for XXX rating. But is this a good thing? Do we want to promote this behavior? When viewing things from a business perspective you can do it with ethics or without ethics... So the question above is for one with ethics....is this the most cost efficient way to produce such behavior for all concerned???? We need to put the same controls on the IP Next Generation Protocol as we do on our dogs, plants, and other entities in our life or chaos will result. A little chaos is OK like a little stress. When flexibility results in lots of chaos it is a bad thing. I will keep my second IPv6 I-TOLD-YOU-SO card on this one and save it for later. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 25 16:28:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id QAA21035 for ipng-dist; Wed, 25 Mar 1998 16:22:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id QAA21028 for ; Wed, 25 Mar 1998 16:21:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA06273 for ; Wed, 25 Mar 1998 16:21:48 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with SMTP id QAA23255 for ; Wed, 25 Mar 1998 16:21:50 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id QAA25292; Wed, 25 Mar 1998 16:20:41 -0800 Message-Id: <3.0.5.32.19980325161950.009a8da0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 25 Mar 1998 16:19:50 -0800 To: Jeffrey Burgan , narten@raleigh.ibm.com From: Bob Hinden Subject: (IPng 5482) Request to Advance IPv6 Documents to Draft Standard Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following documents be published as Draft Standards: Title : Internet Protocol, Version 6 (IPv6) Specification Author(s) : S. Deering, R. Hinden Filename : draft-ietf-ipngwg-ipv6-spec-v2-01.txt Date : 04-Dec-97 This will replace RFC 1883 Title : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v2-00.txt Date : 27-Oct-97 This will replace RFC 1885 RFC 1981: Title : Path MTU Discovery for IP version 6 Author(s) : J. McCann, S. Deering, J. Mogul Date : August 1996 Implementation reports for each of these protocols can be found at: ftp://playground.sun.com/pub/ipng/implementation-reports/ Working group last calls were completed for these document and they were discussed at the last two IETF meetings. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 05:22:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id FAA21786 for ipng-dist; Thu, 26 Mar 1998 05:15:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id FAA21779 for ; Thu, 26 Mar 1998 05:15:23 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA05791 for ; Thu, 26 Mar 1998 05:15:20 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA25582 for ; Thu, 26 Mar 1998 05:15:22 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id IAA18519; Thu, 26 Mar 1998 08:15:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21680; Thu, 26 Mar 1998 08:15:17 -0500 Message-Id: <199803261315.AA21680@wasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5484) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Thu, 26 Mar 1998 08:08:15 +1100." <10717.890860095@munnari.OZ.AU> Date: Thu, 26 Mar 1998 08:15:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | And I am not clear the spec says we have to support them. >I think you're probably right, but earlier you were trying to read the >spec as saying you were to be prohibited from supporting them. Agreed. But I think with all the changes that will be required to support them in ND and addrconf and elsewhere, I suggest our intent was to not permit them and now that I bring this up everyone wants them, just in case. This is exactly the behavior of any org entity in the nor IMO, and one of my frustrations consistently in the IETF. This is tough. But how about "whats a site" we are told implement this yet no one can tell us what it is? More IETF charlie brown security blanket thinking. Your a wuss charlie brown ---------)........ /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 05:24:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id FAA21797 for ipng-dist; Thu, 26 Mar 1998 05:20:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id FAA21790 for ; Thu, 26 Mar 1998 05:20:48 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA06115 for ; Thu, 26 Mar 1998 05:20:45 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA27866 for ; Thu, 26 Mar 1998 05:20:47 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id IAA13825 for ; Thu, 26 Mar 1998 08:20:46 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA29593; Thu, 26 Mar 1998 08:20:46 -0500 Message-Id: <199803261320.AA29593@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5485) Re: What is a site in IPv6 ??? In-Reply-To: Your message of "Tue, 24 Mar 1998 23:47:23 EST." <199803250447.AA10005@wasted.zk3.dec.com> Date: Thu, 26 Mar 1998 08:20:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maybe what is a site needs to be on the agenda. We have: 1. I think stated consenus is we need site-local addresses. 2. There is a spec on converting addresses to site-local. 3. We have defined reserved bit patterns for site addresses with IANA. 4. And most importantly we tell implmentors to implement conditions based on site-local addresses, and it has a multicast condition. But we have not stated what is a site? I made a suggestion.. Lets fix this........or get rid of them. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 05:53:51 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id FAA21846 for ipng-dist; Thu, 26 Mar 1998 05:47:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id FAA21839 for ; Thu, 26 Mar 1998 05:47:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA08144 for ; Thu, 26 Mar 1998 05:47:15 -0800 Received: from mti6000.zfm.com (mti6000.zfm.com [206.0.67.254]) by earth.sun.com (8.8.8/8.8.8) with SMTP id FAA09576 for ; Thu, 26 Mar 1998 05:47:11 -0800 (PST) Received: from mtint.zfm.com by mti6000.zfm.com with smtp (Smail3.1.28.1 #4) id m0yICnE-0004LCC; Thu, 26 Mar 98 10:34 GRNLNDST Received: by MTINT with Internet Mail Service (5.0.1458.49) id ; Thu, 26 Mar 1998 10:46:24 -0300 Message-ID: <5D4FD0036882D011A9400060940A770D03650C@MTINT> From: Alberto Abudara To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5486) Protocol Analyzer Date: Thu, 26 Mar 1998 10:46:22 -0300 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello ! Does anyone knows where I can find a protocol analyzer for IPv6 working in Windows NT or Linux ? Regards, Alberto. ------------------------------------------------------------------------ ------------------------ Alberto Abudara Montevideo, URUGUAY - South America Montevideo Teleport International, ZONA FRANCA DE MONTEVIDEO RUTA 8 Km 17.500 Loc. 123 email: aabudara@zfm.com voice +598 982 2000 x 5728 fax +598 982 2000 x 5274 ------------------------------------------------------------------------ -------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 06:54:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA22016 for ipng-dist; Thu, 26 Mar 1998 06:49:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA22009 for ; Thu, 26 Mar 1998 06:49:48 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA17433 for ; Thu, 26 Mar 1998 06:49:45 -0800 Received: from mti6000.zfm.com (mti6000.zfm.com [206.0.67.254]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA12958 for ; Thu, 26 Mar 1998 06:49:45 -0800 (PST) Received: from mtint.zfm.com by mti6000.zfm.com with smtp (Smail3.1.28.1 #4) id m0yIDlv-0004KSC; Thu, 26 Mar 98 11:36 GRNLNDST Received: by MTINT with Internet Mail Service (5.0.1458.49) id ; Thu, 26 Mar 1998 11:49:07 -0300 Message-ID: <5D4FD0036882D011A9400060940A770D03650E@MTINT> From: Alberto Abudara To: "'Mark A. Miller'" , Alberto Abudara Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5488) RE: Protocol Analyzer Date: Thu, 26 Mar 1998 11:49:05 -0300 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there any place to download it ? By the way , is there any stack IPv6 for Windows 95 ? Regards, Alberto > -----Mensaje original----- > De: Mark A. Miller [SMTP:mark@diginet.com] > Enviado el: Jueves 26 de Marzo de 1998 08:47 AM > Para: Alberto Abudara > CC: 'ipng@sunroof.eng.sun.com' > Asunto: Re: (IPng 5486) Protocol Analyzer > > Alberto: > > Wandel & Goltermann's Domino analyzer runs on Windows 95, and has IPv6 > decodes available. I am not aware of any other analyzers that support > IPv6 at this time. > > Regards, > > Mark > > ********************************************************************** > ***** > Mark A. Miller Tel: > 303.682.5244 > DigiNet Corporation Fax: > 303.682.2654 > 5310 St. Vrain Road Email: > mark@diginet.com > Longmont, CO 80503 > http://www.diginet.com > ********************************************************************** > ***** > > On Thu, 26 Mar 1998, Alberto Abudara wrote: > > > Hello ! > > Does anyone knows where I can find a protocol analyzer for IPv6 > working > > in Windows NT or Linux ? > > Regards, > > Alberto. > > > > > ---------------------------------------------------------------------- > -- > > ------------------------ > > Alberto Abudara > > Montevideo, URUGUAY - South America > > Montevideo Teleport International, > > ZONA FRANCA DE MONTEVIDEO > > RUTA 8 Km 17.500 Loc. 123 > > email: aabudara@zfm.com > > voice +598 982 2000 x 5728 > > fax +598 982 2000 x 5274 > > > ---------------------------------------------------------------------- > -- > > -------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 07:02:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id GAA22035 for ipng-dist; Thu, 26 Mar 1998 06:59:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA22028 for ; Thu, 26 Mar 1998 06:59:01 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA19846 for ; Thu, 26 Mar 1998 06:58:57 -0800 Received: from james.kalifornia.com (james.kalifornia.com [207.213.0.47]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA18880 for ; Thu, 26 Mar 1998 06:58:59 -0800 (PST) Received: from james.kalifornia.com (david@james.kalifornia.com [207.213.0.47]) by james.kalifornia.com (8.8.5-r-beta/8.8.7) with SMTP id GAA12030 for ; Thu, 26 Mar 1998 06:58:58 -0800 Date: Thu, 26 Mar 1998 06:58:58 -0800 (PST) From: Blu3Viper To: ipng@sunroof.eng.sun.com Subject: (IPng 5489) Re: Protocol Analyzer In-Reply-To: <5D4FD0036882D011A9400060940A770D03650E@MTINT> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 26 Mar 1998, Alberto Abudara wrote: > > Wandel & Goltermann's Domino analyzer runs on Windows 95, and has IPv6 > > decodes available. I am not aware of any other analyzers that support > > IPv6 at this time. does it come as source so it may be ported? -d Look, look, see Windows 95. Buy, lemmings, buy! (c) 1998 David Ford. Redistribution via the Microsoft Network is prohibited. [reply to: david@127-0-0-1.kalifornia.com without the 127-0-0-1.] *** *** Flames will go to /dev/null ** WARNING ** SPAM mail will be returned to you at a *** *** minimum rate of 50,000 copies per email -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 07:39:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id HAA22097 for ipng-dist; Thu, 26 Mar 1998 07:31:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id HAA22090 for ; Thu, 26 Mar 1998 07:31:23 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA28109 for ; Thu, 26 Mar 1998 07:31:21 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA08641 for ; Thu, 26 Mar 1998 07:31:20 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA00313; Thu, 26 Mar 1998 09:24:36 -0600 Message-Id: <199803261524.JAA00313@gungnir.fnal.gov> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5490) Re: Link-Local Address, more than one on an interface.... In-reply-to: Your message of Thu, 26 Mar 1998 08:15:17 EST. <199803261315.AA21680@wasted.zk3.dec.com> Date: Thu, 26 Mar 1998 09:24:36 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is tough. But how about "whats a site" we are told implement this > yet no one can tell us what it is? More IETF charlie brown security > blanket thinking. Don't neglect the possibility (just the possibility) that site does not need to be defined. It could be that "site" is best left as "whatever the network manager says is a site." Sure, there would be some self-evident guidelines, such as "a site should be a connected set of links and nodes." Or maybe it does need to be defined. I haven't made up my mind. But I do know one thing: it was Linus van Pelt, not Charlie Brown who had the security blanket. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 08:03:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id HAA22151 for ipng-dist; Thu, 26 Mar 1998 07:56:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id HAA22144 for ; Thu, 26 Mar 1998 07:56:23 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA05605 for ; Thu, 26 Mar 1998 07:56:20 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA24200 for ; Thu, 26 Mar 1998 07:56:21 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA04663; Thu, 26 Mar 1998 07:49:39 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199803261315.AA21680@wasted.zk3.dec.com> References: Your message of "Thu, 26 Mar 1998 08:08:15 +1100." <10717.890860095@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Mar 1998 07:50:48 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 5491) Re: Link-Local Address, more than one on an interface.... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:15 AM -0800 3/26/98, bound@zk3.dec.com wrote: > Agreed. But I think with all the changes that will be required to > support them in ND and addrconf and elsewhere, The changes in the specs are trivial -- just editorial corrections. > I suggest our intent was to not permit them... That was not the intent of the authors who wrote those specs. It was simply that, since in the normal case we expect interfaces to have only one LL address, we forgot about the plural case. The moment you pointed out the ambiguity, we were able to tell you what our intent was. > This is exactly the behavior of any org entity in the > nor IMO, and one of my frustrations consistently in the IETF. This is the value of the IETF: improving the quality of specs and the chances of interoperability by broad review by a variety of people, to ferret out bugs/ambiguities/oversights in those specs. > This is tough. But how about "whats a site" we are told implement this > yet no one can tell us what it is? The short answer is: a site is whatever turns out to be convenient or useful for any specific customer. The long answer, at least from me, will have to wait until next week, because I'm busy attending a workshop all day today and tomorrow, and don't have time to compose a long message. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 08:09:29 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA22207 for ipng-dist; Thu, 26 Mar 1998 08:06:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA22200 for ; Thu, 26 Mar 1998 08:06:12 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA08457 for ; Thu, 26 Mar 1998 08:06:10 -0800 Received: from att.com (kcgw2.att.com [192.128.133.152]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA00319 for ; Thu, 26 Mar 1998 08:06:11 -0800 (PST) Received: by kcgw2.att.com; Thu Mar 26 09:48 CST 1998 Received: from frgmsx1.de.att.com (frgmsx1.de.att.com [135.76.188.33]) by kcig2.att.att.com (AT&T/GW-1.0) with ESMTP id KAA01141 for ; Thu, 26 Mar 1998 10:06:04 -0600 (CST) Received: by frgmsx1.de.att.com with Internet Mail Service (5.0.1458.49) id ; Thu, 26 Mar 1998 17:06:36 +0100 Message-ID: From: "Buclin, Bertrand" To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5492) Re: Link-Local Address, more than one on an inter face.... Date: Thu, 26 Mar 1998 17:06:35 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, What about a node running DECnet: its interface has two MAC addresses (the physical and the DECnet one). Why not allowing to use a link local with the ID derived from the DECnet MAC address ? (actually some of your colleagues might be tempted to do that for DECnet Phase VI :-). In general, if it is accepted that an interface can have several MAC addresses, then if that interface is attached to a node running IPv6, nothing should prevent the use of any of the MAC addresses to build the LL address, and furtherore why not build several LL addresses to reflect each MAC address this interface is supporting. Cheers, Bertrand -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 08:23:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA22247 for ipng-dist; Thu, 26 Mar 1998 08:15:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA22240 for ; Thu, 26 Mar 1998 08:15:26 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA10960 for ; Thu, 26 Mar 1998 08:15:24 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA06259 for ; Thu, 26 Mar 1998 08:15:24 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id LAA65214; Thu, 26 Mar 1998 11:11:54 -0500 (EST) Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA34092; Thu, 26 Mar 1998 11:11:54 -0500 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24338; Thu, 26 Mar 1998 11:12:22 -0500 Message-Id: <351A7E66.445B5637@raleigh.ibm.com> Date: Thu, 26 Mar 1998 11:12:22 -0500 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Matt Crawford Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5493) Re: Link-Local Address, more than one on an interface.... References: <199803261524.JAA00313@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford wrote: > > Don't neglect the possibility (just the possibility) that site does > not need to be defined. It could be that "site" is best left as > "whatever the network manager says is a site." Sure, there would be > some self-evident guidelines, such as "a site should be a connected > set of links and nodes." Matt, I believe it does need to be defined. At the implementation level, you have to represent a site in some way, especially for routers that sit at site boundaries (i.e. a router that has inter- faces on different sites). If we don't define a site identifier, implementations will choose their own mechanism for defining sites. And this will lead to inter-operability problems for network admins. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 08:53:10 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA22326 for ipng-dist; Thu, 26 Mar 1998 08:48:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA22319 for ; Thu, 26 Mar 1998 08:48:11 -0800 (PST) From: RAMAMIRTHAM@PROCESS.COM Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA18710 for ; Thu, 26 Mar 1998 08:48:09 -0800 Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA27470 for ; Thu, 26 Mar 1998 08:48:09 -0800 (PST) Date: Thu, 26 Mar 1998 11:48 -0500 Message-Id: <009C3C3581B59966.49E1@PROCESS.COM> To: Bertrand.Buclin@ch.att.com, IPNG@sunroof.eng.sun.com Subject: (IPng 5494) Re: Link-Local Address, more than one on an inter face.... X-VMS-To: SMTP%"Bertrand.Buclin@ch.att.com" X-VMS-Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What about a node running DECnet: its interface has two MAC addresses >(the physical and the DECnet one). Why not allowing to use a link local >with the ID derived from the DECnet MAC address ? (actually some of your >colleagues might be tempted to do that for DECnet Phase VI :-). Actually we have derived LL addresses from the DECnet MAC address and it works just fine! The only minor problem we face was at the last Connectathon, held earlier this month, when the UNH test suite barfed upon seeing the "AA-" in the MAC address. --Ravi Ramamirtham Process Software Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 08:57:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id IAA22378 for ipng-dist; Thu, 26 Mar 1998 08:54:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id IAA22371 for ; Thu, 26 Mar 1998 08:54:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA20165 for ; Thu, 26 Mar 1998 08:54:03 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA01212 for ; Thu, 26 Mar 1998 08:53:59 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id QAA20378; Thu, 26 Mar 1998 16:52:20 GMT Message-Id: <199803261652.QAA20378@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 26 Mar 1998 16:54:36 +0000 To: Alberto Abudara From: Peter Curran Subject: (IPng 5495) Re: Protocol Analyzer Cc: "'Mark A. Miller'" , Alberto Abudara , "'ipng@sunroof.eng.sun.com'" In-Reply-To: <5D4FD0036882D011A9400060940A770D03650E@MTINT> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >> Wandel & Goltermann's Domino analyzer runs on Windows 95, and has IPv6 >> decodes available. I am not aware of any other analyzers that support >> IPv6 at this time. >> Precision Guesswork have a version of LanWatch that supports IPv6. It is Beta code for Windoze 95/NT and is currently a freeby demo. Try http://www.guesswork.com/demo.html#lw32demo Also, for the real-mode (DOS) version of LanWatch (version 3.0, 4.0 and 4.1), we have a set of v6 parsers that can be installed. IMHO they are far more complete than the 'official' version in the LanWatch32 Beta - they handle IPsec, tunnelling and proper decode of RA. You can download this from http://www.ipv6.ticl.co.uk/devpv6.htm You can run regular LanWatch under Win95 using a Vxd packet driver interface. Cheers Peter TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:12:23 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22400 for ipng-dist; Thu, 26 Mar 1998 09:06:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA22393 for ; Thu, 26 Mar 1998 09:06:46 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA23473 for ; Thu, 26 Mar 1998 09:06:44 -0800 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA09906 for ; Thu, 26 Mar 1998 09:06:43 -0800 (PST) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id JAA16011; Thu, 26 Mar 1998 09:06:41 -0800 (PST) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.6.9) id JAA28500; Thu, 26 Mar 1998 09:06:37 -0800 (PST) From: Vivek Kashyap Message-Id: <199803261706.JAA28500@eng4.sequent.com> Subject: (IPng 5496) Re: Request to Advance IPv6 Documents to Draft Standard To: hinden@iprg.nokia.com (Bob Hinden) Date: Thu, 26 Mar 1998 09:06:36 -0800 (PST) Cc: burgan@corp.home.net, narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com, viv@sequent.com (Vivek Kashyap) In-Reply-To: <3.0.5.32.19980325161950.009a8da0@mailhost.iprg.nokia.com> from "Bob Hinden" at Mar 25, 98 04:19:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Jeff, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following documents be published as > Draft Standards: > > Title : Internet Protocol, Version 6 (IPv6) Specification > Author(s) : S. Deering, R. Hinden > Filename : draft-ietf-ipngwg-ipv6-spec-v2-01.txt > Date : 04-Dec-97 > > This will replace RFC 1883 > > > Title : Internet Control Message Protocol (ICMPv6) > for the Internet Protocol Version 6 (IPv6) > Specification > Author(s) : A. Conta, S. Deering > Filename : draft-ietf-ipngwg-icmp-v2-00.txt > Date : 27-Oct-97 > > This will replace RFC 1885 > > > RFC 1981: > Title : Path MTU Discovery for IP version 6 > Author(s) : J. McCann, S. Deering, J. Mogul > Date : August 1996 > I am not sure of the procedure/process, (I have joined this group only a month back), but since this is relevant : I have recently (approx. a month back) written a draft that requests a change in the ICMP 'datagram too big' error message with a view to allow per net routes while attempting Path mtu discovery as against always using per host routes. The change is useful in situations with 1000s of hosts, but as is usually the case, only a few routes. The draft is : Modification in Datagram Too Big message Thanks Vivek > Implementation reports for each of these protocols can be found at: > > ftp://playground.sun.com/pub/ipng/implementation-reports/ > > Working group last calls were completed for these document and they were > discussed at the last two IETF meetings. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Vivek Kashyap viv@sequent.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:15:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22432 for ipng-dist; Thu, 26 Mar 1998 09:12:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA22423 for ; Thu, 26 Mar 1998 09:12:19 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA04309 for ; Thu, 26 Mar 1998 09:12:18 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA17127 for ipng@sunroof.eng.sun.com; Thu, 26 Mar 1998 09:12:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id SAA21379 for ; Wed, 25 Mar 1998 18:50:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA15986 for ; Wed, 25 Mar 1998 18:50:04 -0800 Received: from vacation.karoshi.com (vacation.karoshi.com [128.9.104.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA16811 for ; Wed, 25 Mar 1998 18:02:32 -0800 (PST) Received: (from bmanning@localhost) by vacation.karoshi.com (8.8.7/8.8.7) id KAA00914; Wed, 25 Mar 1998 10:02:17 -0800 From: Bill Manning Message-Id: <199803251802.KAA00914@vacation.karoshi.com> Subject: (IPng 5497) Re: Transparent Renumbering? To: soule@math.brown.edu (Steve Soule) Date: Wed, 25 Mar 1998 10:02:16 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199803251825.KAA02332@earth.sun.com> from "Steve Soule" at Mar 25, 98 01:25:54 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Is anyone working on a "Transparent Renumbering" draft? That is, a > system by which a node's (or group of nodes) IP address may change > without losing any of its connections, TCP, UDP, or other? I don't > mean MobileIP; I mean a permanent change. > > If the answer is no, no one's working on this: > I have some ideas on this subject. Would anyone be interested in > discussing them with me at length? There have been a number of attempts at this over the past few years. One of the most recent is Christians now expired draft. My favorite is using a variable length thing. You might review the NIMROD work as well -- --bill Silence is _NOT_ consent. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:26:16 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22506 for ipng-dist; Thu, 26 Mar 1998 09:19:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA22498 for ; Thu, 26 Mar 1998 09:19:01 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA26554 for ; Thu, 26 Mar 1998 09:18:58 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA18109 for ; Thu, 26 Mar 1998 09:18:59 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id MAA02616; Thu, 26 Mar 1998 12:18:55 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19118; Thu, 26 Mar 1998 12:18:50 -0500 Message-Id: <199803261718.AA19118@wasted.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5498) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Thu, 26 Mar 1998 09:24:36 CST." <199803261524.JAA00313@gungnir.fnal.gov> Date: Thu, 26 Mar 1998 12:18:50 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Thats fine for the net manager? But how do I know when I write code for example on rtr renumbering spec (and I am not picking on you spec) what I do with the 'if', 'switch' and other constructs for the "condition" to test if an interface is in another site. My fix would work too. Then I could at least do a best guess that the sla's are different and I can condition code test that case, and set a policy switch from the user to perform that type of test. But we need some ruleset here to implement "something".... thanks for the ack on charlie brown et al...I was winging it I don't really read it sometimes I see it on tv at friends with kids... thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:27:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22524 for ipng-dist; Thu, 26 Mar 1998 09:22:48 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA22517 for ; Thu, 26 Mar 1998 09:22:41 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id JAA05726 for ; Thu, 26 Mar 1998 09:22:41 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA17162 for ipng@sunroof.eng.sun.com; Thu, 26 Mar 1998 09:22:36 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id GAA21997 for ; Thu, 26 Mar 1998 06:47:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA16857 for ; Thu, 26 Mar 1998 06:47:16 -0800 Received: from teal.csn.net (teal.csn.net [199.117.27.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA11353 for ; Thu, 26 Mar 1998 06:47:17 -0800 (PST) Received: (from mark@localhost) by teal.csn.net (8.8.5/8.6.9) id HAA02892; Thu, 26 Mar 1998 07:47:10 -0700 (MST) Date: Thu, 26 Mar 1998 07:47:10 -0700 (MST) From: "Mark A. Miller" Subject: (IPng 5499) Re: Protocol Analyzer To: Alberto Abudara cc: "'ipng@sunroof.eng.sun.com'" In-Reply-To: <5D4FD0036882D011A9400060940A770D03650C@MTINT> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alberto: Wandel & Goltermann's Domino analyzer runs on Windows 95, and has IPv6 decodes available. I am not aware of any other analyzers that support IPv6 at this time. Regards, Mark *************************************************************************** Mark A. Miller Tel: 303.682.5244 DigiNet Corporation Fax: 303.682.2654 5310 St. Vrain Road Email: mark@diginet.com Longmont, CO 80503 http://www.diginet.com *************************************************************************** On Thu, 26 Mar 1998, Alberto Abudara wrote: > Hello ! > Does anyone knows where I can find a protocol analyzer for IPv6 working > in Windows NT or Linux ? > Regards, > Alberto. > > ------------------------------------------------------------------------ > ------------------------ > Alberto Abudara > Montevideo, URUGUAY - South America > Montevideo Teleport International, > ZONA FRANCA DE MONTEVIDEO > RUTA 8 Km 17.500 Loc. 123 > email: aabudara@zfm.com > voice +598 982 2000 x 5728 > fax +598 982 2000 x 5274 > ------------------------------------------------------------------------ > -------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:31:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22555 for ipng-dist; Thu, 26 Mar 1998 09:27:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA22548 for ; Thu, 26 Mar 1998 09:27:24 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28915 for ; Thu, 26 Mar 1998 09:27:21 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id JAA24439 for ; Thu, 26 Mar 1998 09:27:21 -0800 (PST) From: Margaret Wasserman To: ipng@sunroof.eng.sun.com In-reply-to: (message from Erik Nordmark on Wed, 25 Mar 1998 12:26:50 -0800 (PST)) Subject: (IPng 5500) Re: Link-Local Address, more than one on an interface.... Date: Thu, 26 Mar 98 12:27:15 -0500 Message-ID: <9803261227.aa17949@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The (perhaps too silent) assumption in RFC 1970 is that each ROUTER >must have a designated link-local address per interface. This designated >link-local address is used to uniquely identify the router based on >the Router Advertisement and Redirect messages it is sending. Several parts of the recent discussion on this list surround one of the trickiest parts of IPv6. The discussion has limited itself, so far, to specific cases, but the meta-issue is unique, one-to-one node or interface identification. Although any IPv6 unicast address does map to a single interface on a single node, there is no one-to-one mapping. Jim had suggested creating a one-to-one mapping for link-local addresses, but that wouldn't solve the problem for other address scopes, as there is no reliable way to connect (or convert between) a node's different unicast addresses. Since ALL internet connected IPv6 nodes will have at least two addresses visible to neighboring nodes (the link-local address and the global address), and there is no way to safely convert between those addresses, we run into a bunch of interesting questions regarding how those nodes (or interfaces) can/should be identified for different purposes. Although there is no true one-to-one mapping in IPv4 (an interface *can* have more than one IPv4 address), most interfaces only have one address. Also, most hosts only have one physical interface, so there is the *illusion* of a one-to-one mapping between IP addresses and nodes. A node with two IPv4 addresses will be treated as two separate nodes by all other IPv4 implementations. This behaviour is nicely exploited when using task-specific domain names (such as www.epilogue.com) to identify the machine currently handling a specific task, but has also caused a great deal of pain and agony throughout the years. DNS clearly works best where there is a one-to-one mapping between hosts and IPv4 addresses. Most routing protocols (and host-router interactions) clearly expect a one-to-one mapping between IP addresses and interfaces. I think this is a large part of why we've had some much trouble in these two areas for IPv6. The common cases where IPv4 nodes are assigned more than one IPv4 address are routers and multi-faced servers (non-router, multihomed hosts). In both cases, there is generally one IPv4 address assigned per interface. Other nodes do not have a method of determining which interfaces are shared by the same node, but this is not usually a problem, as most nodes only want to communicate with the "closest" interface (presumably a link-local interface, in the router case). The multi-faced server concept has never been well supported by IPv4, but is in wide-spread use, anyway. The burden falls on the system administrators or individual users to assure that all nodes that use the multi-faced node are configured to use the "right" address for the node. This leads to a great deal of pain and inefficiency which I still wish that IPv6 could alleviate (although that was another discussion). Protocols which deal with IPv4 routers (such as the IPv4 version of Router Discovery, IPv4 Routing Protocols, etc.) make the assumption that there is a one-to-one mapping between router interfaces and IPv4 addresses. Furthermore, they make the assumption that an IPv4 host will only ever see one "side" of a given router. So, if the router at address a.b.c.d stops sending advertisements, and an IPv4 host determines that the router is now "unreachable", it is relatively easy to determine all of the routes in the current routing table which are using a.b.c.d as a next-hop address. Again, clever exploitation of this behaviour can allow one router to masquerade as several routers on a given link, when desired. The fact that a host will only know each neighboring router by a single IPv6 address is important, as Jim Bound pointed out in an earlier message, for a number of reasons pertaining to the efficacy and efficiency of the Router Discovery protocol. This issue is (perhaps) easily resolved by Erik's proposed "designated" link-local router address. This proposal has the advantage that it allows the IPv4 assumption (one address per interface) to stand for local routing purposes, so it allows some of the same mechanisms to be used in IPv6 that have been used in IPv4. There is another implied assumption here, though: All hosts will use "designated" link-local addresses for all next-hop addresses in all routes (even routes configured by a user). I don't know if this is an explicitly stated assumption of IPv6, but it is implicit in the belief that a "designated" link-local address can "fix" the problems with Router Discovery in this area. If this will be an explicit requirement of IPv6, though, I need to go fix my implementation :-). BTW, if a user only knows the domain name (and/or the global address) of the router he wishes to use as a next-hop, how does my host implementation determine the "designated" link-local address for that router? I don't think, though, that a "designated" link-local address fixes the larger problem. Most of the problem seems to have been swept under the rug of "routing protocols". Now, I haven't been working on the development of any IPv6 routing protocols (yet), so I could be misunderstanding something. If so, please point out my error(s). It seems to me that routers get caught in the middle (more than literally) by the insistence that IPv6 nodes will only know their routers by link-local addresses. Since all of the heirarchical information is contained in global addresses (or site-local for a non-globally-connected site) and since link-local addresses are not guaranteed to be unique within any scope greater than one link, it seems pretty clear that sophisticated routing protocols (which maintain information about a considerably larger portion of the world than their local neighbors) will need to maintain and disseminate, via routing protocols, internal routing information in terms of global addresses. Right? But, these same routers will need to disseminate routing information (via ICMPv6 redirects) to hosts using only link-local addresses. Right? So, have the router folks bought into the feasibility of having routers maintain a mapping between the link-local and global addresses of neighboring routers? If so, what mechanism is used to perform the mapping (or is it routing protocol dependent)? If this is still an unsolved problem, could this be (part of the reason) why the only IPv6 routing protocol I've seen used is RIPv6? And, where lies the responsibility of providing this mapping information to other nodes that require it? If I use SNMP to dump the routing table of an IPv6 host on another link, will I have any way to reach the routers which have been designated as next-hop addresses for the routes on that host, given their "designated" link-local address? Or will I have to have a big table somewhere mapping link-local addresses to global addresses (similar to the old BootP tables mapping hardware addresses to IPv4 addresses)? We'd all hate to see things return to the level of RIP and BootP, so obviously we need a better solution. This whole problem can be fixed if we can determine a method to "convert" between different node addresses. For example, if I could count on the fact that a given node will use the same interface token for each of its addresses on a given interface (unless it is specifically trying to masquerade as multiple nodes), I can construct any of a node's IPv6 addresses given its interface token(s) and its "location(s)" (which global and site-local prefixes apply to its attached link(s)). From a global address and awareness of my own global and site prefixes, I could convert to a site-local or link-local address for the node and know whether or not it would be valid to use those addresses for communication. This would, incidentally, solve the problem of how to obtain the narrowest-scoped valid address to use when starting a communication. I could also convert to wider-scoped addresses using my own site and global prefix information to convert link-local or site-local addresses to a wider scope. I don't think these types of conversions are valid within the current architecture, though. In fact, I'm not even sure they are a good idea. There would be a number of issue with doing these types of conversions in the presence of manually-assigned or DHCP-assigned addresses, for example. Another alternative would be some sort of automated mechanism for obtaining these address mappings. Something in the DNS? Asking the routers? Some other mechanism? Asking the host itself might work in some circumstances, but would not serve to map a link-local address to a global address when I am not attached to the link (as in the SNMP example above). Does anyone else have any thoughts on this? Or have I just wandered off into the weeds? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:40:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22572 for ipng-dist; Thu, 26 Mar 1998 09:30:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA22565 for ; Thu, 26 Mar 1998 09:30:39 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA29907 for ; Thu, 26 Mar 1998 09:30:37 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA26567 for ; Thu, 26 Mar 1998 09:30:38 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id MAA06907; Thu, 26 Mar 1998 12:30:31 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19584; Thu, 26 Mar 1998 12:30:24 -0500 Message-Id: <199803261730.AA19584@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5501) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Thu, 26 Mar 1998 07:50:48 PST." Date: Thu, 26 Mar 1998 12:30:24 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Agreed. But I think with all the changes that will be required to >> support them in ND and addrconf and elsewhere, >The changes in the specs are trivial -- just editorial corrections. I think that is an overstatement. >> I suggest our intent was to not permit them... >That was not the intent of the authors who wrote those specs. It was >simply that, since in the normal case we expect interfaces to have only >one LL address, we forgot about the plural case. The moment you pointed >out the ambiguity, we were able to tell you what our intent was. Well if your in "our" so am I. I was around when Bill first declared the idea of ND. So your talking to one from the beginning. And I never envisioned multiple LL addresses when thinking about all the assertions in the ND architecture or the code base. >> This is exactly the behavior of any org entity in the >> nor IMO, and one of my frustrations consistently in the IETF. >This is the value of the IETF: improving the quality of specs and the >chances of interoperability by broad review by a variety of people, >to ferret out bugs/ambiguities/oversights in those specs. That is not what I am saying is stressful. That is a standard practice in any engineering org. The norm I was speaking of was the "just in case" mindset. Don't twist my words around OK. I have lived the broad review and it is good and chases out bugs. But when you tell me to put things in a protocol or architecture for the future you have to tell me why and justifying it with some vague promise that it will be needed some day. Thats bogus and what I don't like. I hope that is cleaar now. Not that you agree. I don't care if you agree or not. But I do care how you republish my comments with your twist on what they said. Don't do it or we can talk offline and I will explain it to you in detail at L.A. in person. >> This is tough. But how about "whats a site" we are told implement this >> yet no one can tell us what it is? >The short answer is: a site is whatever turns out to be convenient or useful >for any specific customer. The long answer, at least from me, will have to >wait until next week, because I'm busy attending a workshop all day today >and tomorrow, and don't have time to compose a long message. OK lets sort it out though. And so it can be sorted with running code. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:40:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22644 for ipng-dist; Thu, 26 Mar 1998 09:36:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA22637 for ; Thu, 26 Mar 1998 09:36:18 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA01636 for ; Thu, 26 Mar 1998 09:36:15 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA00696 for ; Thu, 26 Mar 1998 09:36:15 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id MAA06928; Thu, 26 Mar 1998 12:36:13 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19912; Thu, 26 Mar 1998 12:36:10 -0500 Message-Id: <199803261736.AA19912@wasted.zk3.dec.com> To: "Buclin, Bertrand" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5502) Re: Link-Local Address, more than one on an inter face.... In-Reply-To: Your message of "Thu, 26 Mar 1998 17:06:35 +0100." Date: Thu, 26 Mar 1998 12:36:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Betrand, >What about a node running DECnet: its interface has two MAC addresses >(the physical and the DECnet one). Why not allowing to use a link local >with the ID derived from the DECnet MAC address ? (actually some of your >colleagues might be tempted to do that for DECnet Phase VI :-). Boy are you talking to the wrong guy at DEC. Nothing that came out of that era I find much use for and I think that should be apparent from my mail indirectly. I can't say more obviously, I will let a non-DEC person tell you what could have been wrong with this approach. >In general, if it is accepted that an interface can have several MAC >addresses, then if that interface is attached to a node running IPv6, >nothing should prevent the use of any of the MAC addresses to build the >LL address, and furtherore why not build several LL addresses to reflect >each MAC address this interface is supporting. If an interface has several real mac addresses then I agree they can be used. ATM has this property in some cases. That is not what I consider two LL addresses. I am talking about when there is only one mac (or mfg address) and we permit just making up a low order 64bits arbitrarily to produce another LL address is what I think is bogus and wrong. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 09:42:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id JAA22665 for ipng-dist; Thu, 26 Mar 1998 09:39:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id JAA22658 for ; Thu, 26 Mar 1998 09:39:20 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA02331 for ; Thu, 26 Mar 1998 09:39:16 -0800 Received: from oscar.broadcom.ie (oscar.broadcom.ie [192.107.110.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA02736 for ; Thu, 26 Mar 1998 09:39:17 -0800 (PST) Received: from pc13 (pc13.broadcom.ie [192.107.110.113]) by oscar.broadcom.ie (8.8.8/8.8.8) with SMTP id RAA17140 for ; Thu, 26 Mar 1998 17:37:04 GMT Message-Id: <199803261737.RAA17140@oscar.broadcom.ie> Reply-To: From: "Ciaran Treanor" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5503) Re: Protocol Analyzer Date: Thu, 26 Mar 1998 17:37:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Thu, 26 Mar 1998, Alberto Abudara wrote: > > > Hello ! > > Does anyone knows where I can find a protocol analyzer for IPv6 working > > in Windows NT or Linux ? > > Regards, > > Alberto. Hmmm. OK. Linux (of course!) ftp ftp.inner.net cd /pub/ipv6 bin get tcpdump-3.4a6+ipv6-1.tar.gz get libpcap-0.4a6+ipv6-1.tar.gz bye Ciaran -- Ciaran Treanor +353-1-604-6000 ciaran@broadcom.ie Broadcom Eireann Research Ltd. PGP Signature http://www-usru.broadcom.ie/~ct/ on HomePage "If you're playing your records backwards, you ARE Satan"-Bill Hicks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 11:02:23 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id KAA23005 for ipng-dist; Thu, 26 Mar 1998 10:56:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id KAA22998 for ; Thu, 26 Mar 1998 10:56:46 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id KAA19133; Thu, 26 Mar 1998 10:56:42 -0800 (PST) Date: Thu, 26 Mar 1998 10:56:37 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5504) Re: Link-Local Address, more than one on an interface.... To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199803252040.AA27777@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would like to hear from IBM, Sun, HP, SGI, Microsoft, and some other > host vendors as implementors. And based on my last mail from router > implementors too as it affects ND on the router too. The Sun implementation will always assign a link-local address as the first address for an interface based on the interface token. While we haven't tested it I don't see a problem with assigning addition link-local addresses to the same interface. (The thing we would need to test is to ensure that these link-local addresses don't accidentally get used as source addresses for redirect messages etc). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 11:20:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA23102 for ipng-dist; Thu, 26 Mar 1998 11:15:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id LAA23095 for ; Thu, 26 Mar 1998 11:15:15 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA22247; Thu, 26 Mar 1998 11:15:06 -0800 (PST) Date: Thu, 26 Mar 1998 11:15:02 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5505) Re: Link-Local Address, more than one on an interface.... To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9803261227.aa17949@khitomer.epilogue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > DNS clearly works best where there is a one-to-one mapping between > hosts and IPv4 addresses. Most routing protocols (and host-router > interactions) clearly expect a one-to-one mapping between IP addresses > and interfaces. I think this is a large part of why we've had some > much trouble in these two areas for IPv6. > > The common cases where IPv4 nodes are assigned more than one IPv4 > address are routers and multi-faced servers (non-router, multihomed > hosts). In both cases, there is generally one IPv4 address assigned > per interface. Other nodes do not have a method of determining which > interfaces are shared by the same node, but this is not usually a > problem, as most nodes only want to communicate with the "closest" > interface (presumably a link-local interface, in the router case). It might just be a lack of the knowledge of the capabilities with the system and network admins. Having DNS return a list of addresses for a canonical name for the multihomed server works fine assuming the clients are smart enough to prefer the address that is on the same IPv4 subnet. This has been part of at least some IPv4 implementations for many years. And it will also work for IPv6. > Protocols which deal with IPv4 routers (such as the IPv4 version of > Router Discovery, IPv4 Routing Protocols, etc.) make the assumption > that there is a one-to-one mapping between router interfaces and > IPv4 addresses. I don't believe this is the case. RFC 1256 explicitly allows a router to include an unlimited number of router addresses in a router advertisement message. > There is another implied assumption here, though: All hosts will use > "designated" link-local addresses for all next-hop addresses in all > routes (even routes configured by a user). I don't know if this is > an explicitly stated assumption of IPv6, but it is implicit in the > belief that a "designated" link-local address can "fix" the problems > with Router Discovery in this area. If this will be an explicit > requirement of IPv6, though, I need to go fix my implementation :-). > > BTW, if a user only knows the domain name (and/or the global > address) of the router he wishes to use as a next-hop, how does > my host implementation determine the "designated" link-local address > for that router? Adding the word "designated" doesn't change the nature of this problem. Without that word you still need to (somehow) determine the link-local address of the router in order to create a static route. (Once could even argue that this is a feature since it prevents folks from putting global addresses in static routing tables thus avoids failure when the site renumbers.) Perhaps the "linkname" draft would be helpful to automatically resolve names to link-local addresses for this purpose? > I don't think, though, that a "designated" link-local address fixes > the larger problem. Most of the problem seems to have been swept > under the rug of "routing protocols". Now, I haven't been working on > the development of any IPv6 routing protocols (yet), so I could be > misunderstanding something. If so, please point out my error(s). > > It seems to me that routers get caught in the middle (more than > literally) by the insistence that IPv6 nodes will only know their > routers by link-local addresses. Not quite. For the purpose of putting a NEXT HOP in the forwarding table the routing protocol needs to propogate the link local addresses between neighboring routers. But the routing protocols (and their implementations) can use other mechanisms to identify the routers (such as a router ID in OSPF). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 11:40:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id LAA23158 for ipng-dist; Thu, 26 Mar 1998 11:31:19 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id LAA23151 for ; Thu, 26 Mar 1998 11:31:14 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with ESMTP id LAA24935 for ; Thu, 26 Mar 1998 11:31:13 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id LAA17571 for ipng@sunroof.eng.sun.com; Thu, 26 Mar 1998 11:31:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id LAA23121 for ; Thu, 26 Mar 1998 11:28:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA05130 for ; Thu, 26 Mar 1998 11:28:07 -0800 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA19241 for ; Thu, 26 Mar 1998 11:28:08 -0800 (PST) Received: from hpinwag.cup.hp.com (wag@hpinwag.cup.hp.com [15.13.108.71]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id LAA23437; Thu, 26 Mar 1998 11:27:57 -0800 (PST) Received: (from wag@localhost) by hpinwag.cup.hp.com (8.7.5/8.7.3 TIS Messaging 5.0) id LAA27226; Thu, 26 Mar 1998 11:27:35 -0800 (PST) From: William Gilliam Message-Id: <199803261927.LAA27226@hpinwag.cup.hp.com> Subject: (IPng 5507) Re: Protocol Analyzer To: mark@diginet.com (Mark A. Miller) Date: Thu, 26 Mar 1998 11:27:35 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Mark A. Miller" at Mar 26, 98 07:47:10 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You might also take a look at EtherPeek from The AG Group, Inc. It does some IPv6 decoding, and it runs on Windows 95 and NT. > Wandel & Goltermann's Domino analyzer runs on Windows 95, and has IPv6 > decodes available. I am not aware of any other analyzers that support > IPv6 at this time. > > Regards, > > Mark > > *************************************************************************** > Mark A. Miller Tel: 303.682.5244 > DigiNet Corporation Fax: 303.682.2654 > 5310 St. Vrain Road Email: mark@diginet.com > Longmont, CO 80503 http://www.diginet.com > *************************************************************************** > > On Thu, 26 Mar 1998, Alberto Abudara wrote: > > > Hello ! > > Does anyone knows where I can find a protocol analyzer for IPv6 working > > in Windows NT or Linux ? > > Regards, > > Alberto. > > > > ------------------------------------------------------------------------ > > ------------------------ > > Alberto Abudara > > Montevideo, URUGUAY - South America > > Montevideo Teleport International, > > ZONA FRANCA DE MONTEVIDEO > > RUTA 8 Km 17.500 Loc. 123 > > email: aabudara@zfm.com > > voice +598 982 2000 x 5728 > > fax +598 982 2000 x 5274 > > ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 12:21:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id MAA23267 for ipng-dist; Thu, 26 Mar 1998 12:11:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id MAA23260 for ; Thu, 26 Mar 1998 12:11:12 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA17865 for ; Thu, 26 Mar 1998 12:11:08 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA19338 for ; Thu, 26 Mar 1998 12:11:07 -0800 (PST) From: Margaret Wasserman To: Erik.Nordmark@Eng CC: ipng@sunroof.eng.sun.com In-reply-to: (message from Erik Nordmark on Thu, 26 Mar 1998 11:15:02 -0800 (PST)) Subject: (IPng 5508) Re: Link-Local Address, more than one on an interface.... Date: Thu, 26 Mar 98 15:11:00 -0500 Message-ID: <9803261511.aa19169@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Protocols which deal with IPv4 routers (such as the IPv4 version of >> Router Discovery, IPv4 Routing Protocols, etc.) make the assumption >> that there is a one-to-one mapping between router interfaces and >> IPv4 addresses. > >I don't believe this is the case. RFC 1256 explicitly allows a router >to include an unlimited number of router addresses in a router >advertisement message. Yes, but they are treated as different routers by hosts that receive the advertisements. If, for example, upper layer advice indicated that a particular router address was unreachable, the node would not consider the other router addresses in the same advertisements to be unreachable. >> BTW, if a user only knows the domain name (and/or the global >> address) of the router he wishes to use as a next-hop, how does >> my host implementation determine the "designated" link-local address >> for that router? > >Adding the word "designated" doesn't change the nature of this problem. You are correct, my wording was misleading. The general problem is determine what link-local address corresponds to a given domain name or global address. >> It seems to me that routers get caught in the middle (more than >> literally) by the insistence that IPv6 nodes will only know their > ^^^^^^^^^^ >> routers by link-local addresses. > >Not quite. For the purpose of putting a NEXT HOP in the forwarding >table the routing protocol needs to propogate the link local >addresses between neighboring routers. But the routing protocols >(and their implementations) can use other mechanisms to identify the >routers (such as a router ID in OSPF). Sorry, I should have said "IPv6 hosts" above. Router Discovery requires that redirects and advertisements use link-local addresses so that the local hosts will only know the router by one address (except in cases where there router intentionally wants to be known at more than one address). I think this is a good thing. But, it does require that IPv6 routers be able to map whatever mechanism they use to identify their neighboring routers for routing protocol purposes (global IP address, router ID, etc.) to a link-local IP address, right? I think that cases I mentioned in my mail (and a number of other situations) all point to the fact that it would be very convenient and desireable to have a mechanism to do this mapping (global address to link-local address and vice versa, possibly with site-local addresses thrown in) automatically (either mechanically, or through an automated mechanism). I don't know whether it makes the most sense to do this as part of the way addresses are assigned/constructed in the architecture (i.e. have each token be a unique (for a given link) identifier for a specific host). This would in turn require that a host have a link-local address matching the address token of each of its wider-scoped addresses, and would probably have other broader-ranging ramifications. Alternatively, it would be good to have some other automated mechanim for performing the mapping. Link-local (and site-local) name resolution would also be cool, but are a separate issue from address mapping (although both forward and reverse name resolution could be the mechanism by which the mapping is acheived). Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 12:49:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id MAA23316 for ipng-dist; Thu, 26 Mar 1998 12:37:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id MAA23309 for ; Thu, 26 Mar 1998 12:37:35 -0800 (PST) From: Alain.Durand@imag.fr Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA23785; Thu, 26 Mar 1998 12:37:31 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA08520; Thu, 26 Mar 1998 12:37:32 -0800 (PST) Received: from brahma.imag.fr (brahma.imag.fr [129.88.30.10]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id VAA04874; Thu, 26 Mar 1998 21:37:30 +0100 (MET) Received: (from durand@localhost) by brahma.imag.fr (8.8.7/8.8.5) id VAA01410; Thu, 26 Mar 1998 21:37:29 +0100 (MET) Date: Thu, 26 Mar 1998 21:37:29 +0100 (MET) Message-Id: <980326213729.ZM1408@brahma.imag.fr> In-Reply-To: Margaret Wasserman "(IPng 5508) Re: Link-Local Address, more than one on an interface...." (Mar 26, 3:11pm) References: <9803261511.aa19169@khitomer.epilogue.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Margaret Wasserman , Erik.Nordmark@Eng Subject: (IPng 5509) Re: Link-Local Address, more than one on an interface.... Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mar 26, 3:11pm, Margaret Wasserman wrote: > Subject: (IPng 5508) Re: Link-Local Address, more than one on an interface > I think that cases I mentioned in my mail (and a number of other > situations) all point to the fact that it would be very convenient and > desireable to have a mechanism to do this mapping (global address to > link-local address and vice versa, possibly with site-local addresses > thrown in) automatically (either mechanically, or through an automated > mechanism). Just a thought: What about a new ICMP message: "what are your other addresses?" Nodes would respond with the complete (???) set of their addresses... We might even refine this a little with an option that will say please return all addresses for your incoming interface or all addresses for all interfaces. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 13:41:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id NAA23603 for ipng-dist; Thu, 26 Mar 1998 13:28:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id NAA23596 for ; Thu, 26 Mar 1998 13:28:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA06172 for ; Thu, 26 Mar 1998 13:28:18 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA14017 for ; Thu, 26 Mar 1998 13:28:17 -0800 (PST) From: Margaret Wasserman To: Alain.Durand@imag.fr CC: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-reply-to: <980326213729.ZM1408@brahma.imag.fr> (Alain.Durand@imag.fr) Subject: (IPng 5510) Re: Link-Local Address, more than one on an interface.... Date: Thu, 26 Mar 98 16:28:10 -0500 Message-ID: <9803261628.aa19974@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What about a new ICMP message: "what are your other addresses?" >Nodes would respond with the complete (???) set of their addresses... >We might even refine this a little with an option that will say >please return all addresses for your incoming interface or >all addresses for all interfaces. This would work (subject to security considerations, etc.) if you have a global address and want to map it to a site-local or a link-local address. However, you'd have no way of knowing whether it would be acceptable to use either of those addresses for communication, since I don't think there is a way to tell if a particular global address is site-local or link-local (Are you allowed to rely on a prefix match with your site or global prefix to determine that a given global address is site or link- local?) It would also work to map the link-local address of a link-local node (or the site-local address of a site-local node) to a broader- scoped address. This would not work, however to discover the global address of a host if all you have is its link-local address on a non-locally-attached link. For example, it would not let you (using SNMP from a non-local link) look at the router configuration for the router corresponding to the next-hop address in a host's current default route entry. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 13:59:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id NAA23665 for ipng-dist; Thu, 26 Mar 1998 13:47:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id NAA23658 for ; Thu, 26 Mar 1998 13:46:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA11402 for ; Thu, 26 Mar 1998 13:46:49 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA26759 for ; Thu, 26 Mar 1998 13:46:49 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id QAA11136; Thu, 26 Mar 1998 16:46:47 -0500 (EST) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10363; Thu, 26 Mar 1998 16:45:52 -0500 Date: Thu, 26 Mar 1998 16:45:52 -0500 From: Jack McCann Message-Id: <199803262145.AA10363@wasted.zk3.dec.com> To: deering@cisco.com, fenner@parc.xerox.com, haberman@raleigh.ibm.com Subject: (IPng 5511) comments on MLD spec Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Bill, Brian, Please find attached some comments on draft-ietf-ipngwg-mld-00.txt, Multicast Listener Discovery (MLD) for IPv6. This is a compilation of comments received from several members of the DIGITAL UNIX IPv6 team: Jim Bound, Mary Clouter, Gerri Harter, Jack McCann, Yanick Pouffary, Ken Powell, Ravi Shankar, Sowmini Varadhan. First, some general comments and questions: - A table of contents would be helpful. - Why did you choose to depart from the terminology in IGMPv2 (e.g. "listener" vs "group member")? - Can you add a statement as to which is authoritative in the event of a conflict: the text or the diagrams? - Labels on the diagrams would be helpful (e.g. Figure 1. Node State Transition Diagram) - Would you consider adding sections describing message validation and message processing similar to those found in Neighbor Discovery? For example: Message Validation Validation of Multicast Listener Query Validation of Multicast Listener Report Validation of Multicast Listener Done Node Specification Becoming a Listener Sending Multicast Listener Reports Receipt of Multicast Listener Querys Receipt of Multicast Listener Reports Stopping being a Listener Sending Multicast Listener Done messages Router Specification Becoming a Querier Sending Multicast Listener Querys General Query Timer expiration Receipt of Multicast Listener Reports Receipt of Multicast Listener Querys Becoming a Non-Querier Other Querier Present Timer expiration Tracking Multicast Address Listeners for a Querier Receipt of Multicast Listener Reports Receipt of Multicast Listener Done Timer Expiration Retransmit Timer Expiration Tracking Multicast Address Listeners for a Non-Querier Receipt of Multicast Listener Reports Receipt of Multicast-Address-Specific Queries Timer Expiration - Perhaps add a note about ignoring packets if AH present but authentication failed? Now for some specific comments: - Section 2 Introduction All MLD messages described in this document are sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RTR- ALERT] in a Hop-by-Hop Options header. Should the Hop Limit 255 "trick" should be used? Why is the Router Alert option included? We were guessing at scenarios where this would be important, if you would be so kind as to elaborate on this a bit it would be helpful. - Section 4 Node State Transition Diagram, page 10 In the diagram on page 10, would it be possible to indicate the initial state, perhaps by adding "(Initial state)" to the Non-Listener box? - Section 4 Node State Transition Diagram, page 10 "The link-scope all-nodes address (FF02::1) is handled as a special case." Why just the all-nodes address, why not all link-scope multicast addresses? - Section 5 Router State Transition Diagram, page 12 "In addition, to keep track of which multicast addresses have listeners, a router may be in one of four possible states with respect to any..." ^^^^ There are only three states. - Section 5 Router State Transition Diagram, page 13 "There are five significant events that can cause router state transitions:" You show only four events, but from the diagram on page 15 it seems there is a fifth event: "multicast-address-specific query received" - Section 5 Router State Transition Diagram, page 14 In the diagram on page 14, the arc labeled "leave received" should be "done received". - Section 8 Security Considerations Typo in the first paragraph: "acting on forged MSD messages originated off-link, so we discuss only" ^^^ - Section 8 Security Considerations "During this time, if the forger ignores Done messages, traffic might flow to addresses with no listeners for up to [Multicast Listener Interval]." Not sure what scenario you had in mind here, could you elaborate? General impression among the reviewers is that this is some really slick technology, and we look forward to implementing your spec. Thanks, - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 15:09:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id PAA23895 for ipng-dist; Thu, 26 Mar 1998 15:03:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id PAA23888 for ; Thu, 26 Mar 1998 15:03:10 -0800 (PST) From: Alain.Durand@imag.fr Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA02270; Thu, 26 Mar 1998 15:03:08 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA17111; Thu, 26 Mar 1998 15:03:07 -0800 (PST) Received: from brahma.imag.fr (brahma.imag.fr [129.88.30.10]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id AAA09462; Fri, 27 Mar 1998 00:02:59 +0100 (MET) Received: (from durand@localhost) by brahma.imag.fr (8.8.7/8.8.5) id AAA02820; Fri, 27 Mar 1998 00:02:58 +0100 (MET) Date: Fri, 27 Mar 1998 00:02:58 +0100 (MET) Message-Id: <980327000258.ZM2818@brahma.imag.fr> In-Reply-To: Margaret Wasserman "(IPng 5510) Re: Link-Local Address, more than one on an interface...." (Mar 26, 4:28pm) References: <9803261628.aa19974@khitomer.epilogue.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Margaret Wasserman Subject: (IPng 5512) Re: Link-Local Address, more than one on an interface.... Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mar 26, 4:28pm, Margaret Wasserman wrote: > Subject: (IPng 5510) Re: Link-Local Address, more than one on an interface > > >What about a new ICMP message: "what are your other addresses?" > >Nodes would respond with the complete (???) set of their addresses... > >We might even refine this a little with an option that will say > >please return all addresses for your incoming interface or > >all addresses for all interfaces. > > This would work (subject to security considerations, etc.) if you > have a global address and want to map it to a site-local or a > link-local address. However, you'd have no way of knowing whether > it would be acceptable to use either of those addresses for > communication, since I don't think there is a way to tell if a > particular global address is site-local or link-local (Are you > allowed to rely on a prefix match with your site or global > prefix to determine that a given global address is site or link- > local?) > > It would also work to map the link-local address of a link-local > node (or the site-local address of a site-local node) to a broader- > scoped address. > > This would not work, however to discover the global address of a host > if all you have is its link-local address on a non-locally-attached > link. For example, it would not let you (using SNMP from a non-local > link) look at the router configuration for the router corresponding > to the next-hop address in a host's current default route entry. I totally agree with you. High level protocols like SNMP SHOULD NOT forward link local addresses. However, this link local to global translation does not necessarely have to be done end to end. My proposal ICMP "what are your addresses" could help nodes that only know the link local addresses of their neighbors to discover their global ones. Then, when queried by SNMP, they could advertise those global addresses instead of the link local one... This may not solve every problem, but may be usefull - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 16:21:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id QAA24201 for ipng-dist; Thu, 26 Mar 1998 16:16:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id QAA24194 for ; Thu, 26 Mar 1998 16:16:40 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA19088 for ; Thu, 26 Mar 1998 16:16:37 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with SMTP id QAA00306 for ; Thu, 26 Mar 1998 16:16:33 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id QAA07755; Thu, 26 Mar 1998 16:16:23 -0800 Message-Id: <3.0.5.32.19980326161601.0082c910@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 26 Mar 1998 16:16:01 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5513) Proposed IPng Agenda for LA IETF Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the proposed agenda for the IPng session at the LA IETF. Suggestions for changes/additions/etc to us. Bob Hinden / Steve Deering -------------------------------------------- IPng Meeting Agenda ------------------- MONDAY, March 30, 1998, 1930-2200 (Santa Barbara BC) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (15 min) Mobile IPv6 Status / D. Johnson (15 min) Proposed ND Split / M. Wasserman (5 min) IPv6 over PVC ATM / S. Deering (10 min) IPv6 over NBMA & IPv6 over ATM Status / P. Schulter (10 min) Router Renumbering / M. Crawford (15 min) Scope Issues / S. Deering (30 min) TUESDAY, March 31, 1998, 1545-1645 (San Gabriel) Multicast Listener Discovery Protocol / S. Deering (30 min) IPv6 Plug and Play, Done? / B. Hinden (30 min) THURSDAY, April 2, 1998, 0900-1130 (San Gabriel) DNS Status / S. Deering (30 min) ICMP Name Lookups / M. Crawford (5 min) Reverse DNS Lookup / M. Crawford (15 min) IPv6 Host Naming Translations / J. Paugh (10 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 18:03:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id RAA24345 for ipng-dist; Thu, 26 Mar 1998 17:53:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id RAA24337 for ; Thu, 26 Mar 1998 17:53:37 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA08849 for ; Thu, 26 Mar 1998 17:53:36 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA23100 for ; Thu, 26 Mar 1998 17:53:38 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id UAA15518 for ; Thu, 26 Mar 1998 20:53:37 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20009; Thu, 26 Mar 1998 20:53:36 -0500 Message-Id: <199803270153.AA20009@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5514) Re: Transparent Renumbering? In-Reply-To: Your message of "Wed, 25 Mar 1998 13:25:54 EST." <199803251825.KAA02332@earth.sun.com> Date: Thu, 26 Mar 1998 20:53:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I want to apologize to anyone that my message to Steve S. offended, it was flip and had an attitude. The jist was not personal nor pointed at any particular group or person. My issue is the "system" in any environment and at times it really gets to me, sorry to bare that on your email. And my own passion to get IPv6 deployed and keep the promises of IPv6 and this is a subpart of that whole. I have told Steve I would work with him on this and will contribute my previous work in this area..... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 26 18:20:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) id SAA24371 for ipng-dist; Thu, 26 Mar 1998 18:13:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta3+Sun/8.9.0.Beta3) with SMTP id SAA24364 for ; Thu, 26 Mar 1998 18:13:05 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA12745; Thu, 26 Mar 1998 18:13:04 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA03276; Thu, 26 Mar 1998 18:13:05 -0800 (PST) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id VAA17878; Thu, 26 Mar 1998 21:13:05 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20202; Thu, 26 Mar 1998 21:12:58 -0500 Message-Id: <199803270212.AA20202@wasted.zk3.dec.com> To: Margaret Wasserman Cc: Alain.Durand@imag.fr, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 5515) Re: Link-Local Address, more than one on an interface.... In-Reply-To: Your message of "Thu, 26 Mar 1998 16:28:10 EST." <9803261628.aa19974@khitomer.epilogue.com> Date: Thu, 26 Mar 1998 21:12:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >...................... to use either of those addresses for >communication, since I don't think there is a way to tell if a >particular global address is site-local or link-local (Are you >allowed to rely on a prefix match with your site or global >prefix to determine that a given global address is site or link- >local?) If we are to switch or IMO even use these addresses as integrated in this manner, I think it is very critical we solve the problem you state above soon, not later. This may be the "root" of many of my recent issues to the list. p.s. you write really well like the chairs, Thomas Nartern, Christian, and some others.... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 27 08:03:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id HAA25431 for ipng-dist; Fri, 27 Mar 1998 07:54:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id HAA25424 for ; Fri, 27 Mar 1998 07:53:44 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA12012 for ; Fri, 27 Mar 1998 07:53:42 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA16465 for ; Fri, 27 Mar 1998 07:53:41 -0800 (PST) Received: from dashub2.das.dec.com (dashub2.das.dec.com [16.136.64.63]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with ESMTP id KAA30855; Fri, 27 Mar 1998 10:53:33 -0500 (EST) Received: by dashub2.das.dec.com with Internet Mail Service (5.0.1460.8) id ; Fri, 27 Mar 1998 10:53:26 -0500 Message-ID: <0C4AB5AB65C1D011BA450000F841943BFA66BB@zkoexc3.zko.dec.com> From: Ken Powell To: "'Matt Crawford'" , Jack McCann Cc: hinden@ipsilon.com, ipng@sunroof.eng.sun.com Subject: (IPng 5516) Re: Router Renumbering Date: Fri, 27 Mar 1998 10:53:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My comments prefixed by "[Ken]" below. -----Original Message----- From: Matt Crawford [SMTP:crawdad@fnal.gov] Sent: Tuesday, March 24, 1998 7:08 PM To: Jack McCann Cc: hinden@ipsilon.com; ipng@sunroof.Eng.Sun.COM Subject: (IPng 5434) Re: Router Renumbering > KeepLen may also be a problem if we ever have Interface_ID_length not > equal to 64 bits for some link type X, but is 64 bits for some other > link type Y, and the router has both type X and Y links: KeepLen would > need to be different depending on the link type, which means whoever > creates the RR command would need to know in advance what link types > were on the router. Well, yes. The network manager would have to know the network. But if there's consensus that this is a problem which needs to be solved, I'd rather add a match-condition on the length of the existing prefix than pur in a sanity check on the result. Half the "reserved" field of a Match-Prefix part could hold, say, a MinLen and MaxLen which would bound the length of an existing prefix to be tested for matching. A "Points for Discussion" section in the -00 through -02 drafts alluded to something along those lines, but no such discussion was provoked. Consider this a concrete suggestion: should such a MinLen & MaxLen, or some equivalent, be inserted? [Ken] The primary problem I have with the existing definition occurs when different prefix lengths are used on different links within a site. Ideally, a single Router Renumber message with one PCO could renumber all routers within such a site. KeepLen prevents this. MinLen and MaxLen do provide a means to solve this issue. More details on what the new prefix's length will become are still needed. I see KeepLen as being necessary to support defining non- standard prefix lengths on router interfaces. In most other situations, KeepLen seems unnecessary. How about adding an "Override Length" flag. If Override Length is set, UseLen and KeepLen work as specified now. If Override Length is clear, then KeepLen is ignored and the final prefix length is defined as: 1) In update PCO's, use the original length of the Modified Prefix. 2) In add PCO's, use the standard prefix length for the interface type as defined in the IPv6 over FOO specification (normally 64). Of course, this still leaves a problem. What happens if UseLen is longer than either of these two values? > - Section 4.2.1.2 Use-Prefix Part > > We thought a more detailed explanation of how the Valid and Preferred > lifetimes and the P and V bits relate back to ND and SAA would be > helpful, e.g. by describing the "Router Configuration Variables" [ND] > affected by the operation (e.g. AdvPrefixList, AdvValidLifetime, > AdvOnLinkFlag, AdvPreferredLifetime, AdvAutonomousFlag). > > As an aside, it would be helpful in this instance for ND to define > "Router Configuration Variable" names to associate with the P and V > flags. OK, I'll do that at a later date. The properties to be affected by the P & V flags didn't exist when I began, but they do now. [Ken] This brings up some interesting questions. Does a router have to update all prefixes in its database that match the Match Prefix, including all those that are statically defined through network management commands? Would it be valid for management commands to isolate prefixes from Router Renumber processing? What should the default behavior be? Do routers have to keep a timer running for how long prefixes from Router Renumber messages are valid to advertise? For example, consider a Router Renumber message containing a Use Prefix part with Valid Lifetime of 3 weeks and V flag clear. Given that the Valid Lifetime of the prefix is 3 weeks, does the router have to stop advertising the prefix after 3 weeks if no further Router Renumber messages are received? > - Section 5.3. Execution > > "If any such address > does match M, process the PCO as if P matched M, but when forming > New Prefixes, if KeepLen is non-zero, bits are copied from the > address." > > See KeepLen issue mentioned above. And same answer. [Ken] Why copy bits from the address instead of the Matched Prefix? Would it make more sense to pad the new prefix on the right with zeros in the situations where KeepLen is non-zero and UseLen+KeepLen are longer than the Matched Prefix's length? -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 27 08:57:42 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id IAA25627 for ipng-dist; Fri, 27 Mar 1998 08:52:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id IAA25620 for ; Fri, 27 Mar 1998 08:52:41 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26213 for ; Fri, 27 Mar 1998 08:52:39 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA25526 for ; Fri, 27 Mar 1998 08:52:39 -0800 (PST) From: Margaret Wasserman To: Alain.Durand@imag.fr CC: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-reply-to: <980327000258.ZM2818@brahma.imag.fr> (Alain.Durand@imag.fr) Subject: (IPng 5517) Re: Link-Local Address, more than one on an interface.... Date: Fri, 27 Mar 98 11:51:40 -0500 Message-ID: <9803271151.aa25051@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> This would not work, however to discover the global address of a host >> if all you have is its link-local address on a non-locally-attached >> link. For example, it would not let you (using SNMP from a non-local >> link) look at the router configuration for the router corresponding >> to the next-hop address in a host's current default route entry. > >I totally agree with you. High level protocols like SNMP SHOULD NOT >forward link local addresses. This is an interesting thought, and I believe that it is very consistent with the IPv6 addressing architecture. It wasn't my intention to imply this general statement, but I do believe it could follow from the concept of scoped addressing. The implications of this statement, though, are simply mind-boggling. Certainly, I would not balk at reading: Upper layer protocols SHOULD NOT forward link-local (or site-local) addresses off-link (or off-site). in an IPv6 specification. In fact, wording like this probably occurs in one or more of the specifications. So, why does it suddenly become frightening when you insert the words "like SNMP"? In this case, I believe that SNMP (and a variety of other management protocols and applications) might be considered exempt from this restriction. In many cases, I certainly wouldn't want any mapping performed on addresses before receiving them at an SNMP manager. For example, if I looked at a host's local address list from a non-site-local manager, I wouldn't want to see the global address three times instead of the actual link-local, site-local and global addresses. This is the most obvious case I can think of, but there are many cases in which I would want to see the "real" information, not a mapped version. However, if I look at a routing table, a security log (or any of a hundred other things I could think of), I might want to be able to actually identify (and possibly communicate with) the host represented by a particular address. In this case, I would obviously want an address of sufficient scope to identify or reach the node from my manager (which might be off-link or off-site). Conceivably, an SNMP agent could perform this mapping conditionally on a field-by-field basis (based on information in the MIB, presumably). MIBs could then be intelligently designed to provide the "right" interpretation of the address, or multiple interpretations if desired. However, the whole idea of having an SNMP agent perform this mapping opens up a big swamp of complexity. Just a few issues: What does the agent return if the node does not answer the ICMP "what are your addresses" message? Is the mapping conditional on the "location" of the manager (i.e. will link-local addresses be sent unmapped to a link-local manager? And the real killer -- How does this work for SETs? This is also greatly complicated by the fact that there is no (implied or otherwise) one-to-one mapping between a node's addresses. Which global address should I pick for a host that has several global addresses? Is there any way to unambiguously map that address back to the same link-local address I started with? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 27 09:43:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA25837 for ipng-dist; Fri, 27 Mar 1998 09:29:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA25830 for ; Fri, 27 Mar 1998 09:28:54 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA06050 for ; Fri, 27 Mar 1998 09:28:52 -0800 Received: from thumper.bellcore.com ([128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA18827 for ; Fri, 27 Mar 1998 09:28:37 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id MAA14678 for ; Fri, 27 Mar 1998 12:28:36 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id MAA11873 for ipng@sunroof.Eng.Sun.COM; Fri, 27 Mar 1998 12:28:35 -0500 (EST) Date: Fri, 27 Mar 1998 12:28:35 -0500 (EST) From: Christian Huitema Message-Id: <980327122834.ZM11871@seawind.bellcore.com> In-Reply-To: Margaret Wasserman "(IPng 5517) Re: Link-Local Address, more than one on an interface...." (Mar 27, 11:51am) References: <9803271151.aa25051@khitomer.epilogue.com> X-Mailer: Z-Mail (5.0.0 30July97) To: ipng@sunroof.eng.sun.com Subject: (IPng 5518) Re: Link-Local Address, more than one on an interface.... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we need to be able to support multiple addresses per interface, at least if we want to multiplex multiple virtual machines on the same physical machines. The reasoning is as follow: 1) If we construct multiple addreses, we will likely construct them by adding different EUI tokens to the same network prefixes. 2) But we can only do this legitimately if we test the tokens for unicity. 3) The test for unicity is only performed within ND, which means using LL addresses. Now, shipping a stack that does not support multiple virtual machines on a physical box is perfectly legitimate. There is no requirement that we should have more than one, only a practicality. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 27 10:23:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA26102 for ipng-dist; Fri, 27 Mar 1998 10:13:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id KAA26095 for ; Fri, 27 Mar 1998 10:13:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA18402 for ; Fri, 27 Mar 1998 10:12:57 -0800 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA17366 for ; Fri, 27 Mar 1998 10:12:57 -0800 (PST) From: Margaret Wasserman To: huitema@bellcore.com CC: ipng@sunroof.eng.sun.com In-reply-to: <980327122834.ZM11871@seawind.bellcore.com> (message from Christian Huitema on Fri, 27 Mar 1998 12:28:35 -0500 (EST)) Subject: (IPng 5519) Re: Link-Local Address, more than one on an interface.... Date: Fri, 27 Mar 98 13:12:54 -0500 Message-ID: <9803271312.aa25805@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >3) The test for unicity is only performed within ND, which means using LL >addresses. It is my understanding that DAD can be performed on any scope of unicast address. It is not necessary, though, to perform DAD on a site-local or global address that is constructed using the same token as a link-local address which has already passed DAD. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 30 21:16:28 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id VAA00623 for ipng-dist; Mon, 30 Mar 1998 21:12:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id VAA00616 for ; Mon, 30 Mar 1998 21:12:08 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA25460 for ; Mon, 30 Mar 1998 21:12:07 -0800 Received: from netman.iscs.nus.sg (netman.iscs.nus.sg [137.132.87.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id VAA03326 for ; Mon, 30 Mar 1998 21:12:02 -0800 (PST) Received: from sun450.iscs.nus.edu.sg (root@sun450-m.iscs.nus.edu.sg [137.132.21.116]) by netman.iscs.nus.sg (8.8.5/8.8.5) with ESMTP id NAA01931; Tue, 31 Mar 1998 13:11:55 +0800 (GMT+0800) Received: from localhost (jiangmin@localhost) by sun450.iscs.nus.edu.sg (8.8.5/8.8.5) with SMTP id UAA07498; Mon, 30 Mar 1998 20:02:22 +0800 (GMT-8) Date: Mon, 30 Mar 1998 20:02:22 +0800 (GMT-8) From: Jiang Ming Liang Reply-To: Jiang Ming Liang To: netdev@nuclecu.unam.mx cc: ipng@sunroof.eng.sun.com Subject: (IPng 5523) MIPv6 for Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mobility Support in IPv6 for Linux ================================== The NUS mobile IP research group is pleased to announce the version 1.0alpha release for our implementation of Mobile IPv6. The code consists of a patch to the Linux kernel version 2.1.59, a daemon program for the home agent and another daemon program for the mobile node. (The code should also work with 2.1.6x kernels, but this has not been tested). This implementation complies with version 4 of the MIPv6 internet draft [draft-ietf-mobileip-ipv6-04.txt], except it does not currently support route optimization and authentication (for the lack of IPsec). Installation Notes ==================================================================== 1. Obtain kernel 2.1.59 from somewhere. e.g ftp.kernel.org 2. Apply our kernel patch. 3. Compile a kernel with MIPv6 support. 4. To install the Home Agent daemon, go to the "ha" subdirectory and read the README file there for futhur instructions. 5. To install the Mobile Node daemon, go to the "mn" subdirectory and read the README file there for futhur instructions. Please note that compilation of the daemon code requires glibc2.1 Downloading ===================================================================== This release is available from our web pages at http://mip.ee.nus.sg http://cram.iscs.nus.sg:8080 Pls direct all your queries to the authors, your comments are most welcome. Jiang Mingliang Leong Peck Yoke Liu Ningjiang -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 31 09:14:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA01295 for ipng-dist; Tue, 31 Mar 1998 09:08:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA01288; Tue, 31 Mar 1998 09:07:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA00741; Tue, 31 Mar 1998 09:07:49 -0800 Received: from nimbus.ocis.temple.edu (nimbus.ocis.temple.edu [155.247.166.101]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA16110; Tue, 31 Mar 1998 09:07:47 -0800 (PST) Received: (from sathya@localhost) by nimbus.ocis.temple.edu (8.8.8/8.8.8) id MAA01134; Tue, 31 Mar 1998 12:07:44 -0500 (EST) From: Sathya Message-Id: <199803311707.MAA01134@nimbus.ocis.temple.edu> Subject: (IPng 5524) IPng Over ATM - Opinions solicited To: ion@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Date: Tue, 31 Mar 1998 12:07:44 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I am a graduate student of Computer Science in Temple Univ., Philadelphia. I am doing a independent study on the topic "IPng over ATM". As part of the course work I am collecting information regarding all related standards in my IPng page, http://nimbus.ocis.temple.edu/~sathya/ipng-atm/ . I am also writing abstracts based on my understanding of what I read. I am sure everybody will agree with me that it is important to make the learning process easy, for the success of IPng (of any protocol for that matter). Even though what I have managed to do may not be really good, I am hopeful it will be a good starting point. I want to make it a good tutorial Page for people interested in IPng and ATM. I think it will better if I get input from others (with more experience) in this field regarding the contents and the organization. I request you all to visit my IPng page (whenever you find time !!!) and send me suggestions. I am prepared to put in the time if I get good feedbacks/ideas to improve my IPng page. Thankx in advance, regards Sathya -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 31 10:25:22 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA01457 for ipng-dist; Tue, 31 Mar 1998 10:18:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id KAA01450 for ; Tue, 31 Mar 1998 10:18:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA21016 for ; Tue, 31 Mar 1998 10:17:40 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA02969 for ; Tue, 31 Mar 1998 10:17:40 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA06966; Tue, 31 Mar 1998 12:17:39 -0600 Message-Id: <199803311817.MAA06966@gungnir.fnal.gov> X-Mailer: exmh version 2.0zeta 7/24/97 To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5525) Summary of WG discussion on router renumbering Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Mar 1998 12:17:39 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I present here the points discussed last night and request concurrence or dissent from the list. 1. A field in the RR header (space freed up by item 6) will be used to hold a 16 bit field specifying the upper bound in milliseconds of a random delay time for replying to a multicast command. 2. The only multicast addresses to which RR commands may be sent will be all-routers, either link-scope or site-scope. This takes away the ability to create subsets of your routers addressable by other multicast addresses. Does anyone have a problem with that? Permitting other mcast addresses of scope <= site would not break anything I can think of. 3. During execution, check for formation of certain prefix types and return an error if the command would form them. These include loopback, multicast, and IPv4-mapped addresses. 4. Use two of the 4 unused bytes of the Match-Prefix part to give a MinLen and MaxLen which bound the length of a potential Matched Prefix. This would help in some world which had prefixes of length other than 64. 5. There was not agreement to forbid formation of prefixes which have the form of v4-compatible addresses. I think the need for this ability would be rare, but not zero, so unless there's a strong contrary sentiment I'm going to let it be allowed. 6. Drop the custom built-in authentication method and mandate use of ipsec. Since some of the IPv6 header must be covered, I believe this dictates use of AH rather than (or in addition to) ESP. 7. Add at least one more example: continuous refresh of a set of global prefixes, with the P & V timers running. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 31 12:27:44 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA01542 for ipng-dist; Tue, 31 Mar 1998 12:19:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA01535 for ; Tue, 31 Mar 1998 12:19:36 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA28067 for ; Tue, 31 Mar 1998 12:19:33 -0800 Received: from rast.cisco.com (ietf-13-27.mtg.ietf.org [198.94.13.27]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA21307 for ; Tue, 31 Mar 1998 12:19:34 -0800 (PST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by rast.cisco.com (8.8.7/8.8.7) with SMTP id MAA16455; Tue, 31 Mar 1998 12:19:02 -0800 (PST) (envelope-from raj@cisco.com) Message-Id: <199803312019.MAA16455@rast.cisco.com> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com Subject: (IPng 5526) Re: Router Renumbering X-Quote: If you consult enough experts, you can confirm any opinion. Date: Tue, 31 Mar 1998 12:18:57 -0800 From: Richard Johnson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have three complaints about the current router renumbering draft. Please let me know if I'm missing something. I would be happy to know these are unfounded: 1) The draft doesn't seem to address the issue of how to handle mobile systems which are not currently in your site at the time of the renumbering. Along those same lines, it also doesn't say how to handle renumbering of systems which are turned off during the renumbering. My guess would be that you would simply retransmit the renumber commands for a few weeks, maybe a month, but I didn't see mention of this. Maybe I missed it? 2) The protocol seems to assume some type of stable storage for all routers. Currently most routers don't really have this stable storage. It was interesting that the Mobile IP people specifically recognized this fact on monday when they made their presentation. Yet this renumbering protocol continues to ignore the issue. I think some mention of this requirement should be explicitly made so that vendors know they will need to introduce stable storage in order to comply completely with this protocol. Either this, or there should be some mention as to workarounds. 3) I see no error response message type. If a system can't fully comply with the renumbering (maybe its configuration files are stored on another server and while it can change its own interfaces, it can't easily update those configuration files), then it would be good to be able to return an error saying this. /raj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 31 13:18:51 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id NAA01720 for ipng-dist; Tue, 31 Mar 1998 13:09:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id NAA01705 for ; Tue, 31 Mar 1998 13:09:20 -0800 (PST) From: sathya@nimbus.ocis.temple.edu Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14355 for ; Tue, 31 Mar 1998 13:09:17 -0800 Received: from gateway.gtech.com (gateway.gtech.com [156.24.1.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA23915 for ; Tue, 31 Mar 1998 13:09:19 -0800 (PST) Received: (qmail 5746 invoked from network); 31 Mar 1998 21:09:16 -0000 Received: from ops.soft.gtech.com (156.24.33.7) by gateway.mis.gtech.com with SMTP; 31 Mar 1998 21:09:16 -0000 Received: from ccgate by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-X) via SMTP; id AA1912319233; Tue, 31 Mar 1998 14:59:29 -0500 Received: from POP3 Client by gtech.com (ccMail Link to SMTP R8.10.00) id AA891374597; Tue, 31 Mar 98 15:03:22 -0500 Message-Id: <9803318913.AA891374597@gtech.com> X-Mailer: ccMail Link to SMTP R8.10.00 Date: Tue, 31 Mar 98 12:07:44 -0500 To: , Subject: (IPng 5527) IPng Over ATM - Opinions solicited Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --simple boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" Hi All, I am a graduate student of Computer Science in Temple Univ., Philadelphia. I am doing a independent study on the topic "IPng over ATM". As part of the course work I am collecting information regarding all related standards in my IPng page, http://nimbus.ocis.temple.edu/~sathya/ipng-atm/ . I am also writing abstracts based on my understanding of what I read. I am sure everybody will agree with me that it is important to make the learning process easy, for the success of IPng (of any protocol for that matter). Even though what I have managed to do may not be really good, I am hopeful it will be a good starting point. I want to make it a good tutorial Page for people interested in IPng and ATM. I think it will better if I get input from others (with more experience) in this field regarding the contents and the organization. I request you all to visit my IPng page (whenever you find time !!!) and send me suggestions. I am prepared to put in the time if I get good feedbacks/ideas to improve my IPng page. Thankx in advance, regards Sathya -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --simple boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------