From owner-ipng@sunroof.eng.sun.com Tue Dec 1 10:35:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA16555 for ipng-dist; Tue, 1 Dec 1998 10:26:27 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA16548 for ; Tue, 1 Dec 1998 10:26:14 -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 KAA02197 for ; Tue, 1 Dec 1998 10:26:13 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA06462 for ; Tue, 1 Dec 1998 10:26:13 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id KAA21109; Tue, 1 Dec 1998 10:25:40 -0800 (PST) Message-Id: <3.0.5.32.19981201102526.008f2d70@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 01 Dec 1998 10:25:26 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6812) W.G. Last Call on "Initial IPv6 Sub-TLA ID Assignments" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an IPng working group last call for comments on advancing the following document as an Informational RFC: Title : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, R. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-00.txt Pages : 5 Date : 17-Nov-98 This document proposes initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries and continued management of the IP6.INT domain. It is intended as input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups as an aid in starting the process of allocating IPv6 addresses. It is not intended for any official IETF status. The goal is to have the IPng w.g. advance this document so it can be approved and sent to the IANA to help expedite the process of starting the allocation of IPng addresses. Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end at the Thursday IETF IPng session on December 10, 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 Wed Dec 2 22:47:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA18584 for ipng-dist; Wed, 2 Dec 1998 22:34:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA18559; Wed, 2 Dec 1998 22:29:47 -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 WAA27606; Wed, 2 Dec 1998 22:29:46 -0800 Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA14535; Wed, 2 Dec 1998 22:29:47 -0800 (PST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA12839; Thu, 3 Dec 1998 15:29:46 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA21631; Thu, 3 Dec 1998 15:29:46 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA27691; Thu, 3 Dec 1998 15:29:45 +0900 (JST) To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 6815) KAME 19981130 stable release From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94b2 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: <19981203152940N.kazu@iijlab.net> Date: Thu, 03 Dec 1998 15:29:40 +0900 X-Dispatcher: imput version 981124(IM104) Lines: 68 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are happy to inform you the stable release of KAME 19981130 for FreeBSD 2.2.7, BSD/OS 3.0, and NetBSD 1.3.2 . The kits are available from: http://www.kame.net/ Summary of the differences from the previous release is enclosed below. Enjoy! --Kazu, KAME Project ---From Here <> - Introduced loop prevention mechanism for gif input and output. <> - Implemented kernel level multicast forwarding with PIM. - Introduced loop prevention mechanism for gif input and output. - Implemented kernel level prefix renumbering mechanism and its API for the "rrenumd" daemon and the "prefix" command. - Gif tunnel IPv6 support as outer encapsulation. (was not possible) - Gif tunnel extension for multiple destination. (contributed by dwiggins@bbn.com) - Neighbor discovery code was stabilized. - ICMPv6 redirect is now working properly. <> <> - IPv4 IPsec (both transport and tunnel) was stabilized very much. - IPsec tunnel now handles path MTU and TCP MSS properly. - IPv4 options are now properly handled by IPsec code. - Most of the ESP/AH algorithms is now confirmed to be interoperable with other implementations. - The "racoon" IKE daemon was updated for better interoperability. - Statistics is now properly gathered. <> - Implemented "pim6dd", a daemon of PIMv2 dense mode for IPv6, to support IPv6 multicast routing. - IPv6 hostname with AAAA record, or numarical IPv6 address escaped by [ ], is supported as proxy server specification for mozilla. - Implemented the "prefix" command for prefix assignment and renumbering inside a node. - Implemented the "rrenumd" daemon for sending router renumbering messages. - Enhanced the "rtadvd" daemon for receiving router renumbering messages and renumbering pre-assigned prefixes. - Resolver was updated to keep binary compatibility with existing implementations. Namely, struct _res is now kept unchanged from original bind distribution. - EPSV/EPRT support for FAITH TCP translator. - "tcpdump" is now able to chase IPv6 header chain and to analyze IPsec related packets. - IPv6-ready logwtmp() and skeyaccess() is now supplied (FreeBSD only). <> - Copyright notice was changed. We are now using 3-clause BSD copyright. - New ports: "apache13", "gated" ("apache" is renamed to "apache12") - "lynx" security hole fix included into the IPv6-ready ports directory. (this is a problem with the original "lynx", not the IPv6 patch) - KAME on NetBSD-pmax is now confirmed to work. ---To Here -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 08:29:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA18858 for ipng-dist; Thu, 3 Dec 1998 08:20:34 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA18851; Thu, 3 Dec 1998 08:20:25 -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 IAA03382; Thu, 3 Dec 1998 08:20:24 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA11601; Thu, 3 Dec 1998 08:20:23 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id LAA16035; Thu, 3 Dec 1998 11:20:20 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA11157; Thu, 3 Dec 1998 11:20:14 -0500 Message-Id: <199812031620.AA11157@quarry.zk3.dec.com> To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 6816) Re: KAME 19981130 stable release In-Reply-To: Your message of "Thu, 03 Dec 1998 15:29:40 +0900." <19981203152940N.kazu@iijlab.net> Date: Thu, 03 Dec 1998 11:20:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good job.............esp the pim................ is this code in the public domain? /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 Dec 3 09:13:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA18932 for ipng-dist; Thu, 3 Dec 1998 09:00:38 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18925; Thu, 3 Dec 1998 09:00:28 -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 JAA09725; Thu, 3 Dec 1998 09:00:28 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA10106; Thu, 3 Dec 1998 09:00:25 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id MAA31472; Thu, 3 Dec 1998 12:00:24 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA02943; Thu, 3 Dec 1998 12:00:19 -0500 Message-Id: <199812031700.AA02943@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 6817) Getting IPv6 Deployed Gathering Needed Date: Thu, 03 Dec 1998 12:00:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Things are moving in the IETF but not as fast as the market needs IPv6 to happen. We have serious implementation issues to address for deployment like which DNS record, which transition mechanism, specs that are moving to slow, etc. I would like to ask folks to meet me in the lobby of the hotel Thurs eve at 8 p.m. for a gathering of what we can do outside of the IETF to assist IPv6 deployment to move more rapidly. IETF stuff will be done for that night. Send me mail privately or grab me at the IETF by Wed a.m. next week if you can make it. There are a lot of back room things going on and I for one am not happy with the evolution of deployment and totally sick of the politics to appease whatever and we need to use the shotgun approach here for the market who wants IPv6 A.S.A.P. I have no clue where we can meet if enough folks are interested but we will find a place. The lobby is the default and if necessary we will go to one of the parks near the hotel. The weather should be fine. Here is what we need to discuss: 1. Vendors - what are the deployment strategies for the next 2 years. What is realistic? 2. Do we have any killer apps we can move quickly and if necessary share code and create a public domain code base? 3. What trade-shows do we need to develop a coordinated demonstration set for IPv6 on the show floors. What application demos can we build. 4. What trade-rags and analysts do we need to probe through our marketing contacts. One VOIP pundit I have the mail from told folks in mail I have that IPv6 is "DEAD" just ask the people working on it at the IETF. We need to fix this and get the analysts the right information, and the pundits. 5. We need a plan for end users and ISPs for deployment. 6. We need to determine how we can get information to the various goverments worldwide and should form a committee to work just on that effort. The whole issue of ICANN and all that is not addressing IPv6 as important as it must and POISED has much more difficult issues to address rigth now. Lets not wait for the present process and between us we can develop a paper that we will position with our relevant governments to explain the need for Ipv6 and why we may need their support. 7. What technology is needed for IPv6 that is happening too slow in the IETF or is just going to take forever with the design by committee approach. Especially around transition mechanisms. Implementors and Architects bring your ideas. Do not come to this gathering if your coming to tell us the IETF is working this or some other body or some czar, etc. Cause it is not happening fast enough. This is for folks who want to develop a plan of attack to get this done where it is not getting done. If it is to turn out to be an IPv6 Consortia or not I just don't know, that is up to the gathering. Worst case we can at least determine what is slowing this up and why it is not moving faster. This is a grass roots effort and we will not appease the politically correct attitude, that has slowed IPv6 up thus far, this I suggest should be this grass roots motto if it happens. /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 Dec 3 09:45:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA19059 for ipng-dist; Thu, 3 Dec 1998 09:35:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA19052 for ; Thu, 3 Dec 1998 09:35:25 -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 JAA28210 for ; Thu, 3 Dec 1998 09:35:22 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA04509 for ; Thu, 3 Dec 1998 09:35:21 -0800 (PST) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA01649; Thu, 3 Dec 1998 09:35:17 -0800 (PST) Message-Id: <3.0.5.32.19981203093441.007cd900@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 09:34:41 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6822) Proposed IPng W.G. Agenda 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 Sorry for the delay, but here is the proposed agenda for the IPng w.g. meeting at the Orlando IETF. Both sessions will be Multicast. In addition to requested topics, we included items for pending documents. Please let us know if this is correct and any other changes/additions. Thanks, Bob Hinden / Steve Deering -------------------------------------------- THURSDAY, December 10 at 1530-1730 (Paradise III) FRIDAY, December 11 at 0900-1130 (Paradise III) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) IPv6 6REN Status and Plans / R. Fink (20 min) Addressing to Draft Standard / R. Hinden (5 min) Initial IANA Sub-TLA Assignments / R. Hinden (10 min) IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) Mobile IPv6 Status / D. Johnson (10 min) IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter (5 min) DNS Extension to Support IP Version 6 / M. Crawford (5 min) Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (5 min) Jumbograms / S. Deering (5 min) Router Renumbering / M. Crawford (5 min) Multicast Listener Discovery Protocol / S. Deering (5 min) Basic API Revision / J. Bound (5 min) Site Prefixes in Neighbor Discovery / E. Nordmark (15 min) IPv6 TCP and anycast address / Jun-ichiro Itoh (10 min) RPC and NFS over IPv6 / L. Wu (15 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 Dec 3 09:46:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA19069 for ipng-dist; Thu, 3 Dec 1998 09:43:10 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA19062 for ; Thu, 3 Dec 1998 09:43:06 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA18786 for ; Thu, 3 Dec 1998 09:43:10 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA25377 for ipng@sunroof.eng.sun.com; Thu, 3 Dec 1998 09:42:39 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18974 for ; Thu, 3 Dec 1998 09:19: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 JAA10952 for ; Thu, 3 Dec 1998 09:19:14 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23283 for ; Thu, 3 Dec 1998 09:19:15 -0800 (PST) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA01010 for ; Thu, 3 Dec 1998 09:19:11 -0800 (PST) Message-Id: <3.0.5.32.19981203091805.00b03cb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 09:18:05 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6823) RFC 2463 on ICMPv6 (ICMP for IPv6) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2463: Title: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s): A. Conta, S. Deering Status: Draft Standard Date: December 1998 Mailbox: aconta@lucent.com, deering@cisco.com Pages: 18 Characters: 34190 Obsoletes: 1885 I-D Tag: draft-ietf-ipngwg-icmp-v2-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2463.txt This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). This document is a product of the IPNG Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981202153227.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2463 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 09:46:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA19078 for ipng-dist; Thu, 3 Dec 1998 09:43:39 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA19071 for ; Thu, 3 Dec 1998 09:43:31 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA18819 for ; Thu, 3 Dec 1998 09:43:34 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA25405 for ipng@sunroof.eng.sun.com; Thu, 3 Dec 1998 09:43:04 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18995 for ; Thu, 3 Dec 1998 09:19: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 JAA19652 for ; Thu, 3 Dec 1998 09:19:22 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23380 for ; Thu, 3 Dec 1998 09:19:22 -0800 (PST) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA01026 for ; Thu, 3 Dec 1998 09:19:18 -0800 (PST) Message-Id: <3.0.5.32.19981203091832.00b05a60@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 09:18:32 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6824) RFC 2464 on IPv6 Packets over Ethernet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2464: Title: Transmission of IPv6 Packets over Ethernet Networks Author(s): M. Crawford Status: Proposed Standard Date: December 1998 Mailbox: crawdad@fnal.gov Pages: 7 Characters: 12725 Obsoletes: 1972 I-D Tag: draft-ietf-ipngwg-trans-ethernet-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc2464.txt This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981202153423.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2464 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 09:46:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA19096 for ipng-dist; Thu, 3 Dec 1998 09:44:31 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA19089 for ; Thu, 3 Dec 1998 09:44:24 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA18957 for ; Thu, 3 Dec 1998 09:44:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA25461 for ipng@sunroof.eng.sun.com; Thu, 3 Dec 1998 09:43:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18982 for ; Thu, 3 Dec 1998 09:19: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 JAA25215 for ; Thu, 3 Dec 1998 09:19:16 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23311 for ; Thu, 3 Dec 1998 09:19:17 -0800 (PST) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA01020 for ; Thu, 3 Dec 1998 09:19:14 -0800 (PST) Message-Id: <3.0.5.32.19981203091720.00afe7f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 09:17:20 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6826) RFC 2461 on Neighbor Discovery for IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2461: Title: Neighbor Discovery for IP Version 6 (IPv6) Author(s): T. Narten, E. Nordmark, W. Simpson Status: Draft Standard Date: December 1998 Mailbox: narten@raleigh.ibm.com, nordmark@sun.com, bsimpson@MorningStar.com Pages: 93 Characters: 222516 Obsoletes: 1970 I-D Tag: draft-ietf-ipngwg-discovery-v2-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2461.txt This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. This document is a product of the IPNG Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981202152730.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2461 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 09:47:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA19087 for ipng-dist; Thu, 3 Dec 1998 09:44:10 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA19080 for ; Thu, 3 Dec 1998 09:44:05 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA18910 for ; Thu, 3 Dec 1998 09:44:09 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA25433 for ipng@sunroof.eng.sun.com; Thu, 3 Dec 1998 09:43:30 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18987 for ; Thu, 3 Dec 1998 09:19:22 -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 JAA19637 for ; Thu, 3 Dec 1998 09:19:19 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23341 for ; Thu, 3 Dec 1998 09:19:18 -0800 (PST) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA01023 for ; Thu, 3 Dec 1998 09:19:16 -0800 (PST) Message-Id: <3.0.5.32.19981203091753.00b01d60@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 09:17:53 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6825) RFC 2462 on IPv6 Stateless Address Autoconfiguration Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2462: Title: IPv6 Stateless Address Autoconfiguration Author(s): S. Thomson, T. Narten Status: Draft Standard Date: December 1998 Mailbox: set@thumper.bellcore.com, narten@raleigh.ibm.com Pages: 25 Characters: 61210 Obsoletes: 1971 I-D Tag: draft-ietf-ipngwg-addrconf-v2-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2462.txt This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. This document is a product of the IPNG Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981202153022.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2462 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 10:09:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA19157 for ipng-dist; Thu, 3 Dec 1998 09:57:44 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA19150; Thu, 3 Dec 1998 09:57:35 -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 JAA18931; Thu, 3 Dec 1998 09:57:35 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA20209; Thu, 3 Dec 1998 09:57:33 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id CAA21329; Fri, 4 Dec 1998 02:57:27 +0900 (JST) To: ngtrans@sunroof.eng.sun.com cc: Kazu Yamamoto (=?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Thu, 03 Dec 1998 11:20:13 EST. <199812031620.AA11157@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 6827) Re: (ngtrans) Re: KAME 19981130 stable release Date: Fri, 04 Dec 1998 02:57:26 +0900 Message-ID: <21325.912707846@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >good job.............esp the pim................ >is this code in the public domain? KAME code is redistributed under BSD-like copyright. (attached) itojun --- Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the project nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 11:25:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA19340 for ipng-dist; Thu, 3 Dec 1998 11:13:37 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA19333 for ; Thu, 3 Dec 1998 11:13: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 LAA09802 for ; Thu, 3 Dec 1998 11:13:28 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.192.13]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA17525 for ; Thu, 3 Dec 1998 11:13:06 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA23083; Thu, 3 Dec 1998 11:11:40 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <3.0.5.32.19981203093441.007cd900@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Dec 1998 11:11:48 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 6828) Re: Proposed IPng W.G. Agenda Cc: hinden@iprg.nokia.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Note: The proposed agenda that we posted this morning includes a number of topics that were not explicitly requested, but which we think are, or may be, outstanding. Please look through the list and, especially if you are listed as a presentor, let us know if the topic should be deleted or the alloted time changed. Bob & Steve > THURSDAY, December 10 at 1530-1730 (Paradise III) > FRIDAY, December 11 at 0900-1130 (Paradise III) > > > Introduction / S. Deering (5 min) > Review Agenda / S. Deering (5 min) > Document Status / R. Hinden (10 min) > IPv6 6REN Status and Plans / R. Fink (20 min) > Addressing to Draft Standard / R. Hinden (5 min) > Initial IANA Sub-TLA Assignments / R. Hinden (10 min) > IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) > Mobile IPv6 Status / D. Johnson (10 min) > IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter (5 min) > DNS Extension to Support IP Version 6 / M. Crawford (5 min) > Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (5 min) > Jumbograms / S. Deering (5 min) > Router Renumbering / M. Crawford (5 min) > Multicast Listener Discovery Protocol / S. Deering (5 min) > Basic API Revision / J. Bound (5 min) > Site Prefixes in Neighbor Discovery / E. Nordmark (15 min) > IPv6 TCP and anycast address / Jun-ichiro Itoh (10 min) > RPC and NFS over IPv6 / L. Wu (15 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 Dec 3 11:25:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA19364 for ipng-dist; Thu, 3 Dec 1998 11:19:17 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id LAA19357 for ; Thu, 3 Dec 1998 11:19:12 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA05626 for ; Thu, 3 Dec 1998 11:19:15 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA25741 for ipng@sunroof.eng.sun.com; Thu, 3 Dec 1998 11:18:45 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA19345 for ; Thu, 3 Dec 1998 11: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 LAA13722 for ; Thu, 3 Dec 1998 11:16:26 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id LAA23447 for ; Thu, 3 Dec 1998 11:16:26 -0800 (PST) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA06282 for ; Thu, 3 Dec 1998 11:06:20 -0800 (PST) Message-Id: <3.0.5.32.19981203105535.007e3250@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 10:55:35 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6830) RFC 2460 on IPv6 Specification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2460: Title: Internet Protocol, Version 6 (IPv6) Specification Author(s): S. Deering, R. Hinden Status: Draft Standard Date: December 1998 Mailbox: deering@cisco.com, hinden@iprg.nokia.com Pages: 37 Characters: 85890 Obsoletes: 1883 I-D Tag: draft-ietf-ipngwg-ipv6-spec-v2-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2460.txt This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. This document is a product of the IPNG Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203095818.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2460 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 14:28:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA19636 for ipng-dist; Thu, 3 Dec 1998 14:19:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA19629; Thu, 3 Dec 1998 14:18: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 OAA26484; Thu, 3 Dec 1998 14:18:47 -0800 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAB24916; Thu, 3 Dec 1998 14:18:46 -0800 (PST) Received: from alden ([193.216.167.143]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id XAA05631; Thu, 3 Dec 1998 23:18:26 +0100 Message-Id: <3.0.2.32.19981203225552.00a725a0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 03 Dec 1998 22:55:52 +0100 To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Harald Tveit Alvestrand Subject: (IPng 6831) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed Cc: bound@zk3.dec.com In-Reply-To: <199812031700.AA02943@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, IMNSHO, IPv6 is now a specified protocol. The main job of a standards org is over. What comes next MUST happen outside the IETF, with the IETF serving only as meeting place/contact area/supporting-protocol standardization. random thought: If there were a way in which a Linux/*BSD/*any box could auto-connect to the 6bone when turned on and having IPv4 connectivity, rather than going through all the "where's my tunnel" mess, grass-roots adoption could happen faster. One thread I see now is that many people building various applications want the "I have an address and I know what it is and you know what it is and know that it's me" paradigm of NAT-less IPv4 back. A lot of these applications are *NOT* "old protocols", and could perhaps live easily in an IPv6-over-IPv4 world. If there was a way to make IPv6 self-deploy. random ramblings.... Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 16:52:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA19820 for ipng-dist; Thu, 3 Dec 1998 16:42:59 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA19788 for ; Thu, 3 Dec 1998 16:42:39 -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 QAA11140 for ; Thu, 3 Dec 1998 16:42:39 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA26900 for ; Thu, 3 Dec 1998 16:42:37 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA23540 for ; Thu, 3 Dec 1998 16:42:36 -0800 (PST) Message-Id: <3.0.5.32.19981203163601.00b31e50@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 16:36:01 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6832) RFC 2452 on TCP MIB for IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2452: Title: IP Version 6 Management Information Base for the Transmission Control Protocol Author(s): M. Daniele Status: Proposed Standard Date: December 1998 Mailbox: daniele@zk3.dec.com Pages: 10 Characters: 19070 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-ipngwg-ipv6-tcp-mib-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2452.txt This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203122519.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2452 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 16:52:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA19823 for ipng-dist; Thu, 3 Dec 1998 16:43:22 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA19807 for ; Thu, 3 Dec 1998 16:42:47 -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 QAA03761 for ; Thu, 3 Dec 1998 16:42:44 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA26990 for ; Thu, 3 Dec 1998 16:42:44 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA23553 for ; Thu, 3 Dec 1998 16:42:43 -0800 (PST) Message-Id: <3.0.5.32.19981203163701.00b50590@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 16:37:01 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6835) RFC 2466 on IPv6 MIB: ICMPv6 Group Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2466: Title: Management Information Base for IP Version 6: ICMPv6 Group Author(s): D. Haskin, S. Onishi Status: Proposed Standard Date: December 1998 Mailbox: dhaskin@baynetworks.com, sonishi@baynetworks.com Pages: 16 Characters: 27547 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-ipngwg-ipv6-icmp-mib-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2466.txt This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203123919.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2466 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 16:53:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA19821 for ipng-dist; Thu, 3 Dec 1998 16:43:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA19791 for ; Thu, 3 Dec 1998 16:42: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 QAA29181 for ; Thu, 3 Dec 1998 16:42:37 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA26909 for ; Thu, 3 Dec 1998 16:42:37 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA23543 for ; Thu, 3 Dec 1998 16:42:36 -0800 (PST) Message-Id: <3.0.5.32.19981203163628.00b3c720@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 16:36:28 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6833) RFC 2454 on UDP MIB for IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2454: Title: IP Version 6 Management Information Base for the User Datagram Protocol Author(s): M. Daniele Status: Proposed Standard Date: December 1998 Mailbox: daniele@zk3.dec.com Pages: 9 Characters: 15862 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-ipngwg-ipv6-udp-mib-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2454.txt This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203123443.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2454 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 16:53:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA19822 for ipng-dist; Thu, 3 Dec 1998 16:43:18 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA19805 for ; Thu, 3 Dec 1998 16:42: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 QAA03759 for ; Thu, 3 Dec 1998 16:42:44 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA26982 for ; Thu, 3 Dec 1998 16:42:44 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA23547 for ; Thu, 3 Dec 1998 16:42:37 -0800 (PST) Message-Id: <3.0.5.32.19981203163642.00b49a40@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 16:36:42 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6834) RFC 2465 on IPv6 MIB: General Group Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2465: Title: Management Information Base for IP Version 6: Textual Conventions and General Group Author(s): D. Haskin, S. Onishi Status: Proposed Standard Date: December 1998 Mailbox: dhaskin@baynetworks.com, sonishi@baynetworks.com Pages: 38 Characters: 77339 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-ipngwg-ipv6-mib-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc2465.txt This document is one in the series of documents that provide MIB definitions for 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 is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203122416.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2465 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 17:43:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19991 for ipng-dist; Thu, 3 Dec 1998 17:34:29 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19976 for ; Thu, 3 Dec 1998 17:34: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 RAA20225 for ; Thu, 3 Dec 1998 17:34:06 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA00383 for ; Thu, 3 Dec 1998 17:33:57 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA25944 for ; Thu, 3 Dec 1998 17:33:42 -0800 (PST) Message-Id: <3.0.5.32.19981203173311.00b53ce0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 17:33:11 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6836) RFC 2467 on IPv6 over FDDI Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2467: Title: Transmission of IPv6 Packets over FDDI Networks Author(s): M. Crawford Status: Proposed Standard Date: December 1998 Mailbox: crawdad@fnal.gov Pages: 9 Characters: 16028 Obsoletes: 2019 I-D Tag: draft-ietf-ipngwg-trans-fddi-net-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2467.txt This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203163158.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2467 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 17:43:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19992 for ipng-dist; Thu, 3 Dec 1998 17:34:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19980 for ; Thu, 3 Dec 1998 17:34: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 RAA09327 for ; Thu, 3 Dec 1998 17:34:06 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA00250 for ; Thu, 3 Dec 1998 17:34:00 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA25939 for ; Thu, 3 Dec 1998 17:33:41 -0800 (PST) Message-Id: <3.0.5.32.19981203173239.00badda0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 17:32:39 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6837) RFC 2450 on Proposed TLA and NLA Assignment Rules Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. Title: Proposed TLA and NLA Assignment Rules Author(s): R. Hinden Status: Informational Date: December 1998 Mailbox: hinden@iprg.nokia.com Pages: 11 Characters: 24484 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-ipngwg-tla-assignment-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2450.txt This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. This document is a product of the IPNG Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203162857.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2450 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 18:11:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA20090 for ipng-dist; Thu, 3 Dec 1998 17:58:21 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA20083 for ; Thu, 3 Dec 1998 17:57: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 RAA16159 for ; Thu, 3 Dec 1998 17:57:42 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA17131 for ; Thu, 3 Dec 1998 17:57:42 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA26784 for ; Thu, 3 Dec 1998 17:57:41 -0800 (PST) Message-Id: <3.0.5.32.19981203175231.00b0d860@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 17:52:31 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6839) RFC 2471 on IPv6 Testing Address Allocation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2471: Title: IPv6 Testing Address Allocation Author(s): R. Hinden, R. Fink, J. Postel (deceased) Status: Experimental Date: December 1998 Mailbox: hinden@ipsilon.com, rlfink@lbl.gov Pages: 5 Characters: 8031 Obsoletes: 1897 I-D Tag: draft-ietf-ipngwg-testv2-addralloc-01.txt URL: ftp://ftp.isi.edu/in-notes/rfc2471.txt This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. This document is a product of the IPNG Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203163906.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2471 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 18:11:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA20065 for ipng-dist; Thu, 3 Dec 1998 17:53:25 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA20058 for ; Thu, 3 Dec 1998 17:53:14 -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 RAA15426 for ; Thu, 3 Dec 1998 17:53:12 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA13855 for ; Thu, 3 Dec 1998 17:53:12 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA26526 for ; Thu, 3 Dec 1998 17:51:34 -0800 (PST) Message-Id: <3.0.5.32.19981203174809.00b56670@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 17:48:09 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6838) RFC 2470 on IPv6 over Token Ring Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2470: Title: Transmission of IPv6 Packets over Token Ring Networks Author(s): M. Crawford, T. Narten, S. Thomas Status: Proposed Standard Date: December 1998 Mailbox: crawdad@fnal.gov, narten@raleigh.ibm.com, stephen.thomas@transnexus.com Pages: 11 Characters: 21677 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-ipngwg-trans-tokenring-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2470.txt This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981203163602.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2470 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 3 18:26:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA20114 for ipng-dist; Thu, 3 Dec 1998 18:07:25 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA20107 for ; Thu, 3 Dec 1998 18:07: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 SAA17508 for ; Thu, 3 Dec 1998 18:07:12 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA22160 for ; Thu, 3 Dec 1998 18:07:13 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id SAA27143; Thu, 3 Dec 1998 18:07:12 -0800 (PST) Message-Id: <3.0.5.32.19981203180702.00b5b880@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 18:07:02 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6840) W.G. Last Call on "The IPv6 Jumbo Payload Option" 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 : The IPv6 Jumbo Payload Option Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-jumbo-00.txt Pages : 5 Date : 07-Aug-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end one week from today on December 10, 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 Fri Dec 4 04:20:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA20532 for ipng-dist; Fri, 4 Dec 1998 04:10:15 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA20511; Fri, 4 Dec 1998 04:07: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 EAA20844; Fri, 4 Dec 1998 04:06:59 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA16881; Fri, 4 Dec 1998 04:06:57 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA39664; Fri, 4 Dec 1998 12:06:55 GMT Received: from hursley.ibm.com (lig32-227-10-105.us.lig-dial.ibm.com [32.227.10.105]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA21364; Fri, 4 Dec 1998 12:06:47 GMT Message-ID: <366758E5.100C1B15@hursley.ibm.com> Date: Fri, 04 Dec 1998 03:37:09 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 6841) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed References: <3.0.2.32.19981203225552.00a725a0@dokka.maxware.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually Harald I somewhat disagree. There are still new ideas on transition mechanisms showing up, and the fact that the base standards are done doesn't mean that the IETF work is done. One job we need to talk about is a trawl through all existing standards looking for IPv4-dependencies (rather like the trawl we did for Y2K issues). Nevertheless there is an issue of getting applications enabled and deployment rolling, and that's worth a walk in the park. Brian Harald Tveit Alvestrand wrote: > > Jim, > > IMNSHO, IPv6 is now a specified protocol. The main job of a standards > org is over. > What comes next MUST happen outside the IETF, with the IETF serving only > as meeting place/contact area/supporting-protocol standardization. > > random thought: > > If there were a way in which a Linux/*BSD/*any box could auto-connect to the > 6bone when turned on and having IPv4 connectivity, rather than going through > all the "where's my tunnel" mess, grass-roots adoption could happen faster. > > One thread I see now is that many people building various applications want > the "I have an address and I know what it is and you know what it is and > know that it's me" paradigm of NAT-less IPv4 back. A lot of these > applications are *NOT* > "old protocols", and could perhaps live easily in an IPv6-over-IPv4 world. > > If there was a way to make IPv6 self-deploy. > > random ramblings.... > > Harald > -- > Harald Tveit Alvestrand, Maxware, Norway > Harald.Alvestrand@maxware.no -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 4 05:40:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA20605 for ipng-dist; Fri, 4 Dec 1998 05:24:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA20583; Fri, 4 Dec 1998 05:19: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 FAA28223; Fri, 4 Dec 1998 05:19:25 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA09419; Fri, 4 Dec 1998 05:19:26 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id IAA18019; Fri, 4 Dec 1998 08:19:24 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA28628; Fri, 4 Dec 1998 08:19:22 -0500 Message-Id: <199812041319.AA28628@quarry.zk3.dec.com> To: Harald Tveit Alvestrand Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: (IPng 6842) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed In-Reply-To: Your message of "Thu, 03 Dec 1998 22:55:52 +0100." <3.0.2.32.19981203225552.00a725a0@dokka.maxware.no> Date: Fri, 04 Dec 1998 08:19:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Harald, >IMNSHO, IPv6 is now a specified protocol. The main job of a standards >org is over. >What comes next MUST happen outside the IETF, with the IETF serving only >as meeting place/contact area/supporting-protocol standardization. Only the core specs. We still need transition mechanisms, DHCPv6, Routing Protocols, Large Scale Mulitcast, Service Location for IPv6, etc. etc. etc. to reach draft standards. But I agree the core specs are done but there is still work to do in the IETF. For example we have enough done to deploy for early adopters who will begin seeding IPv6 with some IPv6 Routers and IPv6 UNIX Servers and High End Server. Even the ISPs could start with the implementations now. But as an example for a DHCv6 Relay and Server we need IPv6 Multicast Routing to work and be specified. This brings to mind also the importance of Router Renumbering too. Anyway there is still IETF work to do and implementation evolution to be planned, like which IPv4 system apps must be there first NFS, Network Utilities, Sys Calls affected by IPv6, X-Windows, etc... etc.. These are the kinds of questions we need to ask at a gathering. Also some of the assumptions and premises we had are wrong now about how customers will deploy IPv6. But if I were to pick the one most urgent reason for IPv6 I would say it is imperative to keep the paradigm of the end-to-end model in our professions and on the Internet. I like the idea of self-deploying IPv6 nodes we need to think about this outside of the IETF. 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 Fri Dec 4 07:30:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20726 for ipng-dist; Fri, 4 Dec 1998 07:26:23 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20719 for ; Fri, 4 Dec 1998 07:26: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 HAA00491 for ; Fri, 4 Dec 1998 07:26:09 -0800 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA04297 for ; Fri, 4 Dec 1998 07:26:03 -0800 (PST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id AAA21699; Sat, 5 Dec 1998 00:25:11 +0900 (JST) Received: from splash.isl.rdc.toshiba.co.jp (splash.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id AAA12430; Sat, 5 Dec 1998 00:23:43 +0900 (JST) Received: from localhost (perfume.isl.rdc.toshiba.co.jp [133.196.16.145]) by splash.isl.rdc.toshiba.co.jp (8.8.8/8.8.8/4.6) with ESMTP id AAA23514; Sat, 5 Dec 1998 00:25:11 +0900 (JST) To: deering@cisco.com, fenner@parc.xerox.com, haberman@raleigh.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6844) MLD query with 0 Maximum Response Delay X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981205002154P.jinmei@isl.rdc.toshiba.co.jp> Date: Sat, 05 Dec 1998 00:21:54 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980905(IM100) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a question about Multicast Listener Discovery. The draft draft-ietf-ipngwg-mld-00 says about Maximum Response Delay as follows; When a node receives a General Query, it sets a delay timer for each multicast address to which it is listening on the interface from which it received the Query, EXCLUDING the link-scope all-nodes address and any multicast addresses of scope 0 (reserved) or 1 (node-local). Each timer is set to a different random value, using the highest clock granularity available on the node, selected from the range (0, Maximum Response Delay] with Maximum Response Delay as specified in the Query packet. The description seems to assume that Maximum Response Delay is greater than 0(note the round bracket at the last sentence). But there seems no description how we treat a query if its Maximum Response Delay field is 0. Should we discard such a query? Or do we have to process such a query in a special manner? I would like to hear the specification authors' opinion. Thanks in advance, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.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 Dec 4 07:31:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20710 for ipng-dist; Fri, 4 Dec 1998 07:17:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20703 for ; Fri, 4 Dec 1998 07:17:25 -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 HAA06070 for ; Fri, 4 Dec 1998 07:17:23 -0800 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA29866 for ; Fri, 4 Dec 1998 07:17:21 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id JAA24119; Fri, 4 Dec 1998 09:17:09 -0600 (CST) Date: Fri, 4 Dec 1998 09:17:09 -0600 (CST) From: David Borman Message-Id: <199812041517.JAA24119@frantic.bsdi.com> To: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: (IPng 6843) Re: W.G. Last Call on "The IPv6 Jumbo Payload Option" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First, I am not suggesting that this needs to be done at this time, but it is something to think about before advancing to draft. Since the Jumbo Payload option has been split out from the base IPv6 spec, would it make sense to combine it with RFC 2147 ("TCP and UDP over IPv6 Jumbograms") into a single document? For this document, it probably should have a reference to RFC 2147. -David Borman, dab@bsdi.com > Date: Thu, 03 Dec 1998 18:07:02 -0800 > From: Bob Hinden > Subject: (IPng 6840) W.G. Last Call on "The IPv6 Jumbo Payload Option" > > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: > > Title : The IPv6 Jumbo Payload Option > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-jumbo-00.txt > Pages : 5 > Date : 07-Aug-98 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end one > week from today on December 10, 1998. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 4 08:04:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20786 for ipng-dist; Fri, 4 Dec 1998 07:51:21 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20776 for ; Fri, 4 Dec 1998 07:51:02 -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 HAA15485 for ; Fri, 4 Dec 1998 07:51:00 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA17746 for ; Fri, 4 Dec 1998 07:50:58 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id AAA06779 for ; Sat, 5 Dec 1998 00:50:47 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: rfc-ed's message of Thu, 03 Dec 1998 09:17:20 PST. <3.0.5.32.19981203091720.00afe7f0@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 6845) Re: RFC 2461 on Neighbor Discovery for IPv6 From: Jun-ichiro itojun Itoh MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <6767.912786632.0@coconut.itojun.org> Date: Sat, 05 Dec 1998 00:50:47 +0900 Message-ID: <6775.912786647@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6767.912786632.1@coconut.itojun.org> Content-Transfer-Encoding: 7bit >A new Request for Comments is now available in online RFC libraries. > RFC 2461: > Title: Neighbor Discovery for IP Version 6 (IPv6) > Author(s): T. Narten, E. Nordmark, W. Simpson Is there any intention to update this document (discovery-v3)? As attached, I believe - behavior on medium without link-layer address, and - IsRouter flag needs to be revisited. I believe both are important as ND has to be independent from actual medium (current document is okay if we assume ethernet-like medium, but we need to write medium-independent code!) itojun ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with SMTP id VAA26185 for ; Thu, 5 Nov 1998 21:27:38 +0900 (JST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA27890; Thu, 5 Nov 1998 04:14:53 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id EAA23980; Thu, 5 Nov 1998 04:14:50 -0800 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA16156 for ipng-dist; Thu, 5 Nov 1998 04:09:04 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA16149 for ; Thu, 5 Nov 1998 04:08:53 -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 EAA11542 for ; Thu, 5 Nov 1998 04:08:51 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA10580; Thu, 5 Nov 1998 04:08:51 -0800 (PST) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id VAA24755; Thu, 5 Nov 1998 21:08:33 +0900 (JST) To: nordmark@Sun.COM, narten@raleigh.ibm.com, bsimpson@MorningStar.com cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 6697) discovery-v2-03 questions (neighbor cache handling) X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Itoh Date: Thu, 05 Nov 1998 21:08:33 +0900 Message-ID: <24751.910267713@coconut.itojun.org> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org MIME-Version: 1.0 I got several questions related to ND6 protocol spec, namely discovery-v2-03. In the following, "lladdr" means "link-layer address", such as ethernet MAC address. I would like to know opinions from implementers, how UNH interop test understands the spec, and so forth. Thanks, itojun@kame.net itojun@iijlab.net jun-ichiro itoh 1. neighbor cache processing rule when no lladdr is attached. ============================================================= ND6 specification defines the following conditions for src/dst lladdr option, for each ND6 packet type: RS: medium w/o lladdr: not needed (can't attach) medium with lladdr: source lladdr option SHOULD be included, if lladdr is known RA: medium w/o lladdr: not needed (can't attach) medium with lladdr: router MAY attach source lladdr option, MAY omit it for load balancing NS: medium w/o lladdr: not needed (can't attach) medium with lladdr: source lladdr option MUST be attached for multicast solicitation, SHOULD be attached for unicast solicitation redirect: medium w/o lladdr: not needed (can't attach) medium with lladdr: target lladdr option SHOULD be included if known. (ATM) MUST be included on some medium. As seen in the above list, it is not rare to see RS/RA/NS/redirect packet, WITHOUT source/target lladdr option. However, the following sections in discovery-v2-03 assume that source/target lladdr is attached to ND packet: 6.2.6(RS) 6.3.4(RA) 7.2.3(NS) 8.3(redirect) appendix C, second state transition chart (p87 to p88) must be clarified for the following 3 cases: medium without lladdr medium with lladdr, packet with lladdr medium with lladdr, packet without lladdr This should be fixed. Also, 6.2.6, 6.3.4, 7.2.3 and 8.3 has almost the same textual description for neighbor cache updates. I believe these duplicates should be merged into one section somewhere. It is not very trivial to clarify. Choices might be: 1. do not make neighbor cache if there's no lladdr, or 2. make neighbor cache with some state. However, these ways do not work very well. 1. If you do not make neighbor cache entry: You cannot record IsRouter flag, and you will have chances for stale entry on default router list. For example, the following list of event will create a stale entry: router X transmits RA without lladdr. Host Y will install default router list entry for X. No neighbor cache entry created. router X becomes host. host X (previously router X) transmits NS with lladr. Default router list entry for X remains on the host Y. Neighbor cache entry will be created, with IsRouter 0, based on NS processing rule. Now, you got a problem. If you try to send a packet to off-link destination, you will be sending packet to host X. If host Y ignores "RA without lladdr", there will be no stale default router list entry. However, in this case, router X can never achieve load balancing among the routers by sending "RA without lladdr" from routers. The source of the problem is recaped in the second question, "neighbor cache entry and default router list". See the last part of the email. What should on medium without lladdr? It is still unclear for us. 2a. If you make neighbor cache entry with INCOMPLETE state: INCOMPLETE state does not really fit this situation. INCOMPLETE is defined as: Address resolution is in progress and the link-layer address of the neighbor has not yet been determined. However, we have never performed address resolution for this entry. It is not good to require address resolution for every "RA without lladdr". 2b. If you make neighbor cache entry with some state other than INCOMPLETE If there is an entry with non-INCOMLETE state, it is assumed that the entry once has lladdr for the target in the past. Therefore, it is not very suitable for this situation. If you set the state to STALE you have a big problem --- DELAY state will defer your future address resolution. Here are solutions we came up with. Solution 1: (from jinmei@kame.net) If a node receives ND packet without lladdr, do not make neighbor cache. If node is about to send a pacet to off-link destination, and router X is chosen from default router list, and there is no neighbor cache entry for router X, node should perform the following. - make neighbor cache entry - set it INCOMPLETE - set IsRouter bit for the entry - perform neighbor discovery - transmit packet if ND completed /* * new entry: neighbor cache entrys is created * olladdr: neighbor cache entry got old lladdr * lladdr: packet contains lladdr option * llchange: olladdr != lladdr * * newentry olladdr lladdr llchange (*=record lladdr) * 0 n n -- (1) * 0 y n -- (2) * 0 n y -- (3) * set state to STALE * 0 y y n (4) * * 0 y y y (5) * set state to STALE * 1 -- n -- (6) (don't create entry) * 1 -- y -- (7) * set state to STALE */ Solution 2: (from itojun@kame.net) Define a new neighbor cache state, PASSIVE. PASSIVE entry will be made when a node received ND packets without lladdr. If a node received RA/RS/NS/redirect without lladdr option, 1. create neighbor cache entry, 2. make it PASSIVE state, and 3. set IsRouter flag properly. You MUST NOT remove neighbor cache entry for node A, if node A is listed in default router list. The above rule still works if there's no lladdr defined for the medium. /* * new entry: neighbor cache entrys is created * olladdr: neighbor cache entry got old lladdr * lladdr: packet contains lladdr option * llchange: olladdr != lladdr * * newentry olladdr lladdr llchange (*=record lladdr) * 0 n n -- (1) * 0 y n -- (2) * 0 n y -- (3) * set state to STALE * 0 y y n (4) * * 0 y y y (5) * set state to STALE * 1 -- n -- (6) set state to PASSIVE * 1 -- y -- (7) * set state to STALE */ /* * ICMP6 type dependent behavior. * * NS: clear IsRouter if new entry * RS: clear IsRouter * RA: set IsRouter if there's lladdr * redir: clear IsRouter if new entry * * newentry olladdr lladdr llchange NS RS RA redir * 0 n n -- (1) c s? * 0 y n -- (2) c s * 0 n y -- (3) c s * 0 y y n (4) c s * 0 y y y (5) c s * 1 -- n -- (6) c c s? c * 1 -- y -- (7) c c s c * * (c=clear s=set) */ Clarification 1: To make implementations easy, rules for source/target lladdr option for ND packets should be: - on medium with lladdr: MUST attach one - on medium w/o lladdr: not needed (and cannot attach) 2. neighbor cache entry and default router list =============================================== Rules for IsRouter bit is "edge trigger" in nature. Therefore, IsRouter rule works only if the following statement is satisfied: For a node that is listed onto default router list, there always be a neighbor cache entry. This must be clearly stated somewhere in document. (What happens on medium ithout lladdr?? We still need to make neighbor cache entry just for IsRouter bit) IsRouter bit must be revisited, really. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------- =_aaaaaaaaaa0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 4 08:49:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA20823 for ipng-dist; Fri, 4 Dec 1998 08:32:27 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA20816 for ; Fri, 4 Dec 1998 08:32:11 -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 IAA22064 for ; Fri, 4 Dec 1998 08:32:10 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA10631 for ; Fri, 4 Dec 1998 08:32:08 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA12177; Fri, 4 Dec 1998 17:31:24 +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 RAA19579; Fri, 4 Dec 1998 17:31:23 +0100 (MET) Message-Id: <199812041631.RAA19579@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: deering@cisco.com, fenner@parc.xerox.com, haberman@raleigh.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 6846) Re: MLD query with 0 Maximum Response Delay In-reply-to: Your message of Sat, 05 Dec 1998 00:21:54 +0900. <19981205002154P.jinmei@isl.rdc.toshiba.co.jp> Date: Fri, 04 Dec 1998 17:31:22 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The description seems to assume that Maximum Response Delay is greater than 0. => this question is important because in some (not yet fixed :-) implementations a zero MDR gives a division by 0 (ie a bug). Obvious fix is to round MDR to a small value (1 for instance) but is it correct ? Thanks Francis.Dupont@inria.fr PS: for UNH (or other) test suite, add zero MDR in nasty packet list... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 4 08:53:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA20856 for ipng-dist; Fri, 4 Dec 1998 08:44:04 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA20838 for ; Fri, 4 Dec 1998 08:43: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 IAA22658 for ; Fri, 4 Dec 1998 08:43:42 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.192.13]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA17419 for ; Fri, 4 Dec 1998 08:43:37 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA06851; Fri, 4 Dec 1998 08:42:13 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <19981205002154P.jinmei@isl.rdc.toshiba.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Dec 1998 08:42:23 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: (IPng 6847) Re: MLD query with 0 Maximum Response Delay Cc: fenner@parc.xerox.com, haberman@raleigh.ibm.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:21 AM -0800 12/4/98, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > The description seems to assume that Maximum Response Delay is greater > than 0(note the round bracket at the last sentence). But there seems > no description how we treat a query if its Maximum Response Delay field > is 0. Should we discard such a query? Or do we have to process such a > query in a special manner? Good catch! MLD was derived from IGMPv2. In IGMP, a Maximum Response Delay value of zero identifies the query as a version 1 query. (In IGMPv1, the Maximum Response Field was not defined, and those bits were required to be set to zero.) An IGMPv2 receiver of a query with a Maximum Response Delay value of zero is required to interpret that as a delay of 10 seconds, because that is the (fixed) delay that was specified for IGMPv1. Now, none of this is relevant to MLD, because there is no need for the same backwards compatibility with an older version. Therefore, you are absolutely correct: we need to define how the value zero is to be interpreted. My inclination is to just say that zero means zero, i.e., no delay, and therefore, change the "(0, Maximum Response Delay]" expression to "[0, Maximum Response Delay]". Having the ability to set the maximum delay to zero seems like a desirable feature for the case of MLD on point-to-point links, where there is no "implosion hazard". 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 Fri Dec 4 08:55:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA20861 for ipng-dist; Fri, 4 Dec 1998 08:44:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA20836; Fri, 4 Dec 1998 08:43: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 IAA15659; Fri, 4 Dec 1998 08:43:40 -0800 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA17391; Fri, 4 Dec 1998 08:43:28 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA13887; Fri, 4 Dec 1998 16:40:14 GMT Received: from cjh.rdg.opengroup.org [192.153.166.111] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Fri Dec 04 16:40 GMT 1998 Message-Id: <3.0.3.32.19981204162959.0083d9e0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 04 Dec 1998 16:29:59 +0000 To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 6848) Re: (c.harding 23195) Getting IPv6 Deployed Gathering Needed Cc: xnet@opengroup.org In-Reply-To: <199812031700.AA02943@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jim, I would like to participate in your lobby meeting. I think that this is an area in which The Open Group can and should help, not by specification development, but by - - giving users information on the progress of IPv6 and on what it will mean for them - providing a forum in which users and vendors can come together to discuss deployment issues - providing feedback to product developers and to the spec writers in the IETF. See you next week! >Folks, > >Things are moving in the IETF but not as fast as the market needs IPv6 >to happen. We have serious implementation issues to address for >deployment like which DNS record, which transition mechanism, specs that are >moving to slow, etc. > >I would like to ask folks to meet me in the lobby of the hotel Thurs eve >at 8 p.m. for a gathering of what we can do outside of the IETF to >assist IPv6 deployment to move more rapidly. IETF stuff will be done >for that night. Send me mail privately or grab me at the IETF by Wed >a.m. next week if you can make it. There are a lot of back room things >going on and I for one am not happy with the evolution of deployment and >totally sick of the politics to appease whatever and we need to use the >shotgun approach here for the market who wants IPv6 A.S.A.P. > >I have no clue where we can meet if enough folks are interested but we >will find a place. The lobby is the default and if necessary we will go >to one of the parks near the hotel. The weather should be fine. > >Here is what we need to discuss: > > 1. Vendors - what are the deployment strategies for the next 2 years. > What is realistic? > > 2. Do we have any killer apps we can move quickly and if necessary > share code and create a public domain code base? > > 3. What trade-shows do we need to develop a coordinated demonstration > set for IPv6 on the show floors. What application demos can > we build. > > 4. What trade-rags and analysts do we need to probe through our > marketing contacts. One VOIP pundit I have the mail from told > folks in mail I have that IPv6 is "DEAD" just ask the people > working on it at the IETF. We need to fix this and get the > analysts the right information, and the pundits. > > 5. We need a plan for end users and ISPs for deployment. > > 6. We need to determine how we can get information to the various > goverments worldwide and should form a committee to work just > on that effort. The whole issue of ICANN and all that is not > addressing IPv6 as important as it must and POISED has much > more difficult issues to address rigth now. Lets not wait for > the present process and between us we can develop a paper that > we will position with our relevant governments to explain the > need for Ipv6 and why we may need their support. > > 7. What technology is needed for IPv6 that is happening too slow > in the IETF or is just going to take forever with the design > by committee approach. Especially around transition mechanisms. > Implementors and Architects bring your ideas. > >Do not come to this gathering if your coming to tell us the IETF is >working this or some other body or some czar, etc. Cause it is not >happening fast enough. This is for folks who want to develop a plan of >attack to get this done where it is not getting done. If it is to turn >out to be an IPv6 Consortia or not I just don't know, that is up to the >gathering. > >Worst case we can at least determine what is slowing this up and why it >is not moving faster. > >This is a grass roots effort and we will not appease the politically >correct attitude, that has slowed IPv6 up thus far, this I suggest should >be this grass roots motto if it happens. > >/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 >-------------------------------------------------------------------- > > 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 Fri Dec 4 13:02:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA21260 for ipng-dist; Fri, 4 Dec 1998 12:46:26 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA21253 for ; Fri, 4 Dec 1998 12:46: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 MAA08679 for ; Fri, 4 Dec 1998 12:46:07 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA19367 for ; Fri, 4 Dec 1998 12:45:58 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id MAA27285 for ; Fri, 4 Dec 1998 12:45:24 -0800 (PST) Message-Id: <3.0.5.32.19981204124505.00af6100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 04 Dec 1998 12:45:05 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6849) RFC 2472 on IP Version 6 over PPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2472: Title: IP Version 6 over PPP Author(s): D. Haskin, E. Allen Status: Proposed Standard Date: December 1998 Mailbox: dhaskin@baynetworks.com, eallen@baynetworks.com Pages: 14 Characters: 29696 Obsoletes: 2023 I-D Tag: draft-ietf-ipngwg-ipv6-over-ppp-06.txt URL: ftp://ftp.isi.edu/in-notes/rfc2472.txt 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. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981204115249.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2472 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 4 15:56:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA21547 for ipng-dist; Fri, 4 Dec 1998 15:40:12 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA21540 for ; Fri, 4 Dec 1998 15:39: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 PAA09424 for ; Fri, 4 Dec 1998 15:39:44 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA06779 for ; Fri, 4 Dec 1998 15:39:41 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id PAA04824; Fri, 4 Dec 1998 15:39:30 -0800 (PST) Message-Id: <3.0.5.32.19981204153909.00a29970@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 04 Dec 1998 15:39:09 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6850) Revised IPng W.G. Agenda 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 Folks, Attached is the revised agenda for the IPng w.g. meeting at the Orlando IETF. Both sessions will be Multicast. Please send us any changes and additions. Especially if you are listed to speak! Thanks, Bob Hinden / Steve Deering -------------------------------------------- THURSDAY, December 10 at 1530-1730 (Paradise III) [120] Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) IPv6 6REN Status and Plans / R. Fink (20 min) Addressing to Draft Standard / R. Hinden (5 min) Initial IANA Sub-TLA Assignments / R. Hinden (10 min) IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) Mobile IPv6 Status / D. Johnson (10 min) IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter (5 min) Basic API Revision / J. Bound (5 min) DNS Extension to Support IP Version 6 / M. Crawford (5 min) Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (5 min) Jumbograms / S. Deering (5 min) Router Renumbering / M. Crawford (5 min) Multicast Listener Discovery Protocol / S. Deering (5 min) Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 / L. Zhang, et. al. (5 min) FRIDAY, December 11 at 0900-1130 (Paradise III) Site Prefixes in Neighbor Discovery / E. Nordmark (15 min) IPv6 TCP and anycast address / Jun-ichiro Itoh (10 min) RPC and NFS over IPv6 / L. Wu (15 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 Sat Dec 5 08:28:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA21988 for ipng-dist; Sat, 5 Dec 1998 08:20:42 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA21981 for ; Sat, 5 Dec 1998 08:20: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 IAA00737 for ; Sat, 5 Dec 1998 08:20:26 -0800 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA18969 for ; Sat, 5 Dec 1998 08:20:17 -0800 (PST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id BAA05199; Sun, 6 Dec 1998 01:19:48 +0900 (JST) Received: from splash.isl.rdc.toshiba.co.jp (splash.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id BAA19990; Sun, 6 Dec 1998 01:18:18 +0900 (JST) Received: from localhost (kwa0208.mobile.toshiba.co.jp [133.120.199.40]) by splash.isl.rdc.toshiba.co.jp (8.8.8/8.8.8/4.6) with ESMTP id BAA04133; Sun, 6 Dec 1998 01:19:46 +0900 (JST) To: deering@cisco.com Cc: fenner@parc.xerox.com, haberman@raleigh.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 6851) Re: MLD query with 0 Maximum Response Delay In-Reply-To: Your message of "Fri, 4 Dec 1998 08:42:23 -0800" References: X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981206011625E.jinmei@isl.rdc.toshiba.co.jp> Date: Sun, 06 Dec 1998 01:16:25 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 4 Dec 1998 08:42:23 -0800, >>>>> Steve Deering said: > Now, none of this is relevant to MLD, because there is no need for the > same backwards compatibility with an older version. Therefore, you > are absolutely correct: we need to define how the value zero is to be > interpreted. My inclination is to just say that zero means zero, i.e., > no delay, and therefore, change the "(0, Maximum Response Delay]" > expression to "[0, Maximum Response Delay]". Having the ability to > set the maximum delay to zero seems like a desirable feature for the > case of MLD on point-to-point links, where there is no "implosion hazard". > Comments? It seems reasonable. I agree with you. JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.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 Sat Dec 5 08:49:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA22017 for ipng-dist; Sat, 5 Dec 1998 08:40:31 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA22010 for ; Sat, 5 Dec 1998 08:40: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 IAA01131 for ; Sat, 5 Dec 1998 08:40:14 -0800 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA23233 for ; Sat, 5 Dec 1998 08:40:10 -0800 (PST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id BAA05441; Sun, 6 Dec 1998 01:39:33 +0900 (JST) Received: from splash.isl.rdc.toshiba.co.jp (splash.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id BAA20139; Sun, 6 Dec 1998 01:38:03 +0900 (JST) Received: from localhost (kwa0208.mobile.toshiba.co.jp [133.120.199.40]) by splash.isl.rdc.toshiba.co.jp (8.8.8/8.8.8/4.6) with ESMTP id BAA04318; Sun, 6 Dec 1998 01:39:30 +0900 (JST) To: Francis.Dupont@inria.fr Cc: deering@cisco.com, fenner@parc.xerox.com, haberman@raleigh.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 6852) Re: MLD query with 0 Maximum Response Delay In-Reply-To: Your message of "Fri, 04 Dec 1998 17:31:22 +0100" <199812041631.RAA19579@givry.inria.fr> References: <199812041631.RAA19579@givry.inria.fr> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981206013609J.jinmei@isl.rdc.toshiba.co.jp> Date: Sun, 06 Dec 1998 01:36:09 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 04 Dec 1998 17:31:22 +0100, >>>>> Francis Dupont said: > In your previous mail you wrote: > The description seems to assume that Maximum Response Delay is greater > than 0. > => this question is important because in some (not yet fixed :-) > implementations a zero MDR gives a division by 0 (ie a bug). Actually, I found the problem because our implementation hung up, too :-) > Obvious fix is to round MDR to a small value (1 for instance) > but is it correct ? If 0 is a valid value(which is Steve's opinion), it's an implementation issue. Of course, your solution above will work well. We can also handle 0 MRD `as is', that is, just send an MLD report immediately when receiving a query with 0 MRD. > PS: for UNH (or other) test suite, add zero MDR in nasty packet list... It would be a good idea. JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.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 Sun Dec 6 10:03:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA22529 for ipng-dist; Sun, 6 Dec 1998 09:52:17 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA22522; Sun, 6 Dec 1998 09:52: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 JAA10786; Sun, 6 Dec 1998 09:52:02 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA05997; Sun, 6 Dec 1998 09:52:03 -0800 (PST) Received: from pinnacle (128.3.9.221) by cnrmail.lbl.gov with SMTP (Eudora Internet Mail Server 2.1); Sun, 6 Dec 1998 09:52:03 -0800 Message-Id: <4.1.19981206094349.017872d0@cnrmail.lbl.gov> X-Sender: rlfink@cnrmail.lbl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 06 Dec 1998 09:51:20 -0800 To: Gregory Taylor From: Bob Fink Subject: (IPng 6856) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed Cc: IPng List , ngtrans@sunroof.eng.sun.com In-Reply-To: References: <199812031700.AA02943@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gregory, At 02:32 AM 12/6/98 -0800, Gregory Taylor wrote: > > We need to also worry about IP addresses once Internic gets their >hands on IPv6 and deems it a neccessary and serious issue.. They will >start assigning IPs from no where and people that are currently trying to >impliment IPv6 will be left in the dust. The Internic is NOT in charge of IPv6 addresses (or IPv4 addresses for that matter). A very long, careful and drawn out process of getting the IANA and the major regional Internet address registries (RIPE-NCC, ARIN and APNIC) to agree on thoughtful processes to assign IPv6 TLAs and Sub-TLAs is close to completed. Those of us that have been working on this with them are pleased with the process and results. Yes, it could move a little faster, but it is worth doing correctly, and I believe that is what is being done. Bob Fink co-chair NGtrans WG -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 6 16:35:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA22745 for ipng-dist; Sun, 6 Dec 1998 16:25:16 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA22738 for ; Sun, 6 Dec 1998 16:25: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 QAA27008; Sun, 6 Dec 1998 16:24:56 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA23095; Sun, 6 Dec 1998 16:24:57 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id SAA05156; Sun, 6 Dec 1998 18:24:48 -0600 (CST) Message-Id: <199812070024.SAA05156@gungnir.fnal.gov> X-Mailer: exmh version 2.0.2 2/24/98 To: Erik Nordmark , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6858) Re: Site prefixes? In-reply-to: Your message of Wed, 11 Nov 1998 15:00:45 PST. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Dec 1998 18:24:47 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I found a quiet moment to read site-prefixes carefully and have a few comments. Several are just nits. Sec. 1, para 3 - I'd rather you said "cost of renumbering" than "risk", just for PR's sake. And in the next para, I think the first intra should have been an inter. What about a dual-sited node that does not have any SL addresses in one of the sites, but does in the other, but "the other" site does contain some nodes that do have SL addresses? This should be common for a mobile node in its visited site. Then nodes in that site with SL addresses won't be able to reach that dual-sited node. Sec 3.2, there's a repeated "the binding updates", and 6 non-blank lines further down a missing "is". Later in that section I think replacing "the specification" with "this specification" would be clearer. Sec 4, moving the SitePLength field over to the right might make the update of router renumbering cleaner, should this come about. At the very end of section 5 you might mention an "unless": if for some inscrutable reason the "site" lifetime needs to be different from the regular ND lifetime. Sec 7., "do nothing further" would be more exact than "ignore the prefix", which could be construed by some perverse minds to mean back up and undo regular ND stuff. And in the second bullet point, shouldn't that be "*a* link-local or *a* site-local", rather than *the*? At the end of the processing in sec. 7 it might be handier to copy the timer value from the regular ND setting, to which the DOS timer defense has already been applied, if the current PIO is valid for both purposes. But that's not vital, since the consequences of dropping a site prefix are much less. Sec 8.1, processing step 3. I think you should return the set of SL addresses *and* those Gi's which didn't match any locally-known site prefix. However, that last remark does nothing to correct the defect which noted in my second point. That's a bit of a head-scratcher. 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 Mon Dec 7 06:57:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA23161 for ipng-dist; Mon, 7 Dec 1998 06:48:24 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA23154 for ; Mon, 7 Dec 1998 06:48:15 -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 GAA21959 for ; Mon, 7 Dec 1998 06:48:14 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA19039 for ; Mon, 7 Dec 1998 06:48:13 -0800 (PST) Received: from spruce.iprg.nokia.com (maxdialin4.iprg.nokia.com [205.226.20.234]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id GAA15525; Mon, 7 Dec 1998 06:48:10 -0800 (PST) Message-Id: <3.0.5.32.19981207064744.009132e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Dec 1998 06:47:44 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6859) Implementation Reports for Addressing Specifications 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 The first set of implementation reports for "RFC2373 IP Version 6 Addressing Architecture" and "RFC2374 An Aggregatable Global Unicast Address Format" are available at: ftp://playground.sun.com/pub/ipng/implementation-reports/add-arch-aggregat.txt Collecting implementation reports for these specifications is an important part of moving them to Draft Standard. If you have not sent one in yet, please do. 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 Mon Dec 7 09:00:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA23270 for ipng-dist; Mon, 7 Dec 1998 08:51:13 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA23263; Mon, 7 Dec 1998 08:51: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 IAA09837; Mon, 7 Dec 1998 08:51:01 -0800 Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA21765; Mon, 7 Dec 1998 08:50:54 -0800 (PST) Received: from localhost ([198.67.177.144]) by shuttle.wide.toshiba.co.jp (8.9.1+IPv6/8.9.0) with ESMTP id BAA01037; Tue, 8 Dec 1998 01:53:34 +0900 (JST) To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: (IPng 6860) Re: (ngtrans) Re: KAME 19981130 stable release In-Reply-To: Your message of "Fri, 04 Dec 1998 02:57:26 +0900" <21325.912707846@coconut.itojun.org> References: <21325.912707846@coconut.itojun.org> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981208015041I.jinmei@isl.rdc.toshiba.co.jp> Date: Tue, 08 Dec 1998 01:50:41 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980905(IM100) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 04 Dec 1998 02:57:26 +0900, >>>>> Jun-ichiro itojun Itoh said: >> good job.............esp the pim................ >> is this code in the public domain? > KAME code is redistributed under BSD-like copyright. (attached) Right. But you may have to note that our(i.e. KAME's) PIM daemon was based on an IPv4 PIM dense mode daemon, called pimdd, developed at the University of Oregon. So the KAME PIM6 daemon also follows their copyright notice. JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.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 Dec 7 11:08:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA23556 for ipng-dist; Mon, 7 Dec 1998 10:57:17 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id KAA23549 for ; Mon, 7 Dec 1998 10:57:11 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA18729 for ; Mon, 7 Dec 1998 10:57:16 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA01145 for ipng@sunroof.eng.sun.com; Mon, 7 Dec 1998 10:56:42 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA22366; Sun, 6 Dec 1998 02:24:33 -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 CAA18261; Sun, 6 Dec 1998 02:24:32 -0800 Received: from noc.santacruz.org ([209.133.111.163]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA23091; Sun, 6 Dec 1998 02:24:32 -0800 (PST) Received: from localhost (jest@localhost) by noc.santacruz.org (8.9.1a/8.9.1) with SMTP id CAA00100; Sun, 6 Dec 1998 02:32:14 -0800 (PST) Date: Sun, 6 Dec 1998 02:32:14 -0800 (PST) From: Gregory Taylor To: ngtrans@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 6861) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed In-Reply-To: <199812031700.AA02943@quarry.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 We need to also worry about IP addresses once Internic gets their hands on IPv6 and deems it a neccessary and serious issue.. They will start assigning IPs from no where and people that are currently trying to impliment IPv6 will be left in the dust. On Thu, 3 Dec 1998 bound@zk3.dec.com wrote: > Folks, > > Things are moving in the IETF but not as fast as the market needs IPv6 > to happen. We have serious implementation issues to address for > deployment like which DNS record, which transition mechanism, specs that are > moving to slow, etc. > > I would like to ask folks to meet me in the lobby of the hotel Thurs eve > at 8 p.m. for a gathering of what we can do outside of the IETF to > assist IPv6 deployment to move more rapidly. IETF stuff will be done > for that night. Send me mail privately or grab me at the IETF by Wed > a.m. next week if you can make it. There are a lot of back room things > going on and I for one am not happy with the evolution of deployment and > totally sick of the politics to appease whatever and we need to use the > shotgun approach here for the market who wants IPv6 A.S.A.P. > > I have no clue where we can meet if enough folks are interested but we > will find a place. The lobby is the default and if necessary we will go > to one of the parks near the hotel. The weather should be fine. > > Here is what we need to discuss: > > 1. Vendors - what are the deployment strategies for the next 2 years. > What is realistic? > > 2. Do we have any killer apps we can move quickly and if necessary > share code and create a public domain code base? > > 3. What trade-shows do we need to develop a coordinated demonstration > set for IPv6 on the show floors. What application demos can > we build. > > 4. What trade-rags and analysts do we need to probe through our > marketing contacts. One VOIP pundit I have the mail from told > folks in mail I have that IPv6 is "DEAD" just ask the people > working on it at the IETF. We need to fix this and get the > analysts the right information, and the pundits. > > 5. We need a plan for end users and ISPs for deployment. > > 6. We need to determine how we can get information to the various > goverments worldwide and should form a committee to work just > on that effort. The whole issue of ICANN and all that is not > addressing IPv6 as important as it must and POISED has much > more difficult issues to address rigth now. Lets not wait for > the present process and between us we can develop a paper that > we will position with our relevant governments to explain the > need for Ipv6 and why we may need their support. > > 7. What technology is needed for IPv6 that is happening too slow > in the IETF or is just going to take forever with the design > by committee approach. Especially around transition mechanisms. > Implementors and Architects bring your ideas. > > Do not come to this gathering if your coming to tell us the IETF is > working this or some other body or some czar, etc. Cause it is not > happening fast enough. This is for folks who want to develop a plan of > attack to get this done where it is not getting done. If it is to turn > out to be an IPv6 Consortia or not I just don't know, that is up to the > gathering. > > Worst case we can at least determine what is slowing this up and why it > is not moving faster. > > This is a grass roots effort and we will not appease the politically > correct attitude, that has slowed IPv6 up thus far, this I suggest should > be this grass roots motto if it happens. > > /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 Dec 7 12:41:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA23686 for ipng-dist; Mon, 7 Dec 1998 12:36:43 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id MAA23679 for ; Mon, 7 Dec 1998 12:36:34 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA05333 for ; Mon, 7 Dec 1998 12:36:39 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id MAA01363 for ipng@sunroof.eng.sun.com; Mon, 7 Dec 1998 12:36:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA22658; Sun, 6 Dec 1998 12:04: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 MAA19665; Sun, 6 Dec 1998 12:04:18 -0800 Received: from noc.santacruz.org (santacruz.org [209.133.111.174]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA01510; Sun, 6 Dec 1998 12:04:19 -0800 (PST) Received: from localhost (jest@localhost) by noc.santacruz.org (8.9.1a/8.9.1) with SMTP id MAA02127; Sun, 6 Dec 1998 12:11:57 -0800 (PST) Date: Sun, 6 Dec 1998 12:11:57 -0800 (PST) From: Gregory Taylor To: Bob Fink cc: IPng List , ngtrans@sunroof.eng.sun.com Subject: (IPng 6862) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed In-Reply-To: <4.1.19981206094349.017872d0@cnrmail.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ah, I see, Thanks for the Info... I was quite concerned that a corporate network would get ahold of the IPv6 IP blocks and would screw everything up. Gregory Taylor Network Security Analyst Consultant and Contract Unix Administrator SantaCruz Networks jest@santacruz.org On Sun, 6 Dec 1998, Bob Fink wrote: > Gregory, > > At 02:32 AM 12/6/98 -0800, Gregory Taylor wrote: > > > > We need to also worry about IP addresses once Internic gets their > >hands on IPv6 and deems it a neccessary and serious issue.. They will > >start assigning IPs from no where and people that are currently trying to > >impliment IPv6 will be left in the dust. > > The Internic is NOT in charge of IPv6 addresses (or IPv4 addresses for that > matter). A very long, careful and drawn out process of getting the IANA and > the major regional Internet address registries (RIPE-NCC, ARIN and APNIC) > to agree on thoughtful processes to assign IPv6 TLAs and Sub-TLAs is close > to completed. Those of us that have been working on this with them are > pleased with the process and results. Yes, it could move a little faster, > but it is worth doing correctly, and I believe that is what is being done. > > Bob Fink > co-chair NGtrans WG > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 7 14:14:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA23823 for ipng-dist; Mon, 7 Dec 1998 14:08:18 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA23816 for ; Mon, 7 Dec 1998 14:08:05 -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 OAA05993 for ; Mon, 7 Dec 1998 14:08:03 -0800 Received: from www.fandom.net (fandom.net [203.35.8.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA29670 for ; Mon, 7 Dec 1998 14:08:01 -0800 (PST) Date: Mon, 7 Dec 1998 14:08:01 -0800 (PST) Message-Id: <199812072208.OAA29670@earth.sun.com> Received: from certhas.fandom.net [203.35.8.5] by www.fandom.net with smtp id KQZCJESP; Mon, 07 Dec 98 22:07:50 GMT (PowerWeb version 4.04r6) Subject: (IPng 6863) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed From: Andrew To: jest@santacruz.org Cc: ipng@sunroof.eng.sun.com Reply-To: Andrew In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: BeatWare Mail-It 1.6 X-BeOS-Platform: Intel or clone Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id OAA23817 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your mail of Sun Dec 6 12:11:57 1998 (subject: (IPng 6862) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed) > Ah, I see, > Thanks for the Info... I was quite concerned that a corporate > network would get ahold of the IPv6 IP blocks and would screw oh-no, it'll be as safe as the IPv4 IP blocks, "protected" by non-profit organisations like APNIC which requires a donation of US$3,500.00 to US$11,000.00 before accepting IP block requests. Meanwhile, though getting IP blocks can be like pulling teeth for some legimate network providers, others like Telstra who've gotten their class B's give multiple class Cs to 33K modem users.. Consider for the moment, the current DNS, much of the current domain hi-jacking / blackmail ows its origin to the way InterNIC gives any domain to any person on first in first serve basis. If some thought had been applied we could have had a very nice & clean system instead, an almost nil cost system where business domains where automaticly available/created for businesses within their domain, e.g, coca-cola in Australia would be coca-cola.au.com , a "Russels Kennels" in state of Victoria would be russelskennels.vic.au.com So I would suggest serious thought be given now, to how & who has authority over IPv6 IP ranges. I would suggest that if it is wanted to avoid the IP system from being used as another license to exort money that every person on the planet would have the option of getting a IP range from two or three seperate authorities. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 7 20:40:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA24117 for ipng-dist; Mon, 7 Dec 1998 20:37:11 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA24110 for ; Mon, 7 Dec 1998 20:37:03 -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 UAA10108 for ; Mon, 7 Dec 1998 20:37:01 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA19831 for ; Mon, 7 Dec 1998 20:37:02 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA24156; Mon, 7 Dec 1998 23:36:54 -0500 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id XAA30130; Mon, 7 Dec 1998 23:36:55 -0500 Received: by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA22802; Mon, 7 Dec 1998 23:36:47 -0500 From: haberman@raleigh.ibm.com (Brian K. Haberman) Message-Id: <9812080436.AA22802@clemson.raleigh.ibm.com> Subject: (IPng 6864) Re: MLD query with 0 Maximum Response Delay To: deering@cisco.com (Steve Deering) Date: Mon, 7 Dec 1998 23:36:46 -0500 (EST) Cc: jinmei@isl.rdc.toshiba.co.jp, fenner@parc.xerox.com, haberman@raleigh.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Steve Deering" at Dec 4, 98 08:42:23 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Now, none of this is relevant to MLD, because there is no need for the > same backwards compatibility with an older version. Therefore, you > are absolutely correct: we need to define how the value zero is to be > interpreted. My inclination is to just say that zero means zero, i.e., > no delay, and therefore, change the "(0, Maximum Response Delay]" > expression to "[0, Maximum Response Delay]". Having the ability to > set the maximum delay to zero seems like a desirable feature for the > case of MLD on point-to-point links, where there is no "implosion hazard". > I agree that zero is a valid value. I have actually played with allowing the Maximum Delay be zero expressly for the case of p-2-p links. So, lets update the spec to specify "[0, Maximum Response Delay]". 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 Tue Dec 8 06:41:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA24344 for ipng-dist; Tue, 8 Dec 1998 06:34:40 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA24337 for ; Tue, 8 Dec 1998 06: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 GAA16294 for ; Tue, 8 Dec 1998 06:34:27 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA10306 for ; Tue, 8 Dec 1998 06:34:27 -0800 (PST) Received: from spruce.mtg.ietf.org (ietf-177-167.mtg.ietf.org [198.67.177.167]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id GAA28549 for ; Tue, 8 Dec 1998 06:34:26 -0800 (PST) Message-Id: <3.0.5.32.19981208062243.03a38b60@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 08 Dec 1998 06:22:43 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 6865) RFC 2473 on Generic Packet Tunneling in IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2473: Title: Generic Packet Tunneling in IPv6 Specification Author(s): A. Conta, S. Deering Status: Proposed Standard Date: December 1998 Mailbox: aconta@lucent.com, deering@cisco.com Pages: 36 Characters: 77956 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-ipngwg-ipv6-tunnel-08.txt URL: ftp://ftp.isi.edu/in-notes/rfc2473.txt This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <981207160836.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2473 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 8 07:33:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA24383 for ipng-dist; Tue, 8 Dec 1998 07:30:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA24376 for ; Tue, 8 Dec 1998 07:29: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 HAA16892 for ; Tue, 8 Dec 1998 07:29:56 -0800 Received: from theoryx.cs.uni-bonn.de (theoryx.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA06748 for ; Tue, 8 Dec 1998 07:29:43 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id QAA04221 for ; Tue, 8 Dec 1998 16:29:18 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id QAA05726; Tue, 8 Dec 1998 16:29:17 +0100 (MET) Message-ID: <19981208162916.H4904@cs.uni-bonn.de> Date: Tue, 8 Dec 1998 16:29:16 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: (IPng 6866) Typo on RFC2462 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk People (including me) should really read documents during the last-call period... >From rfc2462 (ipv6 stateless address autoconfiguration): 2. TERMINOLOGY IP - Internet Protocol Version 6. The terms IPv4 and are used only in contexts where necessary to avoid ambiguity. I guess, s/and are/and IPv6 are/ was intended. -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 8 11:21:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA00372 for ipng-dist; Tue, 8 Dec 1998 11:18:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA00347; Tue, 8 Dec 1998 11:16: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 LAA03418; Tue, 8 Dec 1998 11:16:15 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA19276; Tue, 8 Dec 1998 11:16:15 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id OAA12641; Tue, 8 Dec 1998 14:16:13 -0500 (EST) Received: from bywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA07679; Tue, 8 Dec 1998 14:16:12 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id OAA0000016089; Tue, 8 Dec 1998 14:16:11 -0500 (EST) From: Jim Bound Message-Id: <199812081916.OAA0000016089@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 6867) Re: (ngtrans) Getting IPv6 Deployed Gathering Needed In-Reply-To: Your message of "Mon, 07 Dec 1998 14:08:01 PST." <199812072208.OAA29670@earth.sun.com> Date: Tue, 08 Dec 1998 14:16:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IETF meeting for this gathering will be at 8 p.m. Thursday in the Paradise D room. /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 Dec 9 05:59:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA01049 for ipng-dist; Wed, 9 Dec 1998 05:46:34 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA01028; Wed, 9 Dec 1998 05:41:37 -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 FAA28839; Wed, 9 Dec 1998 05:41:35 -0800 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA04925; Wed, 9 Dec 1998 05:41:35 -0800 (PST) Received: from pinnacle (131.243.212.222) by cnrmail.lbl.gov with SMTP (Eudora Internet Mail Server 2.1); Wed, 9 Dec 1998 05:41:13 -0800 Message-Id: <4.1.19981209083831.01a9de10@cnrmail.lbl.gov> X-Sender: rlfink@cnrmail.lbl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 Dec 1998 08:40:44 -0500 To: ngtrans@sunroof.eng.sun.com, IPng List , 6bone@isi.edu From: Bob Fink Subject: (IPng 6868) 6ren discussion in Paradise A at 12:15 PM (40-45 mins at most) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As mentioned in the ngtrans meeting yesterday, I will have a brief 6ren startup discussion at 12:15 PM in Paradise A today, Wed. Current 6boen pTLAs are especially invite to come. 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 Dec 9 19:55:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA01718 for ipng-dist; Wed, 9 Dec 1998 19:52:52 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA01711 for ; Wed, 9 Dec 1998 19:52:35 -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 TAA18884 for ; Wed, 9 Dec 1998 19:52:35 -0800 Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA23402 for ; Wed, 9 Dec 1998 19:52:34 -0800 (PST) Received: from classic (ietf-178-141.mtg.ietf.org [198.67.178.141]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with SMTP id WAA06549; Wed, 9 Dec 1998 22:45:19 -0500 (EST) Message-Id: <3.0.5.32.19981209225046.00aa8100@mail.viagenie.qc.ca> Prefer-Language: fr, en X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Dec 1998 22:50:46 -0500 To: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com From: Marc Blanchet Subject: (IPng 6870) Re: W.G. Last Call on "Initial IPv6 Sub-TLA ID Assignments" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id TAA01712 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a modification to propose about the initial assignments to subtlas by registries. >From draft-ietf-ipngwg-iana-tld-00.txt: ---------------------------------------------------------------------- As specified in [TLA-RULES] assignments of Sub-TLA ID's will be done in blocks. The initial assignment of Sub-TLA ID's to registries will be in blocks of 64 Sub-TLA ID's. These assignments are as follows: Binary Range (Hex) Assignment ---------------- --------------- ------------------- 0 0000 00XX XXXX 0x0000 - 0x003F IANA 0 0000 01XX XXXX 0x0040 - 0x007F APNIC 0 0000 10XX XXXX 0x0080 - 0x00BF ARIN 0 0000 11XX XXXX 0x00C0 - 0x00FF RIPE 0 0001 00XX XXXX 0x0100 - 0x013F (future assignment) 0 0001 01XX XXXX 0x0140 - 0x017F (future assignment) 0 0001 10XX XXXX 0x0180 - 0x01BF (future assignment) 0 0001 11XX XXXX 0x01C0 - 0x01FF (future assignment) 0 0010 00XX XXXX 0x0200 - 0x023F (future assignment) . . . . . . . . . 1 1111 11XX XXXX 0x1FC0 - 0x1FFF (future assignment) ------------------------------------------------------------------------ Since the first 3 bits are 001 and then 13 next bits (TLA ID for subtlas) are 0x0001, then the leftmost 16 bits of the 128 bits are now fixed. We then try with the draft to assign the 13 next bits. Then, in order to be more flexible, I think we should begin using leftmost bits for the 13 bits of the Sub-TLAs for the registries and ask them to grow from the either the center or the rightmost bits. So we would be able to change the boundaries if in the future, the number of bits chosen in 1998 were not the best we will find in N years. Changing the boundaries mean that a larger number of either subtlas or NLA can be used without any harm. So the allocation would be: Binary Range (Hex) Assignment ------------------- --------------- ------------------- 1000 000X XXXX XNNN 0x8000 - 0x81FF IANA 0100 000X XXXX XNNN 0x4000 - 0x41FF APNIC 1100 000X XXXX XNNN 0xC000 - 0xC1FF ARIN 0010 000X XXXX XNNN 0x2000 - 0x21FF RIPE 1010 000X XXXX XNNN 0xA000 - 0xA1FF (future assignment) 0110 000X XXXX XNNN 0x6000 - 0x61FF (future assignment) 1110 000X XXXX XNNN 0xB000 - 0xB1FF (future assignment) 0001 000X XXXX XNNN 0x1000 - 0x11FF (future assignment) 1001 000X XXXX XNNN 0x9000 - 0x91FF (future assignment) . . . . . . . . . 1111 111X XXXX XNNN 0xFB00 - 0xFFFF (future assignment) (formatting note: I took the 16 bits boundaries for converting to hex so it looks exactly as the second group of 16 bits in the complete addresses. N are the NLA part. ) An interesting advantage is that the next blocks for a specific registry will be contiguous to the first ones. For example, the next block for APNIC will be 0x4200 - 0x43FF. The consequence is that it postponed the decision on the possible number of registries and the maximum number of subtlas. Which is great, since we don't really know what those numbers will be. This proposal doesn't harm anything but allows more flexibility in the future. Flexibility, especially if we don't know what will happen in the future, is very useful. Regards, Marc. PS. some of the ideas about bits allocation are described in draft-ietf-ipngwg-ipaddressassign-00.txt At 10:25 98-12-01 -0800, you wrote: >This is an IPng working group last call for comments on advancing the >following document as an Informational RFC: > > Title : Initial IPv6 Sub-TLA ID Assignments > Author(s) : B. Hinden, S. Deering, R. Fink, T. Hain > Filename : draft-ietf-ipngwg-iana-tla-00.txt > Pages : 5 > Date : 17-Nov-98 > >This document proposes initial assignments of IPv6 Sub-TLA Aggregation >Identifiers (Sub-TLA ID) to the Address Registries and continued management >of the IP6.INT domain. It is intended as input to the IANA from the IETF >IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working >groups as an aid in starting the process of allocating IPv6 addresses. It >is not intended for any official IETF status. > >The goal is to have the IPng w.g. advance this document so it can be >approved and sent to the IANA to help expedite the process of starting the >allocation of IPng addresses. > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the author. This last call period will end at the >Thursday IETF IPng session on December 10, 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 >-------------------------------------------------------------------- > > ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 10 11:49:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA02116 for ipng-dist; Thu, 10 Dec 1998 11:44:50 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA02109 for ; Thu, 10 Dec 1998 11:44:37 -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 LAA01638 for ; Thu, 10 Dec 1998 11:44:35 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA22090 for ; Thu, 10 Dec 1998 11:44:35 -0800 (PST) Received: from spruce.mtg.ietf.org (ietf-177-179.mtg.ietf.org [198.67.177.179]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA07619; Thu, 10 Dec 1998 11:44:13 -0800 (PST) Message-Id: <3.0.5.32.19981210114341.00abc840@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 10 Dec 1998 11:43:41 -0800 To: Marc Blanchet From: Bob Hinden Subject: (IPng 6871) Re: W.G. Last Call on "Initial IPv6 Sub-TLA ID Assignments" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.5.32.19981209225046.00aa8100@mail.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marc, When the draft was written, I considered doing it in the manner you proposed (e.g., allocate left to right). It came down to keeping flexibility to possibly grow toward the TLA v.s. growing toward the NLA field. I didn't see a particular win in either approach so chose what I considered to be simpler to allocate. Also, the routing plan for these prefixes is to not aggregate by registries, so there is no requirement to have contiguous blocks for each registry. 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 Thu Dec 10 14:51:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA02210 for ipng-dist; Thu, 10 Dec 1998 14:42:35 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA02203 for ; Thu, 10 Dec 1998 14:42: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 OAA10781 for ; Thu, 10 Dec 1998 14:42:23 -0800 Received: from www.fandom.net (fandom.net [203.35.8.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA12638 for ; Thu, 10 Dec 1998 14:42:21 -0800 (PST) Date: Thu, 10 Dec 1998 14:42:21 -0800 (PST) Message-Id: <199812102242.OAA12638@earth.sun.com> Received: from certhas.fandom.net [203.35.8.5] by www.fandom.net with smtp id KTCMFGTL; Thu, 10 Dec 98 22:42:13 GMT (PowerWeb version 4.04r6) Subject: (IPng 6872) Wassenaar From: Andrew To: ipng@sunroof.eng.sun.com Reply-To: Andrew X-Priority: 3 (Normal) X-Mailer: BeatWare Mail-It 1.6 X-BeOS-Platform: Intel or clone Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id OAA02204 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What's the status of the US government and IPv6. Does the US regard data security of IPv6 as another military treat that must be ban from export by all signatories to the Wassenaar agreement? For introduction to Wassenaar see: http://biz.yahoo.com/rf/981203/3l.html http://www.glasswings.com.au/wassenaar.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 10 19:29:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA02442 for ipng-dist; Thu, 10 Dec 1998 19:25:06 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id TAA02435 for ; Thu, 10 Dec 1998 19:24:55 -0800 (PST) Received: from localhost (hobo157 [129.146.31.157]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id TAA23648; Thu, 10 Dec 1998 19:24:58 -0800 (PST) Date: Thu, 10 Dec 1998 13:02:07 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6873) Re: Site prefixes? To: Matt Crawford Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199812070024.SAA05156@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the careful reading - I've applied all the editorial comments. > Sec. 1, para 3 - I'd rather you said "cost of renumbering" than "risk", > just for PR's sake. I could do that but I was trying to somewhat distiguish between the effort of renumbering (updating DNS, reconfiguring routers etc) with the risk associated with things that you can't track down in advance (such as applications having cached IP addresses in memory or in files). Do you think that distinction makes sense? > What about a dual-sited node that does not have any SL addresses in > one of the sites, but does in the other, but "the other" site does > contain some nodes that do have SL addresses? This should be common > for a mobile node in its visited site. Then nodes in that site with > SL addresses won't be able to reach that dual-sited node. That it only true of the nodes in "the other" site do not have any global addresses. And if they don't have global addresses they can't communicate with the mobile when it is at home. So I guess I don't see the problem. > Sec 3.2, there's a repeated "the binding updates", and 6 non-blank lines > further down a missing "is". Later in that section I think replacing > "the specification" with "this specification" would be clearer. I don't find the missing "is" - there is some complex sentence that I can rephrase. > Sec 4, moving the SitePLength field over to the right might make > the update of router renumbering cleaner, should this come about. I'll do that. > At the end of the processing in sec. 7 it might be handier to > copy the timer value from the regular ND setting, to which the DOS > timer defense has already been applied, if the current PIO is > valid for both purposes. But that's not vital, since the consequences > of dropping a site prefix are much less. I don't think addrconf says anything other than the 2 hour rules for the valid lifetime for addrconf purposes. For instance, I've interpreted it to NOT apply to the "onlink" property of the same prefix. If we want to mandate that the 2 hour rules apply to site-prefixes then I think we must also mandate the rule for the on-link part (i.e. revise the ND spec.) I don't see a bug in leaving this with minimal specification. > Sec 8.1, processing step 3. I think you should return the set of > SL addresses *and* those Gi's which didn't match any locally-known > site prefix. Yes, that would make sense. That way if the peer is multihomed with some interfaces in "your" site and some outside it ensures that the application can try reaching all of its interfaces while using site-local addresses to use the interfaces local to the site. 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 Fri Dec 11 02:38:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA02739 for ipng-dist; Fri, 11 Dec 1998 02:34:33 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA02732 for ; Fri, 11 Dec 1998 02:34: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 CAA03138 for ; Fri, 11 Dec 1998 02:34:22 -0800 Received: from theoryx.cs.uni-bonn.de (theoryx.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA25174 for ; Fri, 11 Dec 1998 02:34:22 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA13283; Fri, 11 Dec 1998 11:31:08 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id LAA18206; Fri, 11 Dec 1998 11:31:08 +0100 (MET) Message-ID: <19981211113107.D18125@cs.uni-bonn.de> Date: Fri, 11 Dec 1998 11:31:07 +0100 From: Ignatios Souvatzis To: Andrew , ipng@sunroof.eng.sun.com Subject: (IPng 6875) Re: Wassenaar References: <199812102242.OAA12638@earth.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <199812102242.OAA12638@earth.sun.com>; from Andrew on Thu, Dec 10, 1998 at 02:42:21PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Dec 10, 1998 at 02:42:21PM -0800, Andrew wrote: > What's the status of the US government and IPv6. > Does the US regard data security of IPv6 as another military > treat that must be ban from export by all signatories to the > Wassenaar agreement? 56bit DES keys won't be limited in the future [now that we're convinced that the NSA can crack them at a one per minute rate (thats from extrapolating the EFF cracking engine to 1 billion dollars)]. -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 11 03:55:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA02771 for ipng-dist; Fri, 11 Dec 1998 03:48:35 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA02764 for ; Fri, 11 Dec 1998 03:48:25 -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 DAA05775 for ; Fri, 11 Dec 1998 03:48:21 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA14164 for ; Fri, 11 Dec 1998 03:48:20 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA162796; Fri, 11 Dec 1998 11:48:16 GMT Received: from hursley.ibm.com (lig32-226-15-217.us.lig-dial.ibm.com [32.226.15.217]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA18838; Fri, 11 Dec 1998 11:48:12 GMT Message-ID: <3671064B.33791C0@hursley.ibm.com> Date: Fri, 11 Dec 1998 11:47:23 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Ignatios Souvatzis CC: Andrew , ipng@sunroof.eng.sun.com Subject: (IPng 6876) Re: Wassenaar References: <199812102242.OAA12638@earth.sun.com> <19981211113107.D18125@cs.uni-bonn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, the IAB and IESG are working on a public statement re Wassenaar. It will not be complimentary :) Brian Carpenter Ignatios Souvatzis wrote: > > On Thu, Dec 10, 1998 at 02:42:21PM -0800, Andrew wrote: > > What's the status of the US government and IPv6. > > Does the US regard data security of IPv6 as another military > > treat that must be ban from export by all signatories to the > > Wassenaar agreement? > > 56bit DES keys won't be limited in the future [now that we're convinced that > the NSA can crack them at a one per minute rate (thats from extrapolating the > EFF cracking engine to 1 billion dollars)]. > > -is > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Fri Dec 11 04:57:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA02807 for ipng-dist; Fri, 11 Dec 1998 04:51:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA02800 for ; Fri, 11 Dec 1998 04:51: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 EAA01785; Fri, 11 Dec 1998 04:51:26 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA02339; Fri, 11 Dec 1998 04:51:27 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA30554; Fri, 11 Dec 1998 07:51:23 -0500 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 HAA19766; Fri, 11 Dec 1998 07:51:25 -0500 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16574; Fri, 11 Dec 1998 07:51:23 -0500 Message-Id: <3671154B.C4AA248A@raleigh.ibm.com> Date: Fri, 11 Dec 1998 07:51:23 -0500 From: Brian Haberman Organization: Remote Access Products X-Mailer: Mozilla 4.07 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Erik Nordmark Cc: Matt Crawford , ipng@sunroof.eng.sun.com Subject: (IPng 6877) Re: Site prefixes? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > Sec. 1, para 3 - I'd rather you said "cost of renumbering" than "risk", > > just for PR's sake. > > Do you think that distinction makes sense? > The previous sentence makes the point about stored IP addresses potentially causing problems, so I don't see a reason not to make the change Matt suggested. > > What about a dual-sited node that does not have any SL addresses in > > one of the sites, but does in the other, but "the other" site does > > contain some nodes that do have SL addresses? This should be common > > for a mobile node in its visited site. Then nodes in that site with > > SL addresses won't be able to reach that dual-sited node. > > That it only true of the nodes in "the other" site do not have any > global addresses. And if they don't have global addresses they can't > communicate with the mobile when it is at home. So I guess I don't see the > problem. > I don't see a problem either. This type of scenario has been pointed out in the scoped-address routing draft as well. I believe the solution is in the routing draft. Here are a few other comments, questions. A question about the assumption made in Sec. 3.3, paragraph 2. What if some subnet within a site does not have any global addresses? The simple solution is that the subnet ID field is set to a value not in use as a Site-Local Aggregator. Should this be mentioned? In Sec. 4, the Site PLength is allowed to have a value between 0 and 128, inclusive. Is 0 a valid site prefix length? Brian Haberman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 14 11:57:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA05223 for ipng-dist; Mon, 14 Dec 1998 11:51:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id LAA05216 for ; Mon, 14 Dec 1998 11:51:45 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id LAA00010; Mon, 14 Dec 1998 11:51:50 -0800 (PST) Date: Mon, 14 Dec 1998 11:51:42 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6882) Re: Site prefixes? To: Brian Haberman Cc: Erik Nordmark , Matt Crawford , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3671154B.C4AA248A@raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here are a few other comments, questions. A question about the > assumption > made in Sec. 3.3, paragraph 2. What if some subnet within a site does > not > have any global addresses? The simple solution is that the subnet ID > field > is set to a value not in use as a Site-Local Aggregator. Should this be > mentioned? I'll expand on this. In fact, all you need is only configure (on the nodes and in DNS) the site-local addresses for those subnets. > In Sec. 4, the Site PLength is allowed to have a value between 0 and > 128, > inclusive. Is 0 a valid site prefix length? I see no reason to have a lower limit on the length of site prefixes since ND doesn't have a lower limit on the length of subnet prefixes. (What number other than zero would make sense since we don't know what future addressing plans might look like?) 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 Dec 15 10:03:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA06119 for ipng-dist; Tue, 15 Dec 1998 09:54:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA06112 for ; Tue, 15 Dec 1998 09:54:21 -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 JAA24969 for ; Tue, 15 Dec 1998 09:54:17 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA22690 for ; Tue, 15 Dec 1998 09:54:16 -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 SAA21677 for ; Tue, 15 Dec 1998 18:54:14 +0100 (MET) Received: (from durand@localhost) by brahma.imag.fr (8.8.7/8.8.5) id SAA04217 for ipng@sunroof.eng.sun.com; Tue, 15 Dec 1998 18:54:13 +0100 (MET) Date: Tue, 15 Dec 1998 18:54:13 +0100 (MET) Message-Id: <199812151754.SAA04217@brahma.imag.fr> To: ipng@sunroof.eng.sun.com Subject: (IPng 6883) interim meeting in Grenoble Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've checked with my University and we can host the IPng interim meeting next february in Grenoble, in the french Alps. So, I would like to make a case for this. We have a room that can accomodate a little less than 100 people. There are plenty of hotels in Grenoble that are available for a very reasonable price (under 50$) Public transportation and taxies are available from dowtown Grenoble to the university Campus. (15 minutes ride) Many very nice fine french restaurant are, of course, available. Grenoble is well deserved by airports (one near Grenoble, one near Lyon, one near Geneva) and fast train (3 hours from Paris) We also can arange some catering services for lunches on site, although there might be some fees for that. Grenoble hosted the Winter Olympic Games in 1968, so we can host an IETF interim meeting! - 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 Tue Dec 15 10:03:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA06128 for ipng-dist; Tue, 15 Dec 1998 09:55:16 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA06121 for ; Tue, 15 Dec 1998 09:55: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 JAA04027 for ; Tue, 15 Dec 1998 09:55:00 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA23111 for ; Tue, 15 Dec 1998 09:54:59 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA16903 for ; Tue, 15 Dec 1998 09:54:59 -0800 (PST) Message-Id: <3.0.5.32.19981215095149.00a3a100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Dec 1998 09:51:49 -0800 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: (IPng 6884) Last Call: Mobility Support in IPv6 to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider Mobility Support in IPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 7, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-07.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 15 10:40:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA06244 for ipng-dist; Tue, 15 Dec 1998 10:27:07 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA06237 for ; Tue, 15 Dec 1998 10:26:53 -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 KAA25797 for ; Tue, 15 Dec 1998 10:26:51 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA13723 for ; Tue, 15 Dec 1998 10:26:51 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id MAA13625; Tue, 15 Dec 1998 12:26:45 -0600 (CST) Message-Id: <199812151826.MAA13625@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com Cc: Jeffrey Burgan , Thomas Narten , namedroppers@internic.net From: "Matt Crawford" Subject: (IPng 6885) draft-ietf-ipngwg-dns-lookups-03.txt Date: Tue, 15 Dec 1998 12:26:45 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I found & fixed a pervasive typo in the previous DNS Extensions for IPv6 draft. (The examples were out of sync with the text. Nobody else seems to have spotted it.) I also clarified the name compression situation. I submitted a revised version today. (The IPng chairs passed this to the ADs on Oct 15, although I don't see it on the IESG status page at http://www.ietf.org/IESG/status.html) 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 Wed Dec 16 00:24:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA07262 for ipng-dist; Wed, 16 Dec 1998 00:19:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA07240; Wed, 16 Dec 1998 00:17: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 AAA03896; Wed, 16 Dec 1998 00:16:59 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.192.13]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA06709; Wed, 16 Dec 1998 00:17:01 -0800 (PST) Received: from [171.69.116.90] (deering-home-mac.cisco.com [171.69.116.90]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id AAA29121; Wed, 16 Dec 1998 00:16:57 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199812151754.SAA04217@brahma.imag.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Dec 1998 00:17:27 -0800 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@ISI.EDU From: Steve Deering Subject: (IPng 6891) interim meeting planning Cc: hinden@iprg.nokia.com, rlfink@lbl.gov, tonyhain@microsoft.com, deering@cisco.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As mentioned in the ipngwg and ngtrans meetings in Orlando last week, the chairs of the two working groups propose to hold a two-day joint interim meeting in the first week of February to discuss the next steps in IPv6 standardization, implementation, transition, and deployment. We propose also to allocate a third day for non-working-group business, such as coordination of the 6bone, 6ren, and other IPv6-related initiatives. A more concrete agenda is in preparation, but of immediate concern is deciding where to meet. We have narrowed it down to two choices: (1) the San Francisco Bay Area (2) Grenoble, France The meeting dates will be February 2-4. We would like to hear as soon as possible (like, within the next 24 hours) from those of you who would like to attend the meeting but will be able to attend in only one of those two places. Specifically: - If you can attend in either place, do not reply. - If you cannot attend in either place, do not reply, - If you can attend in only one of those two places, please reply as soon as possible to Bob, Bob, Tony, and me (our addresses are in the Cc: line, above; please do NOT reply to the three mailing lists in the To: line!), and tell us in which place you can attend. Thanks, 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 Dec 16 01:22:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA07310 for ipng-dist; Wed, 16 Dec 1998 01:18:19 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA07303 for ; Wed, 16 Dec 1998 01:18:11 -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 BAA09358 for ; Wed, 16 Dec 1998 01:18:11 -0800 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by earth.sun.com (8.9.1/8.9.1) with SMTP id BAA03229 for ; Wed, 16 Dec 1998 01:18:09 -0800 (PST) Received: (qmail 7906 invoked by uid 502); 16 Dec 1998 09:18:05 -0000 Message-ID: <19981216091805.7905.qmail@mail.ocs.com.au> Received: (qmail 7898 invoked from network); 16 Dec 1998 09:18:03 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Dec 1998 09:18:03 -0000 From: Keith Owens To: ipng@sunroof.eng.sun.com Subject: (IPng 6892) Name space for ICMPV6 symbols, RFC 2463 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Dec 1998 20:17:54 +1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looking at RFC 2463, there are no symbols defined for the various ICMPV6 codes, nor can I find any suggested name space for ICMPV6. Craig Metz has used names like ICMPV6_ECHO_REPLY, the glibc people have used ICMP6_ECHO_REPLY (no V), which is correct? Given that the glibc include files are called icmp6.h and not icmpv6.h, I tend towards ICMP6_ as a prefix but it is not my decision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 16 01:43:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA07369 for ipng-dist; Wed, 16 Dec 1998 01:38:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA07362 for ; Wed, 16 Dec 1998 01:38: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 BAA10118 for ; Wed, 16 Dec 1998 01:38:45 -0800 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA10944 for ; Wed, 16 Dec 1998 01:38:44 -0800 (PST) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id SAA22890; Wed, 16 Dec 1998 18:38:37 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.8.8/8.8.8) id SAA21820; Wed, 16 Dec 1998 18:38:32 +0900 (JST) Date: Wed, 16 Dec 1998 18:38:32 +0900 (JST) From: Atsushi Onoe Message-Id: <199812160938.SAA21820@duplo.sm.sony.co.jp> To: kaos@ocs.com.au Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6893) Re: Name space for ICMPV6 symbols, RFC 2463 In-Reply-To: Your message of "Wed, 16 Dec 1998 20:17:54 +1200" <19981216091805.7905.qmail@mail.ocs.com.au> References: <19981216091805.7905.qmail@mail.ocs.com.au> X-Mailer: Cue version 0.3 (981216-1826/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Looking at RFC 2463, there are no symbols defined for the various > ICMPV6 codes, nor can I find any suggested name space for ICMPV6. You can find it in RFC 2292 (Advanced Sockets API for IPv6). Atsushi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 17 19:49:00 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta2+Sun/8.9.2.Beta2) id TAA09601 for ipng-dist; Thu, 17 Dec 1998 19:43:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta2+Sun/8.9.2.Beta2) with SMTP id TAA09584; Thu, 17 Dec 1998 19:39:33 -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 TAA17333; Thu, 17 Dec 1998 19:39:33 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA12880; Thu, 17 Dec 1998 19:39:33 -0800 (PST) Received: from spruce.iprg.nokia.com (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id TAA06226; Thu, 17 Dec 1998 19:39:32 -0800 (PST) Message-Id: <3.0.5.32.19981217193903.00ada100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 17 Dec 1998 19:39:03 -0800 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@ISI.EDU From: Bob Hinden Subject: (IPng 6894) Interim Meeting Location Cc: hinden@iprg.nokia.com, rlfink@lbl.gov, tonyhain@microsoft.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The interim IPng and NGTRANS meeting will be held in Grenoble, France on February 2-4, 1999. It will be hosted by Alain Durand. He will be sending travel and accommodations information to the mailing lists in the next few days. The chairs wish to thank all of the groups who volunteered to host the meeting. It was very appreciated and made for a difficult decision. 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 Fri Dec 18 07:05:52 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta2+Sun/8.9.2.Beta2) id GAA09880 for ipng-dist; Fri, 18 Dec 1998 06:57:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta2+Sun/8.9.2.Beta2) with SMTP id GAA09842; Fri, 18 Dec 1998 06: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 GAA24506; Fri, 18 Dec 1998 06:54:03 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA09361; Fri, 18 Dec 1998 06:53:50 -0800 (PST) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id PAA01231; Fri, 18 Dec 1998 15:53:43 +0100 (MET) Message-Id: <199812181453.PAA01231@imag.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 18 Dec 1998 15:52:44 +0100 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@ISI.EDU From: Alain Durand Subject: (IPng 6895) Interim Meeting, travel direction Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id GAA09843 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm very pleased to host the interim meeting in Grenoble. Here are some travel directions: Airports: - Grenoble Saint Geoir. Very little traffic on it. Mostly 4 flights a day for Paris-Orly (2 in the morning, 2 in the evening) and return from Paris-Orly. Beware: most international flight arrives at PARIS-Charles-de-Gaule (CDG) (Roissy) which is very far away from Orly. A shuttle bus to Grenoble-downtown waits passenger at each flight. You can also rent a car at the airport. Gaz is expensive in france. Taxy is very expensive on long distance. It's about 40 min drive to Grenoble. Just take the Highway to Grenoble. - Lyon-Satolas It's an international airport, many flights arrives there. You can also arrives there in a flight connected from Paris-CDG (Air-France, Delta,...) or Zurich (Swissair). There is a shuttle service direct to Grenoble every hour. You can also rent a car at the airport. It's an hour drive to grenoble. Just take the Highway to Grenoble. Note: if you depart from the same airport you arrived, ask for a round-trip shuttle ticket, it's much cheaper (190F instead of 2 x 130F for Lyon's airport) - Geneva It's about 2 hours drive from Grenoble. It might make some sense if you intend to rent a car. Trains: It's usually the best way to come to Grenoble from Paris. It takes 3h only, as the train (TGV) drives 300kph, a little less than 200mph. The TGV leaves from PARIS-Gare-de-Lyon and is direct, non stop to Grenoble. Some of them are direct from Paris-CDG See http://www.sncf.fr for details (they have an english version) Hotels: Here is a list of hotels downtown Grenoble: · hotel des Alpes - 45 avenue Félix Viallet +33 4 76 87 00 71 12 rooms reserved. 270F with breakfast. Specify IETF. · hotel Bastille - 25 avenue Félix Viallet +33 4 76 43 10 27 20 rooms reserved 247F with breakfast fax: +33 476 87 52 69. Specify IETF · hotel Bristol - 11 avenue Félix Viallet +33 4 76 46 11 18 - room: 175 F to 245 F (Breakfast 25 F) · hotel de l'Institut - 10 rue Barbillon +33 4 76 46 36 44 - room 215 F to 240 F (Breakfast 25 F) · hotel Touring hotel - 26 avenue Alsace Lorraine +33 4 76 46 24 32 - room 190 F to 210 F (Breakfast 25 F) The standard of those hotels is somehow less than the one we usually have for IETF meetings, but they are OK. All those hotels are less than 5 min walk from the train station. Airport shuttle arrives at the bus station wich is located next to the train station. Restaurants: Many!!! The best ones are in the pedestrian streets, 5 to 10 min walk from the hotels. Menus are from 60F to 160F+. Transportation: Downtown Grenoble, just walk. To go to the university Campus, take the Tramway B direction University. it's about 15 min ride. Tram fare is 7F50 per ticket. You might buy 10 tickets for about 50F. You might want to take a taxi, it will be a 10 min ride for about 50F Meeting Room: It will be at IMAG, maison Jean Kuntzmann. It's 1 min walk from the tram terminus. See map http://www.imag.fr/Multimedia/logos/Domaine.gif Some pictures: http://www.imag.fr/Multimedia/jeudis/mjk.html Information about IMAG: http://www.imag.fr Terminal Room: We will install some PCs and ether links for laptops. The format of printers is A4, not letter. Lunches: We will organise a catering service. We will have to charge some fees for that, more information later. Misc: Power is 220V is france, 50 Hz. Plugs are round. You can find adapters easily in the US (Radio Shack), it's more difficult to get in france. Inscription & Hotel reservation: Contact ietf@imag.fr for inscriptions. Due to security reasons, the meeting room is limited to 100 persons. I will do the reservation in the hotels for you if you desire. Send exact arrival and departure dates to ietf@imag.fr. Other: Contact ietf@imag.fr You might find some information on http://www.Yahoo.fr or http://www.nomade.fr or http://www.pageswoom.tm.fr - 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 Fri Dec 18 09:12:19 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta2+Sun/8.9.2.Beta2) id JAA10228 for ipng-dist; Fri, 18 Dec 1998 09:05:26 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta2+Sun/8.9.2.Beta2) with SMTP id JAA10217 for ; Fri, 18 Dec 1998 09:05: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 JAA10928 for ; Fri, 18 Dec 1998 09:05:14 -0800 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA28278 for ; Fri, 18 Dec 1998 09:05:14 -0800 (PST) Received: from hpindtug.cup.hp.com (hpindtug.cup.hp.com [15.13.108.87]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id JAA08442; Fri, 18 Dec 1998 09:05:12 -0800 (PST) Received: (from ctekwani@localhost) by hpindtug.cup.hp.com (8.7.1/8.7.3 TIS Messaging 5.0) id JAA17680; Fri, 18 Dec 1998 09:11:25 -0800 (PST) Date: Fri, 18 Dec 1998 09:11:25 -0800 (PST) From: Chandra Tekwani Message-Id: <199812181711.JAA17680@hpindtug.cup.hp.com> To: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Subject: (IPng 6896) IPv6 Developer's Kit for HP-UX 11.0 available Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-MD5: qa5Jzkn7o/7H7Hye76R+ng== Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hewlett-Packard announces the availability of IPv6 Developer's Kit for HP-UX Hewlett-Packard has released the IPv6 Developer's Kit Version 1.0 for experimentation, evaluation and development of applications. The IPv6 Developer's Kit Version 1.0 is available from "http://www.software.hp.com" under "Internet & Security". IPv6 Developer's Kit Version 1.0 runs on 32-bit, HP-UX 11.00 systems. You can send any questions/queries about IPv6 Developer's Kit for HP-UX to hpux-ipv6@cup.hp.com. Chandra Tekwani HP-UX IPv6 Team -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 07:16:52 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id GAA11559 for ipng-dist; Sun, 20 Dec 1998 06:54:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id GAA11552 for ; Sun, 20 Dec 1998 06:53: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 GAA10836 for ; Sun, 20 Dec 1998 06:53:49 -0800 Received: from mail12.svr.pol.co.uk (mail12.svr.pol.co.uk [195.92.193.215]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA00390 for ; Sun, 20 Dec 1998 06:53:50 -0800 (PST) Received: from modem-106.buproprione.dialup.pol.co.uk ([62.136.55.234] helo=babylon5) by mail12.svr.pol.co.uk with smtp (Exim 2.054 #1) id 0zrkEu-0004bF-00 for ipng@sunroof.eng.sun.com; Sun, 20 Dec 1998 14:53:48 +0000 Message-Id: <4.1.0.67.19981220144441.0093c4c0@pop.pol.net.uk> X-Sender: co-hop.freeserve.co.uk@pop.pol.net.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.67 (Beta) Date: Sun, 20 Dec 1998 14:53:40 +0000 To: ipng@sunroof.eng.sun.com From: Myron Szymanskyj Subject: (IPng 6898) An simple idea thrown into the air. In-Reply-To: <199812201356.FAA11536@sunroof.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Apologies if I appear to be a little out of touch, but I've just found this list and I'm studying the up and coming IPv6 spec. I'll keep this short as maybe the idea has already been though of, but I've not seen something in the draft that _might_ prove useful. Thinking simple.... Would it not be a good idea to put in right from the start a mechanism (be it an extra bit in the IP header) that if it's set to 1, the IP address is treated to be double the size of the current draft? This to be built into all the new server software that is to appear. I know it's far fetched for all the IPv6 addresses to be used up, but it allows for instant address space expansion in the far future at the `flick of a switch` without making the IPv6 IP header any longer at this present time. Anyway, for now I'll shut up, observe and become more knowledgeable on the subject so I'm not muddying the water. Comments and further words wisdom welcome..... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 07:23:22 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id HAA11569 for ipng-dist; Sun, 20 Dec 1998 07:08:28 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id HAA11561 for ; Sun, 20 Dec 1998 07:06: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 HAA29754 for ; Sun, 20 Dec 1998 07:05:25 -0800 Received: from send103.yahoomail.com (send103.yahoomail.com [205.180.60.92]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA02248 for ; Sun, 20 Dec 1998 07:05:12 -0800 (PST) Message-ID: <19981220150534.13933.rocketmail@send103.yahoomail.com> Received: from [209.94.102.48] by send103.yahoomail.com; Sun, 20 Dec 1998 07:05:34 PST Date: Sun, 20 Dec 1998 07:05:34 -0800 (PST) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6899) Reg: Quality of Service routing To: routing quality Cc: Internet Protocol , MultiProtocol Label Switching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All, I have one basic question regarding QoS routing. Do we need QoS routing if we have enough infinite (I mean large ) bandwidth. >From my poor knowledge: We need QoS routing b'cos we have limited BW and we want to give priority to QoS flows. If some one comes with a Tx system which supports 100s Gb/s,(say 128 channel WDM system) Do we need to support the "special" status for the QoS flows. May in that case the memory at the routers will be bottleneck. Am I missing something. With Regards -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Sun Dec 20 11:00:52 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id KAA11794 for ipng-dist; Sun, 20 Dec 1998 10:49:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id KAA11787 for ; Sun, 20 Dec 1998 10:49: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 KAA16975 for ; Sun, 20 Dec 1998 10:49:08 -0800 Received: from send104.yahoomail.com (send104.yahoomail.com [205.180.60.122]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA10923 for ; Sun, 20 Dec 1998 10:49:09 -0800 (PST) Message-ID: <19981220184934.18493.rocketmail@send104.yahoomail.com> Received: from [209.94.102.60] by send104.yahoomail.com; Sun, 20 Dec 1998 10:49:34 PST Date: Sun, 20 Dec 1998 10:49:34 -0800 (PST) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6903) Re: Reg: Quality of Service routing To: Antoni Przygienda Cc: routing quality , Internet Protocol , MultiProtocol Label Switching MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But the end-2-end delay = propagation time + proce. time. Right. The processing time of packet is more in the present networks due to lack of BW at all instants of time. So you need some I/O Q which will increase the total proc. time and hence the end-2-end delay. We want to process the packets based on the QoS requirements b'cos we don't have enough BW. Is there any other reason which increases the proc. time of a packet at a node. So in that case end-2-end delay ~ Propagation time. Which helps us in meeting the end-2-end delay requirement. Waiting for the expert comments... With Regards -Raghu. ---Antoni Przygienda wrote: > > Raghu V.V.J Vadapalli wrote: > > > > Dear All, > > > > I have one basic question regarding QoS routing. > > > > Do we need QoS routing if we have enough infinite (I mean > > large ) bandwidth. > > > > >From my poor knowledge: > > > > We need QoS routing b'cos we have limited BW and we want > > to give priority to QoS flows. If some one comes with > > a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > > Do we need to support the "special" status for the QoS flows. > > May in that case the memory at the routers will be > > bottleneck. > > > > Am I missing something. > > With Regards > > -Raghu. > > > > > > I am not aware that you can generally trade bandwidth for delay > (said simply: if you have end-2-end delay constraints to meet & sum of > your link propagation delays exceeds it, there is little you can do) > so having arbitrary amounts > of bandwidth does not necessarily solve the end-2-end delay problem. > > > > thank you > > --- tony > == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Sun Dec 20 14:44:27 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id OAA11908 for ipng-dist; Sun, 20 Dec 1998 14:35:14 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id OAA11901 for ; Sun, 20 Dec 1998 14:35: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 OAA27403 for ; Sun, 20 Dec 1998 14:35:00 -0800 Received: from ezymail.ezymail.com ([203.61.203.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA21754 for ; Sun, 20 Dec 1998 14:34:52 -0800 (PST) Received: from csl-ws000000 ([203.108.29.41]) by ezymail.ezymail.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 1-666L) with SMTP id AAA261; Mon, 21 Dec 1998 08:38:31 +1000 Reply-To: From: "Mitch Denny" To: "Myron Szymanskyj" Cc: "IPNG List" Subject: (IPng 6906) RE: An simple idea thrown into the air. Date: Mon, 21 Dec 1998 09:34:54 +1000 Message-ID: <004a01be2c71$587cc0d0$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> 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-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <4.1.0.67.19981220144441.0093c4c0@pop.pol.net.uk> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Myron, I am new to it aswell, your suggestion is pretty simple, and very implementable. I think the arguement is when do you stop adding bits :) Currently they are using 128bit addresses which provides a substansial yield. Perhaps what they should look at is a 16bit part (or less) section in the header that can be used to define the size of the address space, and routers can inteligently handle each packet. [normal header crap|address space size|address|-------------] 0000000011111111 would provide a 256 bit address space :) Now that IPv6 is basically agreed upon (am I wrong?) I think we will have to wait for IPvX for that facility, and even then it may be deemed to computationally intensive for routers to handle and still maintain speed. Not to mention other problems that may arrise. Who knows with ng technology :) Actually I think by the time peoples are ready to get more address space there will be need to extend the protocol suite aswell. Cheers, Mitch Denny warbyte@ezymail.com > -----Original Message----- > From: owner-ipng@sunroof.Eng.Sun.COM > [mailto:owner-ipng@sunroof.Eng.Sun.COM]On Behalf Of Myron Szymanskyj > Sent: Monday, December 21, 1998 00:54 > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6898) An simple idea thrown into the air. > > > Apologies if I appear to be a little out of touch, but I've just > found this > list and I'm studying the up and coming IPv6 spec. > > I'll keep this short as maybe the idea has already been though > of, but I've > not seen something in the draft that _might_ prove useful. > Thinking simple.... > > Would it not be a good idea to put in right from the start a mechanism (be > it an extra bit in the IP header) that if it's set to 1, the IP address is > treated to be double the size of the current draft? This to be built into > all the new server software that is to appear. > > I know it's far fetched for all the IPv6 addresses to be used up, but it > allows for instant address space expansion in the far future at the `flick > of a switch` without making the IPv6 IP header any longer at this > present time. > > Anyway, for now I'll shut up, observe and become more knowledgeable on the > subject so I'm not muddying the water. > > Comments and further words wisdom welcome..... > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sun Dec 20 14:45:57 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id OAA11918 for ipng-dist; Sun, 20 Dec 1998 14:41:32 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id OAA11911 for ; Sun, 20 Dec 1998 14:41: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 OAA04880 for ; Sun, 20 Dec 1998 14:41:20 -0800 Received: from ezymail.ezymail.com ([203.61.203.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA22963 for ; Sun, 20 Dec 1998 14:41:18 -0800 (PST) Received: from csl-ws000000 ([203.108.29.41]) by ezymail.ezymail.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 1-666L) with SMTP id AAA323 for ; Mon, 21 Dec 1998 08:44:54 +1000 Reply-To: From: "Mitch Denny" To: "IPNG List" Subject: (IPng 6907) RE: Interim Meeting, travel direction Date: Mon, 21 Dec 1998 09:41:17 +1000 Message-ID: <004c01be2c72$3cc79800$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <199812181453.PAA01231@imag.imag.fr> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 X-MIME-Autoconverted: from 8bit to quoted-printable by earth.sun.com id OAA22963 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id OAA11912 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Watch out for the paparatzi :) Bad joke I know. > -----Original Message----- > From: owner-ipng@sunroof.Eng.Sun.COM > [mailto:owner-ipng@sunroof.Eng.Sun.COM]On Behalf Of Alain Durand > Sent: Saturday, December 19, 1998 00:53 > To: ipng@sunroof.Eng.Sun.COM; ngtrans@sunroof.Eng.Sun.COM; 6bone@ISI.EDU > Subject: (IPng 6895) Interim Meeting, travel direction > > > I'm very pleased to host the interim meeting in Grenoble. > > Here are some travel directions: > > Airports: > - Grenoble Saint Geoir. Very little traffic on it. Mostly > 4 flights a day for Paris-Orly (2 in the morning, 2 in > the evening) > and return from Paris-Orly. > Beware: most international flight arrives at > PARIS-Charles-de-Gaule > (CDG) > (Roissy) which is very far away from Orly. > A shuttle bus to Grenoble-downtown waits passenger at > each flight. > You can also rent a car at the airport. Gaz is > expensive in france. > Taxy is very expensive on long distance. It's about 40 > min drive to > Grenoble. > Just take the Highway to Grenoble. > > - Lyon-Satolas > It's an international airport, many flights arrives > there. You can > also > arrives there in a flight connected from Paris-CDG > (Air-France, > Delta,...) > or Zurich (Swissair). There is a shuttle service direct to > Grenoble > every hour. > You can also rent a car at the airport. It's an hour drive to > grenoble. > Just take the Highway to Grenoble. > > Note: if you depart from the same airport you > arrived, ask for a > round-trip > shuttle ticket, it's much cheaper (190F instead of 2 > x 130F for > Lyon's airport) > > - Geneva > It's about 2 hours drive from Grenoble. It might > make some sense > if you > intend to rent a car. > > Trains: > > It's usually the best way to come to Grenoble from > Paris. It takes > 3h only, > as the train (TGV) drives 300kph, a little less than 200mph. > The TGV leaves from PARIS-Gare-de-Lyon and is direct, > non stop to > Grenoble. > Some of them are direct from Paris-CDG > See http://www.sncf.fr for details (they have an > english version) > > Hotels: > Here is a list of hotels downtown Grenoble: > > · hotel des Alpes - 45 avenue Félix Viallet +33 4 76 87 00 71 > 12 rooms reserved. 270F with breakfast. Specify IETF. > > · hotel Bastille - 25 avenue Félix Viallet +33 4 76 43 10 27 > 20 rooms reserved 247F with breakfast fax: +33 476 87 52 > 69. Specify > IETF > > · hotel Bristol - 11 avenue Félix Viallet +33 4 76 46 11 18 > - room: 175 F to 245 F (Breakfast 25 F) > · hotel de l'Institut - 10 rue Barbillon +33 4 76 46 36 44 > - room 215 F to 240 F (Breakfast 25 F) > · hotel Touring hotel - 26 avenue Alsace Lorraine +33 4 > 76 46 24 32 > - room 190 F to 210 F (Breakfast 25 F) > > The standard of those hotels is somehow less than the one we usually > have > for IETF meetings, but they are OK. > > All those hotels are less than 5 min walk from the train station. > Airport shuttle > arrives at the bus station wich is located next to the > train station. > > Restaurants: > Many!!! The best ones are in the pedestrian streets, 5 to > 10 min walk > from > the hotels. Menus are from 60F to 160F+. > > Transportation: > Downtown Grenoble, just walk. To go to the university > Campus, take the > Tramway B direction University. it's about 15 min ride. > Tram fare is > 7F50 > per ticket. You might buy 10 tickets for about 50F. > You might want to take a taxi, it will be a 10 min ride > for about 50F > > Meeting Room: > It will be at IMAG, maison Jean Kuntzmann. > It's 1 min walk from the tram terminus. > See map http://www.imag.fr/Multimedia/logos/Domaine.gif > Some pictures: http://www.imag.fr/Multimedia/jeudis/mjk.html > Information about IMAG: http://www.imag.fr > > > Terminal Room: > We will install some PCs and ether links for laptops. > The format of printers is A4, not letter. > > Lunches: > We will organise a catering service. We will have to > charge some fees > for that, > more information later. > > Misc: > Power is 220V is france, 50 Hz. Plugs are round. You can > find adapters > easily in the US (Radio Shack), it's more difficult to > get in france. > > Inscription & Hotel reservation: > Contact ietf@imag.fr for inscriptions. Due to security > reasons, the > meeting > room is limited to 100 persons. > I will do the reservation in the hotels for you if you desire. Send > exact arrival > and departure dates to ietf@imag.fr. > > Other: > Contact ietf@imag.fr > > You might find some information on http://www.Yahoo.fr or > http://www.nomade.fr > or http://www.pageswoom.tm.fr > > - 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 15:02:13 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id OAA11972 for ipng-dist; Sun, 20 Dec 1998 14:53:34 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id OAA11957 for ; Sun, 20 Dec 1998 14:53: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 OAA11804 for ; Sun, 20 Dec 1998 14:53:22 -0800 Received: from mail4.svr.pol.co.uk (mail4.svr.pol.co.uk [195.92.193.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA25073 for ; Sun, 20 Dec 1998 14:53:22 -0800 (PST) Received: from modem-114.phosphorus.dialup.pol.co.uk ([62.136.7.114] helo=babylon5) by mail4.svr.pol.co.uk with smtp (Exim 2.054 #1) id 0zrrik-0005sU-00; Sun, 20 Dec 1998 22:53:07 +0000 Message-Id: <4.1.0.67.19981220224423.009843e0@pop.pol.net.uk> X-Sender: co-hop.freeserve.co.uk@pop.pol.net.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.67 (Beta) Date: Sun, 20 Dec 1998 22:52:50 +0000 To: From: Myron Szymanskyj Subject: (IPng 6908) RE: An simple idea thrown into the air. Cc: ipng@sunroof.eng.sun.com In-Reply-To: <004a01be2c71$587cc0d0$ee4f000a@csl-ws000000.resource.bm.me l.au.csl.com> References: <4.1.0.67.19981220144441.0093c4c0@pop.pol.net.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In Reply to `RE: (IPng 6898) An simple idea thrown into the air.` by `warbyte@ezymail.com`. Well Mitch, I don't think it'll be a computational burden on routers. It would be just a simple conditional branch made by approx. 10 CPU instructions. If the the `IP type` bit would be zero then it would be handles ezxactly as defined in te IPv6 specification. If the `IP type` bit would be non-zero then it would be handled by another set of routines that would understand the extended functionality. Basically, built in an even larger address space right from the start, but have it supressed, thus smaller IP packet size at 128 bits. As soon as problems arise where the expanded address space is required then turn on that `IP type` bit`! All the routers, protocol handlers, etc.... would already know how to handle the further extended address space. Just build in the functionality into IPv6 right from conception so there is no rush and headache to `get it right` in a few decated from now. * Myron Szymanskyj. * myron@co-hop.co.uk or myron@spuddy.mew.co.uk * World Wide Web: http://www.users.zetnet.co.uk/maac/myron/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 15:04:44 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id PAA12007 for ipng-dist; Sun, 20 Dec 1998 15:02:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id PAA11994 for ; Sun, 20 Dec 1998 15:02:03 -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 PAA23726 for ; Sun, 20 Dec 1998 15:02:01 -0800 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by earth.sun.com (8.9.1/8.9.1) with SMTP id PAA26586 for ; Sun, 20 Dec 1998 15:02:01 -0800 (PST) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP-external (PP); Sun, 20 Dec 1998 23:01:11 +0000 Date: Sun, 20 Dec 1998 23:01:27 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Mitch Denny cc: IPNG List Subject: (IPng 6909) Re: Interim Meeting, travel direction In-Reply-To: <004c01be2c72$3cc79800$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 21 Dec 1998, Mitch Denny wrote: > Watch out for the paparatzi :) > > Bad joke I know. And that is just further proof that any decision taken that involves tunnelling as an end in itself, rather than as a short-term transition, is a choice that will be regretted. L. contrasting 6Bone with Mobile IP. [Grenoble-and-getting-to-it-from-Paris interim announcement] PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 15:32:54 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id PAA12097 for ipng-dist; Sun, 20 Dec 1998 15:22:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id PAA12088 for ; Sun, 20 Dec 1998 15:22: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 PAA24808 for ; Sun, 20 Dec 1998 15:22:10 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.9.1/8.9.1) with SMTP id PAA00813 for ; Sun, 20 Dec 1998 15:22:10 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Sun Dec 20 18:14:59 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research; Sun Dec 20 18:19:41 EST 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id SAA16779; Sun, 20 Dec 1998 18:19:40 -0500 (EST) Message-Id: <199812202319.SAA16779@postal.research.att.com> To: Myron Szymanskyj cc: ipng@sunroof.eng.sun.com Subject: (IPng 6910) Re: An simple idea thrown into the air. Date: Sun, 20 Dec 1998 18:19:40 -0500 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4.1.0.67.19981220144441.0093c4c0@pop.pol.net.uk>, Myron Szymanskyj writes: > Apologies if I appear to be a little out of touch, but I've just found this > list and I'm studying the up and coming IPv6 spec. > > I'll keep this short as maybe the idea has already been though of, but I've > not seen something in the draft that _might_ prove useful. Thinking simple.. > .. > > Would it not be a good idea to put in right from the start a mechanism (be > it an extra bit in the IP header) that if it's set to 1, the IP address is > treated to be double the size of the current draft? This to be built into > all the new server software that is to appear. We discussed extensible addresses in the IPng directorate. While there was strong support from some quarters, eventually the group decided not to -- and at that, there was a lot of laughter for 128-bit 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 Sun Dec 20 16:05:09 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id PAA12177 for ipng-dist; Sun, 20 Dec 1998 15:52:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id PAA12170 for ; Sun, 20 Dec 1998 15:52:39 -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 PAA25819 for ; Sun, 20 Dec 1998 15:52:36 -0800 Received: from ezymail.ezymail.com ([203.61.203.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA06423 for ; Sun, 20 Dec 1998 15:52:33 -0800 (PST) Received: from csl-ws000000 ([203.108.29.41]) by ezymail.ezymail.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 1-666L) with SMTP id AAA265; Mon, 21 Dec 1998 09:56:05 +1000 Reply-To: From: "Mitch Denny" To: "Steve Bellovin" , "Myron Szymanskyj" Cc: Subject: (IPng 6911) Re: An simple idea thrown into the air. Date: Mon, 21 Dec 1998 10:52:27 +1000 Message-ID: <005b01be2c7c$2e2f2100$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> 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-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <199812202319.SAA16779@postal.research.att.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I want to get my own address range, for personal use. One for each of my shoes, plus one for each shoe lace (smart laces). I am pretty sure that I will need an IP address for each of my hair folicles too :) No matter how much address space we assign ourselves (fixed or variable) we will always approach capacity at a steady rate. Cheers, Mitch Denny warbyte@ezymail.com > -----Original Message----- > From: owner-ipng@sunroof.Eng.Sun.COM > [mailto:owner-ipng@sunroof.Eng.Sun.COM]On Behalf Of Steve Bellovin > Sent: Monday, December 21, 1998 09:20 > To: Myron Szymanskyj > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6910) Re: An simple idea thrown into the air. > > > In message <4.1.0.67.19981220144441.0093c4c0@pop.pol.net.uk>, > Myron Szymanskyj > writes: > > Apologies if I appear to be a little out of touch, but I've > just found this > > list and I'm studying the up and coming IPv6 spec. > > > > I'll keep this short as maybe the idea has already been though > of, but I've > > not seen something in the draft that _might_ prove useful. > Thinking simple.. > > .. > > > > Would it not be a good idea to put in right from the start a > mechanism (be > > it an extra bit in the IP header) that if it's set to 1, the IP > address is > > treated to be double the size of the current draft? This to be > built into > > all the new server software that is to appear. > > We discussed extensible addresses in the IPng directorate. While there > was strong support from some quarters, eventually the group decided not > to -- and at that, there was a lot of laughter for 128-bit 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 16:05:19 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id PAA12187 for ipng-dist; Sun, 20 Dec 1998 15:54:46 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id PAA12180 for ; Sun, 20 Dec 1998 15:54: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 PAA06900 for ; Sun, 20 Dec 1998 15:54:35 -0800 Received: from ezymail.ezymail.com ([203.61.203.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA06959 for ; Sun, 20 Dec 1998 15:54:31 -0800 (PST) Received: from csl-ws000000 ([203.108.29.41]) by ezymail.ezymail.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 1-666L) with SMTP id AAB268; Mon, 21 Dec 1998 09:58:13 +1000 Reply-To: From: "Mitch Denny" To: "Myron Szymanskyj" Cc: "IPNG List" Subject: (IPng 6912) Re: An simple idea thrown into the air. Date: Mon, 21 Dec 1998 10:54:36 +1000 Message-ID: <005d01be2c7c$7afcfe80$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> 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-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <4.1.0.67.19981220224423.009843e0@pop.pol.net.uk> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Myron, I don't think IPv6 will last a few decades, not with the rate of IT growth that we are experiencing, the problem is not neccessarily address space the the need to implement new technologies. My point was that adding an extra bit probably won't achieve much, other then giving twice the address space. The big advancement with IPv6 is all the extra functionality that is added. A the comming decades there will be need for more and more functionality, and no matter how are we try to cater for technology that we haven't yet invented, there will always be something that breaks the bank. Cheers, Mitch Denny warbyte@ezymail.com > -----Original Message----- > From: owner-ipng@sunroof.Eng.Sun.COM > [mailto:owner-ipng@sunroof.Eng.Sun.COM]On Behalf Of Myron Szymanskyj > Sent: Monday, December 21, 1998 08:53 > To: warbyte@ezymail.com > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6908) RE: An simple idea thrown into the air. > > > In Reply to `RE: (IPng 6898) An simple idea thrown into the air.` by > `warbyte@ezymail.com`. > > Well Mitch, I don't think it'll be a computational burden on routers. It > would be just a simple conditional branch made by approx. 10 CPU > instructions. > > If the the `IP type` bit would be zero then it would be handles > ezxactly as > defined in te IPv6 specification. If the `IP type` bit would be non-zero > then it would be handled by another set of routines that would understand > the extended functionality. > > Basically, built in an even larger address space right from the start, but > have it supressed, thus smaller IP packet size at 128 bits. As soon as > problems arise where the expanded address space is required then turn on > that `IP type` bit`! All the routers, protocol handlers, etc.... would > already know how to handle the further extended address space. > > Just build in the functionality into IPv6 right from conception > so there is > no rush and headache to `get it right` in a few decated from now. > > > * Myron Szymanskyj. > * myron@co-hop.co.uk or myron@spuddy.mew.co.uk > * World Wide Web: http://www.users.zetnet.co.uk/maac/myron/ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sun Dec 20 16:58:53 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id QAA12356 for ipng-dist; Sun, 20 Dec 1998 16:46:23 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id QAA12345 for ; Sun, 20 Dec 1998 16:46:11 -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 QAA03822 for ; Sun, 20 Dec 1998 16:46:11 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.9.1/8.9.1) with SMTP id QAA18095 for ; Sun, 20 Dec 1998 16:46:10 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Sun Dec 20 19:38:59 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research; Sun Dec 20 19:43:37 EST 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id TAA17215; Sun, 20 Dec 1998 19:43:36 -0500 (EST) Message-Id: <199812210043.TAA17215@postal.research.att.com> To: warbyte@ezymail.com cc: "Myron Szymanskyj" , ipng@sunroof.eng.sun.com Subject: (IPng 6913) Re: An simple idea thrown into the air. Date: Sun, 20 Dec 1998 19:43:36 -0500 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <005b01be2c7c$2e2f2100$ee4f000a@csl-ws000000.resource.bm.mel.au.csl. com>, "Mitch Denny" writes: > Steve, > > I want to get my own address range, > for personal use. > > One for each of my shoes, plus one > for each shoe lace (smart laces). > > I am pretty sure that I will need > an IP address for each of my hair folicles > too :) > > No matter how much address space we > assign ourselves (fixed or variable) > we will always approach capacity at a > steady rate. I was one of th epeople who wanted extensible addresses. I lost... and I don't think it's time to reopen the question. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 17:45:35 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id RAA12469 for ipng-dist; Sun, 20 Dec 1998 17:40:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id RAA12462 for ; Sun, 20 Dec 1998 17:40: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 RAA28790 for ; Sun, 20 Dec 1998 17:40:38 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id RAA00343 for ; Sun, 20 Dec 1998 17:40:37 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id BA25666; Mon, 21 Dec 1998 12:40:33 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: (IPng 6916) Re: An simple idea thrown into the air. In-Reply-To: Your message of "Mon, 21 Dec 1998 10:52:27 +1000." <005b01be2c7c$2e2f2100$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Dec 1998 12:40:33 +1100 Message-Id: <27215.914204433@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 21 Dec 1998 10:52:27 +1000 From: "Mitch Denny" Message-ID: <005b01be2c7c$2e2f2100$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> | I want to get my own address range, | for personal use. | | One for each of my shoes, plus one | for each shoe lace (smart laces). I think that you have no concept of just how huge the IPv6 address space is. As currently planned, the smallest address space that you (any random individual network) can normally be given is 2^64 addresses - and 2^80 will be more common for most organisations. Do you have any concept at all just how huge that really is? To give you some idea, just calculate 2^64 nano-seconds and wait that long before replying to this message (so you can see just how quickly you can use up your private IPv6 address space assuming you can allocate them at a rate of a thousand million (a billion in the US) a second). Further, as I read the suggestion, it wasn't really to double the address space (which would make addresses 129 bits long) but to double the size of the address field (making addresses 256 bits), which isn't doubling the address space, it is increasing it by an amount that is so huge it is hard to contemplate. As Steve Bellovin said, we had this argument already, a long time ago. It went on for ages - there are lots of issues involved. This one is not one to re-open now. 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 Dec 20 17:45:51 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id RAA12455 for ipng-dist; Sun, 20 Dec 1998 17:33:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id RAA12448 for ; Sun, 20 Dec 1998 17:33: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 RAA28617 for ; Sun, 20 Dec 1998 17:33:43 -0800 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA28990 for ; Sun, 20 Dec 1998 17:33:43 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id MAA06298 for ; Mon, 21 Dec 1998 12:33:40 +1100 (EST) (envelope-from pete@trumpet.com.au) To: "IPNG List" From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6915) Re: An simple idea thrown into the air. Date: Mon, 21 Dec 1998 12:34:23 +1100 Message-ID: <3bvk49e$1fo@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <005d01be2c7c$7afcfe80$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> "Mitch Denny" writes: >Reply-To: >From: "Mitch Denny" >To: "Myron Szymanskyj" >Cc: "IPNG List" >Subject: (IPng 6912) Re: An simple idea thrown into the air. >Date: Mon, 21 Dec 1998 10:54:36 +1000 >Myron, >I don't think IPv6 will last a few decades, >not with the rate of IT growth that we are >experiencing, the problem is not neccessarily >address space the the need to implement >new technologies. >My point was that adding an extra bit probably >won't achieve much, other then giving twice >the address space. The big advancement with >IPv6 is all the extra functionality that is >added. >A the comming decades there will be need for >more and more functionality, and no matter >how are we try to cater for technology >that we haven't yet invented, there will always >be something that breaks the bank. >Cheers, >Mitch Denny >warbyte@ezymail.com My personal belief is that the 128 bit address space will somehow get exhausted, either through hoarding or unforeseen applications that may require a huge virtual internet address space. Just a gut feeling having been in the ISP industry for a while. One possibility would be some kind of artificial intelligence application/protocol that was somehow recursive and could not be sustained with a fixed address length. Perhaps rather than being in the header, have a special escape prefix reserved for address extension. Those stacks that don't want to support it can simply reject/ignore addresses of that type and continue with currently specified address functionality. Future stacks could switch the address extension on at a future date. We don't need to define the details of the address extension, but rather provide the opening for it in the future. It's not too late to do this in my opinion. We will kick ourselves if the opportunity was there and we didn't take it. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 19:13:37 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id TAA12591 for ipng-dist; Sun, 20 Dec 1998 19:03:19 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id TAA12584 for ; Sun, 20 Dec 1998 19:03: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 TAA20332 for ; Sun, 20 Dec 1998 19:03:08 -0800 Received: from send105.yahoomail.com (send105.yahoomail.com [205.180.60.128]) by earth.sun.com (8.9.1/8.9.1) with SMTP id TAA19475 for ; Sun, 20 Dec 1998 19:03:09 -0800 (PST) Message-ID: <19981221030330.29441.rocketmail@send105.yahoomail.com> Received: from [209.94.102.141] by send105.yahoomail.com; Sun, 20 Dec 1998 19:03:30 PST Date: Sun, 20 Dec 1998 19:03:30 -0800 (PST) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6918) Re: An simple idea thrown into the air. To: warbyte@ezymail.com, Myron Szymanskyj Cc: IPNG List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, If IPV6 ran out of it's address space at some later time we can add some speial option routing header which contains an address B. so then the effective address can be A:B where is A is the IPv6 address in the main routing header. It means with IPv6 address A we can represent a WHOLE network. As for the routing at the other routers is considered it will be the same. Does it make any sense. With Regards -Raghu. ---Mitch Denny wrote: > > Myron, > > I don't think IPv6 will last a few decades, > not with the rate of IT growth that we are > experiencing, the problem is not neccessarily > address space the the need to implement > new technologies. > > My point was that adding an extra bit probably > won't achieve much, other then giving twice > the address space. The big advancement with > IPv6 is all the extra functionality that is > added. > > A the comming decades there will be need for > more and more functionality, and no matter > how are we try to cater for technology > that we haven't yet invented, there will always > be something that breaks the bank. > > Cheers, > > Mitch Denny > warbyte@ezymail.com > > > -----Original Message----- > > From: owner-ipng@sunroof.Eng.Sun.COM > > [mailto:owner-ipng@sunroof.Eng.Sun.COM]On Behalf Of Myron Szymanskyj > > Sent: Monday, December 21, 1998 08:53 > > To: warbyte@ezymail.com > > Cc: ipng@sunroof.Eng.Sun.COM > > Subject: (IPng 6908) RE: An simple idea thrown into the air. > > > > > > In Reply to `RE: (IPng 6898) An simple idea thrown into the air.` by > > `warbyte@ezymail.com`. > > > > Well Mitch, I don't think it'll be a computational burden on routers. It > > would be just a simple conditional branch made by approx. 10 CPU > > instructions. > > > > If the the `IP type` bit would be zero then it would be handles > > ezxactly as > > defined in te IPv6 specification. If the `IP type` bit would be non-zero > > then it would be handled by another set of routines that would understand > > the extended functionality. > > > > Basically, built in an even larger address space right from the start, but > > have it supressed, thus smaller IP packet size at 128 bits. As soon as > > problems arise where the expanded address space is required then turn on > > that `IP type` bit`! All the routers, protocol handlers, etc.... would > > already know how to handle the further extended address space. > > > > Just build in the functionality into IPv6 right from conception > > so there is > > no rush and headache to `get it right` in a few decated from now. > > > > > > * Myron Szymanskyj. > > * myron@co-hop.co.uk or myron@spuddy.mew.co.uk > > * World Wide Web: http://www.users.zetnet.co.uk/maac/myron/ > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- > == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Sun Dec 20 19:24:23 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id TAA12613 for ipng-dist; Sun, 20 Dec 1998 19:17:29 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id TAA12606 for ; Sun, 20 Dec 1998 19:17: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 TAA20833 for ; Sun, 20 Dec 1998 19:17:19 -0800 Received: from send102.yahoomail.com (send102.yahoomail.com [205.180.60.90]) by earth.sun.com (8.9.1/8.9.1) with SMTP id TAA22289 for ; Sun, 20 Dec 1998 19:17:20 -0800 (PST) Message-ID: <19981221031739.29493.rocketmail@send102.yahoomail.com> Received: from [209.94.102.141] by send102.yahoomail.com; Sun, 20 Dec 1998 19:17:39 PST Date: Sun, 20 Dec 1998 19:17:39 -0800 (PST) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6919) Re: An simple idea thrown into the air. To: Robert Elz , 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 kre, > Further, as I read the suggestion, it wasn't really to double the address > space (which would make addresses 129 bits long) but to double the size of > the address field (making addresses 256 bits), which isn't doubling the > address space, it is increasing it by an amount that is so huge it is hard > to contemplate. > I think u misunderstood that. Let the extra bit be A. Where A can take 1 or 0. 1: IPv6 address and 0: IPv6 address space. Which actully doubles the address space. I think 2^128 is not a big number for the internet. If all the devices (for example car, oven, ur lights...) then you will run out of IPv6 address space. With Regards -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Sun Dec 20 19:41:05 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id TAA12675 for ipng-dist; Sun, 20 Dec 1998 19:33:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id TAA12668 for ; Sun, 20 Dec 1998 19:33:22 -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 TAA02341 for ; Sun, 20 Dec 1998 19:33:22 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id TAA25994 for ; Sun, 20 Dec 1998 19:33:20 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id DA27254; Mon, 21 Dec 1998 14:32:41 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: "Raghu V.V.J Vadapalli" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6920) Re: An simple idea thrown into the air. In-Reply-To: Your message of "Sun, 20 Dec 1998 19:17:39 -0800." <19981221031739.29493.rocketmail@send102.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Dec 1998 14:32:41 +1100 Message-Id: <27893.914211161@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 20 Dec 1998 19:17:39 -0800 (PST) From: "Raghu V.V.J Vadapalli" Message-ID: <19981221031739.29493.rocketmail@send102.yahoomail.com> | I think u misunderstood that. Let the extra bit be A. | Where A can take 1 or 0. | 1: IPv6 address and 0: IPv6 address space. That isn't the way I read the suggestion that started this. It seemed very clear to me that if the magic bit were set to 1, then the length of the address was to be doubled. Certainly simply adding 1 bit to the address size would be a waste of time - if we're ever about to run out of addresses doubling the address space is not likely to save us for long enough to be worth the effort. | I think 2^128 is not a big number for the internet. I think you have no idea just how big 2^128 really is (compared say to the estimates of the number of atoms in the universe). But once again, this discussion is pointless. It has been held before, with much more convincing arguments for variable length addresses than have appeared here just recently, and even then the simplicity of fixed size addresses was seen as the best way to go. 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 Dec 20 20:39:47 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id UAA12766 for ipng-dist; Sun, 20 Dec 1998 20:29:42 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id UAA12759 for ; Sun, 20 Dec 1998 20:29:30 -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 UAA18436 for ; Sun, 20 Dec 1998 20:29:32 -0800 Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA08881 for ; Sun, 20 Dec 1998 20:29:29 -0800 (PST) Received: from jimmy.trumpet.com.au (jimmy.trumpet.com.au [203.5.119.2]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id PAA15449 for ; Mon, 21 Dec 1998 15:29:27 +1100 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 6921) Re: An simple idea thrown into the air. Date: Mon, 21 Dec 1998 15:30:10 +1100 Message-ID: <3c9m1fa$1fq@jimmy.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <27893.914211161@munnari.OZ.AU> Robert Elz writes: >From: Robert Elz >To: "Raghu V.V.J Vadapalli" >Cc: ipng@sunroof.Eng.Sun.COM >Subject: (IPng 6920) Re: An simple idea thrown into the air. >Date: Mon, 21 Dec 1998 14:32:41 +1100 > Date: Sun, 20 Dec 1998 19:17:39 -0800 (PST) > From: "Raghu V.V.J Vadapalli" > Message-ID: <19981221031739.29493.rocketmail@send102.yahoomail.com> > | I think u misunderstood that. Let the extra bit be A. > | Where A can take 1 or 0. > | 1: IPv6 address and 0: IPv6 address space. >That isn't the way I read the suggestion that started this. It seemed very >clear to me that if the magic bit were set to 1, then the length of the >address was to be doubled. Certainly simply adding 1 bit to the address >size would be a waste of time - if we're ever about to run out of addresses >doubling the address space is not likely to save us for long enough to be >worth the effort. > | I think 2^128 is not a big number for the internet. >I think you have no idea just how big 2^128 really is (compared say to the >estimates of the number of atoms in the universe). >But once again, this discussion is pointless. It has been held before, >with much more convincing arguments for variable length addresses than have >appeared here just recently, and even then the simplicity of fixed size >addresses was seen as the best way to go. >kre Yes, I can well understand. But was that discussion before the Auto address config changed to 64 bits? Doing that has depleted the address space somewhat, leaving us with only 64 bits of routing information. Current heirarchical address management plans may quickly deplete the remaining 64 bits. Comparing with the typical IPv4 routing info of say 16-24 bits shows that while the number of bits has grown 4 times, the effective growth from a routing point of view is roughly more than twice, although it is probably a fair assumption to say that a site is not going to run out of addresses. I guess it boils down to whether we can realistically say that the routing gook is safe at the current number of bits assigned. Our estimates of address use are based on our *current* understanding of how the internet is managed and used. Who's to say that the number of hierarchical levels of Internet management grows unexpectedly resulting in localized cramming of the address space. Imagine each house being a virtual ISP, suburbs, cities etc... I can think of a few ways to exhaust the hiearchical address space vertically. We haven't really seen the next great wave of the Internet. The crux of my argument is that while the raw number of addresses is effectively infinite, the way that it is structured is certainly not. Robert, I don't think it's really fair to discourage discussion on the issue when there are now many more participants in the IPng discussion than there were before. Even if we end up with the same conclusions as before, I believe that the discussion will be valuable and may shed light on issues that may have been overlooked, discarded or were not even thought of before. I am personally glad that the question was asked as it has allowed me to express some concerns that have been brewing over the limitations of hierarchical address management within a fixed address space. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 20 21:57:30 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id VAA12862 for ipng-dist; Sun, 20 Dec 1998 21:46:49 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id VAA12855 for ; Sun, 20 Dec 1998 21:46: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 VAA22352 for ; Sun, 20 Dec 1998 21:46:42 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id VAA27826 for ; Sun, 20 Dec 1998 21:46:39 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id FA29231; Mon, 21 Dec 1998 16:46:33 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: pete@trumpet.com.au (Peter R. Tattam) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6923) Re: An simple idea thrown into the air. In-Reply-To: Your message of "Mon, 21 Dec 1998 15:30:10 +1100." <3c9m1fa$1fq@jimmy.trumpet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Dec 1998 16:46:32 +1100 Message-Id: <28514.914219192@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 21 Dec 1998 15:30:10 +1100 From: pete@trumpet.com.au (Peter R. Tattam) Message-ID: <3c9m1fa$1fq@jimmy.trumpet.com.au> | But was that discussion before the Auto address | config changed to 64 bits? It was before. But all the initial discussions (before there was any autoconfig) put the total address size needed at somewhere about 64 bits - that's where the calculations lead. That included both the routing gook, and the local subnet numbering (though the latter wasn't given large numbers of bits). What we have now is 64 bits for routing gook alone, with the on-subnet numbering being the other 64 bits (for autoconfig). That's basically an extra couple of orders of magnitude of routing good size over what was calculated before, which is enough to satisfy (most of) those who were just a little concerned that the initial 64 bits planned was not enough. | Who's to say that the number of | hierarchical levels of Internet management grows unexpectedly resulting in | localized cramming of the address space. This can only happen because of poorly designed address hierarchies. That incidentally is what I think we have now - but I also don't think it matters in the slightest. In the IPv4 world we've gone through 2 or 3 major paradigm shifts in address management, in IPv6 we can easily do the same. If we come to the conclusion that the way that we're handing out addresses is ineffecient, then we just change the method, and people renumber. Recall that renumbering is intended to be a (moderately) commonplace event for v6. | Robert, I don't think it's really fair to discourage discussion on the issue I would suggest that those who care should go look at the big-internet archives and examine all the discussions on this which took place during 92, 93 and 94. (those archives can be found at ftp://munnari.oz.au/big-internet/list-archive/) If they still exist, looking at the archives of the sip (and sipp if it ever was different) lists would be instructive as well. | when there are now many more participants in the IPng discussion than there | were before. No, I think there were more before, when the basics were being set. Many more. Now that all that is left is to actually get the thing deployed, and finish the more esoteric parts, many are no longer so actively involved. 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 Mon Dec 21 00:38:00 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id AAA12969 for ipng-dist; Mon, 21 Dec 1998 00:29:02 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id AAA12962 for ; Mon, 21 Dec 1998 00:28:53 -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 AAA22628 for ; Mon, 21 Dec 1998 00:28:53 -0800 Received: from alphatje.NL.net (alphatje.NL.net [193.78.240.11]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA09002 for ; Mon, 21 Dec 1998 00:28:52 -0800 (PST) Received: from db52-69.Den-Bosch.NL.net ([212.206.201.70]:24359 "HELO acnllelo" ident: "NO-IDENT-SERVICE[2]") by alphatje.NL.net with SMTP id <230587-13384>; Mon, 21 Dec 1998 09:27:54 +0100 Received: by localhost with Microsoft MAPI; Mon, 21 Dec 1998 09:28:48 +0100 Message-ID: <841A3211363CD21182E500A0C9B40892B7CD@ACDBS01> From: Ernst Lopes Cardozo To: "'Peter R. Tattam'" , IPNG List Subject: (IPng 6925) Re: An simple idea thrown into the air. Date: Mon, 21 Dec 1998 09:26:34 +0100 Organization: Aranea Consult BV X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter et al, isn't address extension already a possibility? When we need it, we can just define another hop-by-hop option. That is in addition to the fact that we can move to version number 7. The problem is not so much hat we would need to define extra bits in the IPv6 header, but would have to decide *now* on its meaning such that it can be included in every implementation (and tested...). If we just define a flag that says "different address format" without specifying, we would still have to open every implementation to make it work. It seems likely that by that time we want to change other aspects as well, i.e. move to a new version. To turn the argument around, let's be happy that we are running out of IPv4 space, so that we now have a chance to clean up the protocol and add a lot of functionality that otherwise would be difficult to get implemented ;-) -----Original Message----- From: Peter R. Tattam [SMTP:pete@trumpet.com.au] Sent: Monday, December 21, 1998 2:34 AM To: IPNG List Subject: (IPng 6915) Re: An simple idea thrown into the air. In article <005d01be2c7c$7afcfe80$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> "Mitch Denny" writes: >Myron, >I don't think IPv6 will last a few decades, >not with the rate of IT growth that we are >experiencing, the problem is not neccessarily >address space the the need to implement >new technologies. >My point was that adding an extra bit probably >won't achieve much, other then giving twice >the address space. The big advancement with >IPv6 is all the extra functionality that is >added. >A the comming decades there will be need for >more and more functionality, and no matter >how are we try to cater for technology >that we haven't yet invented, there will always >be something that breaks the bank. >Cheers, >Mitch Denny >warbyte@ezymail.com My personal belief is that the 128 bit address space will somehow get exhausted, either through hoarding or unforeseen applications that may require a huge virtual internet address space. Just a gut feeling having been in the ISP industry for a while. One possibility would be some kind of artificial intelligence application/protocol that was somehow recursive and could not be sustained with a fixed address length. Perhaps rather than being in the header, have a special escape prefix reserved for address extension. Those stacks that don't want to support it can simply reject/ignore addresses of that type and continue with currently specified address functionality. Future stacks could switch the address extension on at a future date. We don't need to define the details of the address extension, but rather provide the opening for it in the future. It's not too late to do this in my opinion. We will kick ourselves if the opportunity was there and we didn't take it. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mon Dec 21 02:47:28 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id CAA13064 for ipng-dist; Mon, 21 Dec 1998 02:37:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id CAA13057 for ; Mon, 21 Dec 1998 02:37: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 CAA18934 for ; Mon, 21 Dec 1998 02:37:24 -0800 Received: from theoryx (theoryx.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA15696 for ; Mon, 21 Dec 1998 02:37:19 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx (8.9.1a/8.9.1) with ESMTP id LAA07879; Mon, 21 Dec 1998 11:35:32 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id LAA13124; Mon, 21 Dec 1998 11:35:31 +0100 (MET) Message-ID: <19981221113531.B13062@cs.uni-bonn.de> Date: Mon, 21 Dec 1998 11:35:31 +0100 From: Ignatios Souvatzis To: "Raghu V.V.J Vadapalli" , Robert Elz , ipng@sunroof.eng.sun.com Subject: (IPng 6926) Re: An simple idea thrown into the air. References: <19981221031739.29493.rocketmail@send102.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <19981221031739.29493.rocketmail@send102.yahoomail.com>; from Raghu V.V.J Vadapalli on Sun, Dec 20, 1998 at 07:17:39PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Dec 20, 1998 at 07:17:39PM -0800, Raghu V.V.J Vadapalli wrote: > Which actully doubles the address space. > > I think 2^128 is not a big number for the internet. > If all the devices (for example car, oven, ur lights...) > then you will run out of IPv6 address space. Please do the math yourself... but if you want to believe me: 2^128 addresses is about 661103768829069934368299 addresses per square meter of Earth surface. 2^64 possible networks (with the current numbering plan) is still 35838 networks per square meter. (and you only need 6% to also add the Moon surface, and no, I don't believe the Global Internet will ever be able to really work effective on further-than -moon distances due to the HUGE delays involved). I'm not totally convinced you really need more than 70000 _networks_ per office desk. (Remember, even one network on your desk will give you 9223372036854 addressible entities per square millimeter). Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 03:35:19 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id DAA13125 for ipng-dist; Mon, 21 Dec 1998 03:27:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id DAA13118 for ; Mon, 21 Dec 1998 03:27: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 DAA20753 for ; Mon, 21 Dec 1998 03:27:10 -0800 Received: from cpcug.org (cpcug.org [205.197.248.25]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA27257 for ; Mon, 21 Dec 1998 03:27:10 -0800 (PST) Received: from papabear.aubert.net. (asc231.idsonline.com [207.176.21.231]) by cpcug.org (8.8.4/8.6.12) with SMTP id GAA28772 for ; Mon, 21 Dec 1998 06:26:58 -0500 (EST) Message-Id: <3.0.5.32.19981221062410.00b65bd0@cpcug.org> X-Sender: jaubert@cpcug.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 21 Dec 1998 06:24:10 -0500 To: ipng@sunroof.eng.sun.com From: Jack Aubert Subject: (IPng 6927) Re: An simple idea thrown into the air. In-Reply-To: <19981221113531.B13062@cs.uni-bonn.de> References: <19981221031739.29493.rocketmail@send102.yahoomail.com> <19981221031739.29493.rocketmail@send102.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And here's a calculation I used for a class paper I wrote: "128 bits (2128) is a very big number. In fact, it is a very, very, very big number. It works out to be : 340,282,366,920,938,463,463,374,607,431,768,211,456. Some intuitive appreciation for the order of magnitude can be grasped imagining that the earth globe were made up entirely of fine beach sand. Assuming sand = .1 millimeter and the earth's diameter = 7,926 miles, each grain could be given approximately 386,727 IPv6 addresses! " Now obviously this is misleading because of topological and hierarchical requirements will lead to an enormous "waste" of addresses... but still, the 128 bit size should be enough to accomodate this waste. Furthermore, the whole "running out of addresses" issue has been somewhat less acute becasuse of increased use of pravate space -- particularly the 10.0.0.0 reserved A address -- and NAT. At 11:35 AM 12/21/98 +0100, Ignatios Souvatzis wrote: >On Sun, Dec 20, 1998 at 07:17:39PM -0800, Raghu V.V.J Vadapalli wrote: >> Which actully doubles the address space. >> >> I think 2^128 is not a big number for the internet. >> If all the devices (for example car, oven, ur lights...) >> then you will run out of IPv6 address space. > >Please do the math yourself... but if you want to believe me: > >2^128 addresses is about 661103768829069934368299 addresses per square meter >of Earth surface. > >2^64 possible networks (with the current numbering plan) is still 35838 >networks per square meter. > >(and you only need 6% to also add the Moon surface, and no, I don't believe >the Global Internet will ever be able to really work effective on further-than >-moon distances due to the HUGE delays involved). > >I'm not totally convinced you really need more than 70000 _networks_ per >office desk. (Remember, even one network on your desk will give you >9223372036854 addressible entities per square millimeter). > >Regards, > Ignatios Souvatzis >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Mon Dec 21 03:56:36 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id DAA13164 for ipng-dist; Mon, 21 Dec 1998 03:53:29 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id DAA13157 for ; Mon, 21 Dec 1998 03:53: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 DAA14169 for ; Mon, 21 Dec 1998 03:53:18 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA03098 for ; Mon, 21 Dec 1998 03:53:18 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA156800; Mon, 21 Dec 1998 11:53:15 GMT Received: from hursley.ibm.com (9-20-31-131.dhcp.hursley.ibm.com [9.20.31.131]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA20962; Mon, 21 Dec 1998 11:53:14 GMT Message-ID: <367E3675.3D896A95@hursley.ibm.com> Date: Mon, 21 Dec 1998 11:52:21 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Robert Elz CC: "Peter R. Tattam" , ipng@sunroof.eng.sun.com Subject: (IPng 6928) Re: An simple idea thrown into the air. References: <28514.914219192@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with kre. There were many people who felt that IPv6 should have had variable length addresses, but we got IETF consensus for the current fixed length in 1994, and we are way beyond that era of the debate. Brian Carpenter Robert Elz wrote: > > Date: Mon, 21 Dec 1998 15:30:10 +1100 > From: pete@trumpet.com.au (Peter R. Tattam) > Message-ID: <3c9m1fa$1fq@jimmy.trumpet.com.au> > > | But was that discussion before the Auto address > | config changed to 64 bits? > > It was before. But all the initial discussions (before there was > any autoconfig) put the total address size needed at somewhere about > 64 bits - that's where the calculations lead. That included both > the routing gook, and the local subnet numbering (though the latter wasn't > given large numbers of bits). What we have now is 64 bits for routing > gook alone, with the on-subnet numbering being the other 64 bits (for > autoconfig). That's basically an extra couple of orders of magnitude > of routing good size over what was calculated before, which is enough > to satisfy (most of) those who were just a little concerned that the > initial 64 bits planned was not enough. > > | Who's to say that the number of > | hierarchical levels of Internet management grows unexpectedly resulting in > | localized cramming of the address space. > > This can only happen because of poorly designed address hierarchies. That > incidentally is what I think we have now - but I also don't think it matters > in the slightest. In the IPv4 world we've gone through 2 or 3 major paradigm > shifts in address management, in IPv6 we can easily do the same. If we come > to the conclusion that the way that we're handing out addresses is ineffecient, > then we just change the method, and people renumber. Recall that renumbering > is intended to be a (moderately) commonplace event for v6. > > | Robert, I don't think it's really fair to discourage discussion on the issue > > I would suggest that those who care should go look at the big-internet archives > and examine all the discussions on this which took place during 92, 93 and 94. > (those archives can be found at ftp://munnari.oz.au/big-internet/list-archive/) > > If they still exist, looking at the archives of the sip (and sipp if it ever > was different) lists would be instructive as well. > > | when there are now many more participants in the IPng discussion than there > | were before. > > No, I think there were more before, when the basics were being set. Many > more. Now that all that is left is to actually get the thing deployed, and > finish the more esoteric parts, many are no longer so actively involved. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 03:58:01 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id DAA13173 for ipng-dist; Mon, 21 Dec 1998 03:56:16 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id DAA13166 for ; Mon, 21 Dec 1998 03:55: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 DAA11379 for ; Mon, 21 Dec 1998 03:55:49 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA03729 for ; Mon, 21 Dec 1998 03:55:49 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA81798; Mon, 21 Dec 1998 11:55:46 GMT Received: from hursley.ibm.com (9-20-31-131.dhcp.hursley.ibm.com [9.20.31.131]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA21076; Mon, 21 Dec 1998 11:55:45 GMT Message-ID: <367E3710.2F2C2048@hursley.ibm.com> Date: Mon, 21 Dec 1998 11:54:56 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Robert Elz CC: "Peter R. Tattam" , ipng@sunroof.eng.sun.com Subject: (IPng 6929) Re: An simple idea thrown into the air. References: <28514.914219192@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oh, I forgot my own RFC. Variable length address fans can look at RFC 1888. 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 Mon Dec 21 07:19:16 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id HAA13529 for ipng-dist; Mon, 21 Dec 1998 07:09:31 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id HAA13522 for ; Mon, 21 Dec 1998 07:09: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 HAA24427 for ; Mon, 21 Dec 1998 07:09:14 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA09437 for ; Mon, 21 Dec 1998 07:09:14 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA17175; Mon, 21 Dec 1998 09:08:58 -0600 (CST) Message-Id: <199812211508.JAA17175@gungnir.fnal.gov> To: warbyte@ezymail.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 6930) Re: An simple idea thrown into the air. In-reply-to: Your message of Mon, 21 Dec 1998 10:52:27 +1000. <005b01be2c7c$2e2f2100$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> Date: Mon, 21 Dec 1998 09:08:58 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You can assign an IPv6 address to each cell in your body and still not use up one subnet. Now go read the archives and the background documents. > Steve, > > I want to get my own address range, > for personal use. > > One for each of my shoes, plus one > for each shoe lace (smart laces). > > I am pretty sure that I will need > an IP address for each of my hair folicles > too :) > > No matter how much address space we > assign ourselves (fixed or variable) > we will always approach capacity at a > steady rate. > > Cheers, > > Mitch Denny > warbyte@ezymail.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 Dec 21 08:00:46 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id HAA13720 for ipng-dist; Mon, 21 Dec 1998 07:51:20 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id HAA13713 for ; Mon, 21 Dec 1998 07:51:11 -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 HAA12554 for ; Mon, 21 Dec 1998 07:51:08 -0800 Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA00271 for ; Mon, 21 Dec 1998 07:51:09 -0800 (PST) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id KAA11004; Mon, 21 Dec 1998 10:51:04 -0500 (EST) Message-Id: <199812211551.KAA11004@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Myron Szymanskyj cc: ipng@sunroof.eng.sun.com Subject: (IPng 6931) Re: An simple idea thrown into the air. In-reply-to: Your message of "Sun, 20 Dec 1998 14:53:40 GMT." <4.1.0.67.19981220144441.0093c4c0@pop.pol.net.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Dec 1998 10:51:04 -0500 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Myron Szymanskyj wrote: > Would it not be a good idea to put in right from the start a mechanism (be > it an extra bit in the IP header) that if it's set to 1, the IP address is > treated to be double the size of the current draft? This to be built into > all the new server software that is to appear. Bit 3 of the header (starting at bit 0) has already been pre-allocated to indicate the next version of the Internet Protocol. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake RTP Development Lab (919)468-8466 x232 Torrent Networking Technologies www.torrentnet.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 Dec 21 09:22:57 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id JAA13961 for ipng-dist; Mon, 21 Dec 1998 09:14:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA13954 for ; Mon, 21 Dec 1998 09:14:42 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA00759 for ; Mon, 21 Dec 1998 09:14:52 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA05937 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 09:14:07 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id HAA11716 for ; Sun, 20 Dec 1998 07:52:03 -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 HAA25551 for ; Sun, 20 Dec 1998 07:52:00 -0800 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA09879 for ; Sun, 20 Dec 1998 07:52:01 -0800 (PST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Dec 20 10:50:08 EST 1998 Received: from dnrc.bell-labs.com (root@prz-home [135.180.152.138]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA21838; Sun, 20 Dec 1998 10:50:06 -0500 (EST) Message-ID: <367D1A93.D06C0B54@dnrc.bell-labs.com> Date: Sun, 20 Dec 1998 10:41:07 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: "Raghu V.V.J Vadapalli" CC: routing quality , Internet Protocol , MultiProtocol Label Switching Subject: (IPng 6932) Re: Reg: Quality of Service routing References: <19981220150534.13933.rocketmail@send103.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu V.V.J Vadapalli wrote: > > Dear All, > > I have one basic question regarding QoS routing. > > Do we need QoS routing if we have enough infinite (I mean > large ) bandwidth. > > From my poor knowledge: > > We need QoS routing b'cos we have limited BW and we want > to give priority to QoS flows. If some one comes with > a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > Do we need to support the "special" status for the QoS flows. > May in that case the memory at the routers will be > bottleneck. > > Am I missing something. > With Regards > -Raghu. > > I am not aware that you can generally trade bandwidth for delay (said simply: if you have end-2-end delay constraints to meet & sum of your link propagation delays exceeds it, there is little you can do) so having arbitrary amounts of bandwidth does not necessarily solve the end-2-end delay problem. thank you --- tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 09:24:07 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id JAA13981 for ipng-dist; Mon, 21 Dec 1998 09:21:50 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA13974 for ; Mon, 21 Dec 1998 09:21:41 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA01543 for ; Mon, 21 Dec 1998 09:21:52 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA05979 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 09:21:07 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id JAA11759 for ; Sun, 20 Dec 1998 09:22: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 JAA18771 for ; Sun, 20 Dec 1998 09:22:22 -0800 Received: from pender.ee.upenn.edu (PENDER.EE.UPENN.EDU [130.91.5.20]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA25709 for ; Sun, 20 Dec 1998 09:22:20 -0800 (PST) Received: from ee.upenn.edu (slip-129-37-18-146.ny.us.ibm.net [129.37.18.146]) by pender.ee.upenn.edu (8.8.5/8.8.4) with ESMTP id MAA20047; Sun, 20 Dec 1998 12:21:36 -0500 (EST) Message-ID: <367D2FCC.862C361@ee.upenn.edu> Date: Sun, 20 Dec 1998 12:11:40 -0500 From: Roch Guerin Organization: University of Pennsylvania X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "Raghu V.V.J Vadapalli" CC: routing quality , Internet Protocol , MultiProtocol Label Switching Subject: (IPng 6933) Re: Reg: Quality of Service routing References: <19981220150534.13933.rocketmail@send103.yahoomail.com> Content-Type: multipart/mixed; boundary="------------ACB4A20C98311955CA9495CD" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------ACB4A20C98311955CA9495CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Raghu V.V.J Vadapalli wrote: > Dear All, > > I have one basic question regarding QoS routing. > > Do we need QoS routing if we have enough infinite (I mean > large ) bandwidth. > > From my poor knowledge: > > We need QoS routing b'cos we have limited BW and we want > to give priority to QoS flows. If some one comes with > a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > Do we need to support the "special" status for the QoS flows. > May in that case the memory at the routers will be > bottleneck. Besides the delay issue that Tony mentions, you should also consider that tx bandwidth is not the only resource inolved in delivering your data. You also need switches/routers that can keep up with the bandwidth, and if they don't they are the resource you need to focus on, i.e., you need to consider the forwarding tput available rather than just the raw bandwidth. Roch --------------ACB4A20C98311955CA9495CD Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Description: Card for Roch Guerin Content-Disposition: attachment; filename="vcard.vcf" Content-Transfer-Encoding: 7bit begin: vcard fn: Roch Guerin n: Guerin;Roch org: University of Pennsylvania email;internet: guerin@ee.upenn.edu title: Prof. x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------ACB4A20C98311955CA9495CD-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 09:34:52 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id JAA14036 for ipng-dist; Mon, 21 Dec 1998 09:25:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA14029 for ; Mon, 21 Dec 1998 09:25:16 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA01982 for ; Mon, 21 Dec 1998 09:25:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA06024 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 09:24:42 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id LAA11873 for ; Sun, 20 Dec 1998 11:53: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 LAA22488 for ; Sun, 20 Dec 1998 11:53:06 -0800 Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA22208 for ; Sun, 20 Dec 1998 11:53:05 -0800 (PST) Received: from cisco.com ([171.70.117.114]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA16523; Sun, 20 Dec 1998 11:52:23 -0800 (PST) Message-ID: <367D469C.DD5AAFBB@cisco.com> Date: Sun, 20 Dec 1998 12:49:00 -0600 From: Qingming Ma Reply-To: qma@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Roch Guerin CC: "Raghu V.V.J Vadapalli" , routing quality , Internet Protocol , MultiProtocol Label Switching Subject: (IPng 6934) Re: Reg: Quality of Service routing References: <19981220150534.13933.rocketmail@send103.yahoomail.com> <367D2FCC.862C361@ee.upenn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Roch. Router packet pool memory and CPU cycles can often become bottleneck in certain scenarios, especially when packet forwarding is done by software. One probably should never expect that there are sufficient memory and CPU cycles, since keeping adding new QoS features (e.g., classifying, scheduling, admission, reservation, policy enforcing, access control, ...) will consume more and more CPU resources. Let us assume that router CPU is never the bottleneck. Even with sufficient large amount of bandwidth, we may still need QoS routing, unless one can ensure that the traffic load is always below the link capacity and the network rarely gets congested. One common belief is that QoS is only needed when the load of QoS traffic is heavy, so that we can reduce the number of requests being blocked. However, QoS routing is still useful even when the QoS traffic load is light. For example, when the load of best effort traffic is heavy and conentrated on some hot links, although call blocking rate for QoS traffic is not an issue, but encourage QoS traffic to use the links with relatively light load of best effort traffic can improve over all throughput for best effort traffic. Qingming Roch Guerin wrote: > > Raghu V.V.J Vadapalli wrote: > > > Dear All, > > > > I have one basic question regarding QoS routing. > > > > Do we need QoS routing if we have enough infinite (I mean > > large ) bandwidth. > > > > From my poor knowledge: > > > > We need QoS routing b'cos we have limited BW and we want > > to give priority to QoS flows. If some one comes with > > a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > > Do we need to support the "special" status for the QoS flows. > > May in that case the memory at the routers will be > > bottleneck. > > Besides the delay issue that Tony mentions, you should also consider > that tx bandwidth is not the only resource inolved in delivering your > data. You also need switches/routers that can keep up with the > bandwidth, and if they don't they are the resource you need to focus on, > i.e., you need to consider the forwarding tput available rather than > just the raw bandwidth. > > Roch > > ------------------------------------------------------------------------ > Name: vcard.vcf > vcard.vcf Type: VCard (text/x-vcard) > Encoding: 7bit > Description: Card for Roch Guerin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 09:36:19 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id JAA14119 for ipng-dist; Mon, 21 Dec 1998 09:33:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA14112 for ; Mon, 21 Dec 1998 09:33:39 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA03143 for ; Mon, 21 Dec 1998 09:33:49 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA06080 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 09:33:05 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id QAA12371 for ; Sun, 20 Dec 1998 16:57: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 QAA15246 for ; Sun, 20 Dec 1998 16:57:24 -0800 Received: from krdl.org.sg (rodin.krdl.org.sg [137.132.252.27]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA20591 for ; Sun, 20 Dec 1998 16:57:24 -0800 (PST) Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [137.132.247.30]) by krdl.org.sg (8.9.0/8.9.0) with ESMTP id IAA07388; Mon, 21 Dec 1998 08:53:05 +0800 (SGT) Received: from fireball (fireball [137.132.248.126]) by mailhost.krdl.org.sg (8.9.0/8.9.0) with SMTP id IAA28957; Mon, 21 Dec 1998 08:47:31 +0800 (SGT) Date: Mon, 21 Dec 1998 08:28:24 +0800 (SGT) From: Masilamany Raguparan X-Sender: ragu@fireball To: "Raghu V.V.J Vadapalli" cc: routing quality , Internet Protocol , MultiProtocol Label Switching Subject: (IPng 6936) Re: Reg: Quality of Service routing In-Reply-To: <19981220150534.13933.rocketmail@send103.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu, | Do we need QoS routing if we have enough infinite (I mean | large ) bandwidth. | | From my poor knowledge: | | We need QoS routing b'cos we have limited BW and we want | to give priority to QoS flows. If some one comes with | a Tx system which supports 100s Gb/s,(say 128 channel WDM system) | Do we need to support the "special" status for the QoS flows. Nature of the traffic can be very bursty and suck up your 100s of Gb/s bandwidth easily at any given time slot. Therefore, having just large bit pipes does not solve the QoS problem. Your delay = propagation time + queuing time + processing time equation certainly works, if you have enough capacity left on the link at the time of your request. | May in that case the memory at the routers will be | bottleneck. This problem is well addressed in the previous answers from Roch & others Ragu. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 09:49:35 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id JAA14199 for ipng-dist; Mon, 21 Dec 1998 09:39:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA14192 for ; Mon, 21 Dec 1998 09:39:39 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA03884 for ; Mon, 21 Dec 1998 09:39:49 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA06153 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 09:39:04 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id SAA12561 for ; Sun, 20 Dec 1998 18:20:03 -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 SAA10088 for ; Sun, 20 Dec 1998 18:20:02 -0800 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by earth.sun.com (8.9.1/8.9.1) with SMTP id SAA09605 for ; Sun, 20 Dec 1998 18:20:01 -0800 (PST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Dec 20 21:19:33 EST 1998 Received: from dnrc.bell-labs.com (root@prz-home [135.180.152.138]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id VAA28931; Sun, 20 Dec 1998 21:19:30 -0500 (EST) Message-ID: <367DAE12.F66AB40C@dnrc.bell-labs.com> Date: Sun, 20 Dec 1998 21:10:26 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Masilamany Raguparan CC: "Raghu V.V.J Vadapalli" , routing quality , Internet Protocol , MultiProtocol Label Switching Subject: (IPng 6937) Re: Reg: Quality of Service routing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masilamany Raguparan wrote: > > Raghu, > > | Do we need QoS routing if we have enough infinite (I mean > | large ) bandwidth. > | > | From my poor knowledge: > | > | We need QoS routing b'cos we have limited BW and we want > | to give priority to QoS flows. If some one comes with > | a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > | Do we need to support the "special" status for the QoS flows. > > Nature of the traffic can be very bursty and suck up your 100s of Gb/s > bandwidth easily at any given time slot. Therefore, having just large bit > pipes does not solve the QoS problem. > > Your delay = propagation time + queuing time + processing time equation > certainly works, if you have enough capacity left on the link at the time > of your request. > Let me bring the economical and philosophical component into this discussion that I tried not to touch so far but probably needs being spelled out: 1. Any amount of bandwidth can be thrown at the problem. 100 Gb/s on transmission media and beyond are not a dream but as CPU, bus & memory technologies taught us, matter of years at most. 2. CPU problems, memory bandwidths, complicated lookups, per-flow-queining in ASICs and other "traditional-router" problems that QMA brings up can be solved based on the fact that "pigs with enough thrust fly just fine" (Ross) and made ATM such a hard sell. Thrust being here on one hand IP being open and amazingly scalable (with hacks of course ;-) technology, on the other hand the expected (and for some companies already real) significant revenues from networking and on the third hand progress in ASIC technology. 3. Any amount of a free (or perceived as free) resource on this planet has or is being depleted if it has any value. why is a question that has seemingly simple answers but can run very deep. I highly recommend http://pespmc1.vub.ac.be/Default.html Therefore I believe that we'll always face congestion in today's model of the Internet, no matter how much bandwidth you are willing to throw at the problem. Which leads to the core of what I try to say: QoS routing is just one possible mechanism how to provide certain guarantees about certain resources to the user. What the resources are and what other mechanisms could be used (network engineering or over-engineering, shaping, CAC and others exist) depends on the pricing model which is basically a function you try to optimize on. Since pricing in the Internet today is basically flat at the end-user level, there is little or no incentive to provide guarantees and therefore deploy something along the lines of QoS routing. Given a different pricing (and an according billing, that's of course the tough part ;-), different mechanisms could be necessary and being deployed. The picture is particularly twisted IMHO since lots of things you'd want to do are not necessarily what is possible (or being perceived as possible) from the technological perspective and therefore widely different perceptions of what reality of data networking on the scale of the planet should be clash in entertaining fireworks onto each other in recent years. I hope that unifies or at least spells out lots of implicit assumptions that I sensed in the different mails sent to this thread ... thank you --- tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 09:49:35 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id JAA14224 for ipng-dist; Mon, 21 Dec 1998 09:42:23 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA14217 for ; Mon, 21 Dec 1998 09:42:18 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA04169 for ; Mon, 21 Dec 1998 09:42:29 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA06188 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 09:41:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id VAA12843 for ; Sun, 20 Dec 1998 21:39: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 VAA06077 for ; Sun, 20 Dec 1998 21:39:50 -0800 Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA26394 for ; Sun, 20 Dec 1998 21:39:51 -0800 (PST) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQfure06361; Mon, 21 Dec 1998 00:39:02 -0500 (EST) Received: by neserve0.uu.net id QQfure13620; Mon, 21 Dec 1998 00:38:54 -0500 (EST) From: awduche@UU.NET (Daniel Awduche) Message-Id: Subject: (IPng 6938) Re: Reg: Quality of Service routing To: prz@dnrc.bell-labs.com (Antoni Przygienda) Date: Mon, 21 Dec 1998 00:38:54 -0500 (EST) Cc: ragu@krdl.org.sg, iprsvp@yahoo.com, qosr@newbridge.com, ipng@sunroof.eng.sun.com, mpls@external.cisco.com In-Reply-To: <367DAE12.F66AB40C@dnrc.bell-labs.com> from "Antoni Przygienda" at Dec 20, 98 09:10:26 pm 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 Tony P. has captured the basic issues very nicely. The fundamental problem is that of resource management. Specifically, the controlled mapping of traffic onto network elements to achieve desired performance objectives. The Internet being an economic system, the problem of resource management will persist even as technology and terminology evolve. Constraint based routing (of which QoS routing is a subset), allows the mapping of traffic onto network assets to be effected in a controlled fashion. Diffserv provides additional mechanisms for localized control. In general, cost structure, revenue model, competition, and other miscellaneous factors will impact optimization policy. Even if bandwidth becomes cheap and plentiful, and we suppose no imaginative entrepreneurs exist to create new services that exploit this abundance (thereby creating a new cycle of demand), the issue of effectiveness concerning resource management will remain a significant aspect for many ISPs who must derive a return on their investment in infrastructure. /Dan. Antoni Przygienda said: > > Let me bring the economical and philosophical component into this > discussion > that I tried not to touch so far but probably needs being spelled out: > > 1. Any amount of bandwidth can be thrown at the problem. 100 Gb/s on > transmission media > and beyond are not a dream but as CPU, bus & memory technologies taught > us, > matter of years at most. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 10:04:00 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id JAA14324 for ipng-dist; Mon, 21 Dec 1998 09:52:04 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA14317 for ; Mon, 21 Dec 1998 09:51:59 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id JAA05392 for ; Mon, 21 Dec 1998 09:52:10 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA06263 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 09:51:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id WAA12918 for ; Sun, 20 Dec 1998 22:21: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 WAA08092 for ; Sun, 20 Dec 1998 22:21:19 -0800 Received: from poteidaia.utdallas.edu (poteidaia.utdallas.edu [129.110.10.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA06531 for ; Sun, 20 Dec 1998 22:21:20 -0800 (PST) Received: from apache.utdallas.edu (parag@apache.utdallas.edu [129.110.16.9]) by poteidaia.utdallas.edu (8.9.1/8.9.1/null-3.5) with ESMTP id AAA03174; Mon, 21 Dec 1998 00:11:12 -0600 (CST) Received: from localhost (parag@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with SMTP id AAA09705; Mon, 21 Dec 1998 00:11:11 -0600 (CST) X-Authentication-Warning: apache.utdallas.edu: parag owned process doing -bs Date: Mon, 21 Dec 1998 00:11:11 -0600 (CST) From: Parag M Panse To: Masilamany Raguparan cc: "Raghu V.V.J Vadapalli" , routing quality , Internet Protocol , MultiProtocol Label Switching Subject: (IPng 6939) Re: Reg: Quality of Service routing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 21 Dec 1998, Masilamany Raguparan wrote: > Raghu, > > | Do we need QoS routing if we have enough infinite (I mean > | large ) bandwidth. > | > | From my poor knowledge: > | > | We need QoS routing b'cos we have limited BW and we want > | to give priority to QoS flows. If some one comes with > | a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > | Do we need to support the "special" status for the QoS flows. > > Nature of the traffic can be very bursty and suck up your 100s of Gb/s > bandwidth easily at any given time slot. Therefore, having just large bit > pipes does not solve the QoS problem. > > Your delay = propagation time + queuing time + processing time equation > certainly works, if you have enough capacity left on the link at the time > of your request. An implicit assumption that seems to be made here is regarding 'number of data sources'. While designing a system that guarantees certain values of BW and end-2-end delay, given the present Internet model no assumption can be made about the number of users or the number of sources geneating data. Since no upper bound can be placed on the value of this parameter, even though links with 100Gbps (or higher) , faster CPUs and faster memories are given eventually the 'number of users' will always catch up and so the "queueing delay" factor mentioned in the above equation for delay can be never be eliminated. In fact as the number of users grow, the factor will become more dominant. So it would be incorrect to say that delay ~ propagation time. > > Ragu. > Regards... -Parag -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 10:18:57 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id KAA14464 for ipng-dist; Mon, 21 Dec 1998 10:07:31 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id KAA14457 for ; Mon, 21 Dec 1998 10:07:25 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id KAA07642 for ; Mon, 21 Dec 1998 10:07:36 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA06355 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 10:06:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id JAA14096 for ; Mon, 21 Dec 1998 09:31: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 JAA19648 for ; Mon, 21 Dec 1998 09:31:40 -0800 Received: from bdykes.sni.net. (bdykes.sni.net [198.243.24.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA01194 for ; Mon, 21 Dec 1998 09:31:40 -0800 (PST) Received: from bdykes.sni.net by bdykes.sni.net. (SMI-8.6/SMI-SVR4) id KAA16909; Mon, 21 Dec 1998 10:20:02 -0700 Message-Id: <199812211720.KAA16909@bdykes.sni.net.> X-Mailer: exmh version 2.0.2 2/24/98 To: MultiProtocol Label Switching cc: routing quality , Internet Protocol From: Barry Dykes Reply-To: barry@qwest.net Subject: (IPng 6940) Re: Reg: Quality of Service routing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Dec 1998 10:20:02 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that some other factors occur here also. Real delay problems aren't in regards to bandwidth. Lack of bandwidth causes excessive queuing. Queuing comes in different forms and sizes or depths. Some applications can be sensitive to deeper queues. Many router and switch vendors have multiple queues for this reason. Some have high priority queues with very shallow buckets. QOS can allow a router/switch to "park" a packet in a shallow queue while waiting for it's turn at the outbound interface. It really may not matter that the actual line is only running at 1/4 capacity. But more how many packets are contending for that interface at the same time, and who should have priority to it. Such is the way of bursty traffic. All packets will be delivered in this scenario, only some have minimum delay characteristics that must be met and therefore win in the first contention within the router/switch. Barry > Masilamany Raguparan wrote: > > > > Raghu, > > > > | Do we need QoS routing if we have enough infinite (I mean > > | large ) bandwidth. > > | > > | From my poor knowledge: > > | > > | We need QoS routing b'cos we have limited BW and we want > > | to give priority to QoS flows. If some one comes with > > | a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > > | Do we need to support the "special" status for the QoS flows. > > > > Nature of the traffic can be very bursty and suck up your 100s of Gb/s > > bandwidth easily at any given time slot. Therefore, having just large bit > > pipes does not solve the QoS problem. > > > > Your delay = propagation time + queuing time + processing time equation > > certainly works, if you have enough capacity left on the link at the time > > of your request. > > > > Let me bring the economical and philosophical component into this > discussion > that I tried not to touch so far but probably needs being spelled out: > > 1. Any amount of bandwidth can be thrown at the problem. 100 Gb/s on > transmission media > and beyond are not a dream but as CPU, bus & memory technologies taught > us, > matter of years at most. > 2. CPU problems, memory bandwidths, complicated lookups, > per-flow-queining in ASICs and other > "traditional-router" problems that QMA brings up can be solved based on > the fact that "pigs with enough thrust fly > just fine" (Ross) and made ATM such a hard sell. Thrust being here on > one hand > IP being open and amazingly scalable (with hacks of course ;-) > technology, > on the other hand the expected (and for some companies already real) > significant > revenues from networking and on the third hand progress in ASIC > technology. > 3. Any amount of a free (or perceived as free) resource on this planet > has or is being depleted > if it has any value. why is a question that has seemingly simple > answers but can > run very deep. I highly recommend http://pespmc1.vub.ac.be/Default.html > Therefore I believe that we'll always face congestion in today's model > of the > Internet, no matter how much bandwidth you are willing to throw at the > problem. > > Which leads to the core of what I try to say: QoS routing is just one > possible mechanism > how to provide certain guarantees about certain resources to the user. > What the resources > are and what other mechanisms could be used (network engineering or > over-engineering, > shaping, CAC and others exist) depends on the pricing model which is > basically a function > you try to optimize on. Since pricing in the Internet today is basically > flat at > the end-user level, there is little or no incentive to provide > guarantees and therefore > deploy something along the lines of QoS routing. Given a different > pricing (and an according > billing, that's of course the tough part ;-), different mechanisms could > be > necessary and being deployed. The picture is particularly twisted IMHO > since lots of things > you'd want to do are not necessarily > what is possible (or being perceived as possible) from the technological > perspective and > therefore widely different perceptions of what reality of data > networking on the scale of > the planet should be clash in entertaining fireworks onto each other in > recent years. > > I hope that unifies or at least spells out lots of implicit assumptions > that I sensed in > the different mails sent to this thread ... > > thank you > > --- tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 10:19:06 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id KAA14496 for ipng-dist; Mon, 21 Dec 1998 10:15:11 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id KAA14489 for ; Mon, 21 Dec 1998 10:14: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 KAA18422 for ; Mon, 21 Dec 1998 10:14:48 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA27153 for ; Mon, 21 Dec 1998 10:14:47 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id MAA18039; Mon, 21 Dec 1998 12:14:37 -0600 (CST) Message-Id: <199812211814.MAA18039@gungnir.fnal.gov> To: "Raghu V.V.J Vadapalli" Cc: routing quality , Internet Protocol , MultiProtocol Label Switching From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 6941) Re: Reg: Quality of Service routing In-reply-to: Your message of Sun, 20 Dec 1998 21:10:26 EST. <367DAE12.F66AB40C@dnrc.bell-labs.com> Date: Mon, 21 Dec 1998 12:14:37 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Do we need QoS routing if we have enough infinite (I mean > large) bandwidth. One can't take the word "inifinite" literally and still try to give a sensible answer. What bandwidth would truly be "sufficiently large" that you would never need to consider the need to give some traffic preference over other? That would be the case if every link and switching device in the network had sufficient capacity to carry all the traffic that could conceivably directed through it by the concerted action of all the end nodes. Do you still want to pursue the question under those terms? I don't. ______________________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab "A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment, thoroughly smash them with a hammer or an ax, and scatter the pieces." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 10:31:04 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id KAA14540 for ipng-dist; Mon, 21 Dec 1998 10:20:08 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id KAA14533 for ; Mon, 21 Dec 1998 10:19: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 KAA21706 for ; Mon, 21 Dec 1998 10:19:55 -0800 Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA00435 for ; Mon, 21 Dec 1998 10:19:54 -0800 (PST) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP-external (PP); Mon, 21 Dec 1998 18:19:06 +0000 Date: Mon, 21 Dec 1998 18:19:21 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: qosr@newbridge.com To: Parag M Panse cc: Masilamany Raguparan , "Raghu V.V.J Vadapalli" , routing quality , Internet Protocol , MultiProtocol Label Switching Subject: (IPng 6942) Re: Reg: Quality of Service routing In-Reply-To: Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 21 Dec 1998, Parag M Panse wrote: > On Mon, 21 Dec 1998, Masilamany Raguparan wrote: > > > Raghu, > > > > | Do we need QoS routing if we have enough infinite (I mean > > | large ) bandwidth. > > | > > | From my poor knowledge: > > | > > | We need QoS routing b'cos we have limited BW and we want > > | to give priority to QoS flows. If some one comes with > > | a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > > | Do we need to support the "special" status for the QoS flows. > > > > Nature of the traffic can be very bursty and suck up your 100s of Gb/s > > bandwidth easily at any given time slot. Therefore, having just large bit > > pipes does not solve the QoS problem. > > > > Your delay = propagation time + queuing time + processing time equation > > certainly works, if you have enough capacity left on the link at the time > > of your request. > > An implicit assumption that seems to be made here is regarding 'number of > data sources'. A second assumption is that this is appropriate to all the lists it's being cc'd to. Followups set to qosr only; give those of us subscribed to all the lists a break. L. PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 11:20:55 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id LAA14718 for ipng-dist; Mon, 21 Dec 1998 11:08:02 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id LAA14711 for ; Mon, 21 Dec 1998 11:07: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 LAA27152 for ; Mon, 21 Dec 1998 11:07:38 -0800 Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA01508 for ; Mon, 21 Dec 1998 11:07:38 -0800 (PST) Received: from nomad.er.doe.gov ([192.73.213.46]) by dns2.anl.gov (8.8.7/8.6.11) with SMTP id NAA18308; Mon, 21 Dec 1998 13:07:25 -0600 (CST) Message-Id: <3.0.2.32.19981221131004.006dc4e8@achilles.ctd.anl.gov> X-Sender: b30118@achilles.ctd.anl.gov X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Mon, 21 Dec 1998 13:10:04 -0600 To: "Raghu V.V.J Vadapalli" From: Richard Carlson Subject: (IPng 6943) Re: Reg: Quality of Service routing Cc: routing quality , Internet Protocol , MultiProtocol Label Switching In-Reply-To: <367D1A93.D06C0B54@dnrc.bell-labs.com> References: <19981220150534.13933.rocketmail@send103.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu; This is a very interesting and important question that I don't think gets the attention it deserves. As has been pointed out in other replies to your question, the cost of providing 'enough' forwarding capabilities (switch/routers, link BW, etc) to prevent packet queuing will be high. The unstated (and I believe suspect) assumption is that the cost of providing QoS mechanisms will be lower. I don't think enough research has been done to identify and classify the real costs of deploying a QoS based Internet. By real costs I mean those charges that are required to build a workable global system. Some simple examples are: * authentication, can I prove who I am and that I have the authority to request this service? * non-repudiation, can you prove it was really me so you can counter my claim that I never used this service? * charging, who pays for traffic in the non-symmetric data world where the web server is the 'source' and the client is the 'sink' for data streams. * cross domain charging, how do service providers pass charges to each other and finally back to the customer. * equipment requirements, how much will equipment (switches/routers, computers) cost when they need to keep track of all the accounting information. I am not trying to say that any one of these issues is expensive by itself, but that the combination of all the components needed to build a workable global QoS Internet must be addressed. Only then can a fair comparison be made to determine what the best answer is. Looking at the total picture, I begin to view the technical solution of just throwing more packet forwarding capability (faster switches/router, links, DWDM muxes, etc.) as very attractive. The costs for the technology will only come down. Indead, look at the new terabit routers now being worked on, wire speed forwarding engines at gigabit speeds in campus switch/routers, and optical networks using NxOC-192 DWDMs. All of these technologies tend to decrease in price as time increases. In contrast, who knows what the administrative costs will be and how they will change over time? Building a high quality Internet will not be an easy task. Right now I think it is to early to tell if technological growth or administrative constraint is the solution to this interesting problem. Rich Raghu V.V.J Vadapalli wrote: > > Dear All, > > I have one basic question regarding QoS routing. > > Do we need QoS routing if we have enough infinite (I mean > large ) bandwidth. > > From my poor knowledge: > > We need QoS routing b'cos we have limited BW and we want > to give priority to QoS flows. If some one comes with > a Tx system which supports 100s Gb/s,(say 128 channel WDM system) > Do we need to support the "special" status for the QoS flows. > May in that case the memory at the routers will be > bottleneck. > > Am I missing something. > With Regards > -Raghu. ------------------------------------ Richard A. Carlson email: carlson@sunvideo.er.doe.gov US Dept of Energy ER-31 Phone: (301) 903-0073 19901 Germantown Rd Fax: (301) 903-7774 Germantown, MD 20874 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 14:34:12 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id OAA15517 for ipng-dist; Mon, 21 Dec 1998 14:23:56 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id OAA15510 for ; Mon, 21 Dec 1998 14:23:51 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with ESMTP id OAA11800 for ; Mon, 21 Dec 1998 14:24:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id OAA07159 for ipng@sunroof.eng.sun.com; Mon, 21 Dec 1998 14:23:17 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id NAA15227 for ; Mon, 21 Dec 1998 13:26: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 NAA15516 for ; Mon, 21 Dec 1998 13:26:06 -0800 Received: from mlsrv1.avici.com ([208.153.76.9]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA22337 for ; Mon, 21 Dec 1998 13:26:07 -0800 (PST) Received: from bohara-pc (bohara-pc.avici.com [10.1.3.36]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id QAA05012; Mon, 21 Dec 1998 16:12:44 -0500 (EST) Message-Id: <199812212112.QAA05012@mlsrv1.avici.com> X-Sender: bohara@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 21 Dec 1998 16:06:31 -0500 To: MultiProtocol Label Switching From: "Bob O'Hara" Subject: (IPng 6945) Re: Reg: Quality of Service routing Cc: routing quality , Internet Protocol In-Reply-To: <3.0.2.32.19981221131004.006dc4e8@achilles.ctd.anl.gov> References: <367D1A93.D06C0B54@dnrc.bell-labs.com> <19981220150534.13933.rocketmail@send103.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id NAA15228 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu, I must disagree. While the idea of infinite bandwidth is alluring and may seem to provide an answer, it does not. I am highly skeptical that we will ever reach a point where bandwidth will become so cheap and so plentiful that it will eliminate all congestion. I think that history has proved to us that larger pipes are always consumed by new generations of more demanding applications. The trend will no doubt continue. Therefore, it is safe to state that bandwidth will NOT eliminate the need for QOS. Likewise, QOS does not create bandwidth. Instead, QOS provides the essential control mechanism for the provision and guarantee of bandwidth to applications with hard requirements. Because the internet is a shared resource by design, software and hardware will have to provide a very large number of identifiers and queues to deliver on tommorrows applications. There are many common points of convergence in the internet and thousands, someday millions of streams of data will have to be negotiated through a single point while providing a specific quality of service to each flow. Bandwidth alone, cannot solve that problem. Thanks, Bob At 01:10 PM 12/21/98 -0600, Richard Carlson wrote: >Raghu; > >This is a very interesting and important question that I don't think gets >the attention it deserves.  As has been pointed out in other replies to >your question, the cost of providing 'enough' forwarding capabilities >(switch/routers, link BW, etc) to prevent packet queuing will be high.  The >unstated (and I believe suspect) assumption is that the cost of providing >QoS mechanisms will be lower.  I don't think enough research has been done >to identify and classify the real costs of deploying a QoS based Internet. > >By real costs I mean those charges that are required to build a workable >global system.  Some simple examples are: > >* authentication, can I prove who I am and that I have the authority to >request this service? > >* non-repudiation, can you prove it was really me so you can counter my >claim that I never used this service? > >* charging, who pays for traffic in the non-symmetric data world where the >web server is the 'source' and the client is the 'sink' for data streams. > >* cross domain charging, how do service providers pass charges to each >other and finally back to the customer. > >* equipment requirements, how much will equipment (switches/routers, >computers) cost when they need to keep track of all the accounting >information. > >I am not trying to say that any one of these issues is expensive by itself, >but that the combination of all the components needed to build a workable >global QoS Internet must be addressed.  Only then can a fair comparison be >made to determine what the best answer is. > >Looking at the total picture, I begin to view the technical solution of >just throwing more packet forwarding capability (faster switches/router, >links, DWDM muxes, etc.) as very attractive.  The costs for the technology >will only come down.  Indead, look at the new terabit routers now being >worked on, wire speed forwarding engines at gigabit speeds in campus >switch/routers, and optical networks using NxOC-192 DWDMs.  All of these >technologies tend to decrease in price as time increases.  In contrast, who >knows what the administrative costs will be and how they will change over >time? > >Building a high quality Internet will not be an easy task.  Right now I >think it is to early to tell if technological growth or administrative >constraint is the solution to this interesting problem. > >Rich > >Raghu V.V.J Vadapalli wrote: >> >> Dear All, >> >> I have one basic question regarding QoS routing. >> >> Do we need QoS routing if we have enough infinite (I mean >> large ) bandwidth. >> >> From my poor knowledge: >> >> We need QoS routing b'cos we have limited BW and we want >> to give priority to QoS flows. If some one comes with >> a Tx system which supports 100s Gb/s,(say 128 channel WDM system) >> Do we need to support the "special"  status for the QoS flows. >> May in that case the memory at the routers will be >> bottleneck. >> >> Am I missing something. >> With Regards >> -Raghu. >------------------------------------ > >Richard A. Carlson email: carlson@sunvideo.er.doe.gov >US Dept of Energy ER-31      Phone: (301) 903-0073 >19901 Germantown Rd Fax:   (301) 903-7774 >Germantown, MD 20874 > Robert C. O'Hara - Corporate Systems Engineer/Customer Services Avici Systems, Inc. 101 Billerica Avenue North Billerica, Massachusetts 01862 Contact Information Tel: 978-964-2053 Fax:  978-964-2100  Cellular: 617-803-7371  Cellular text message: 6178037371@mobile.att.net email: bohara@avici.com web: http://www.avici.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 Dec 21 14:51:49 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id OAA15582 for ipng-dist; Mon, 21 Dec 1998 14:41:55 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id OAA15575 for ; Mon, 21 Dec 1998 14:41: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 OAA25980 for ; Mon, 21 Dec 1998 14:41:44 -0800 Received: from ezymail.ezymail.com ([203.61.203.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA07652 for ; Mon, 21 Dec 1998 14:41:40 -0800 (PST) Received: from csl-ws000000 ([203.108.28.186]) by ezymail.ezymail.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 1-666L) with SMTP id AAA213 for ; Tue, 22 Dec 1998 08:45:19 +1000 Reply-To: From: "Mitch Denny" To: "IPNG List" Subject: (IPng 6946) Re: An simple idea thrown into the air. Date: Tue, 22 Dec 1998 09:41:56 +1000 Message-ID: <001201be2d3b$7eae11d0$ee4f000a@csl-ws000000.resource.bm.mel.au.csl.com> 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-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <367E3675.3D896A95@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ye All, A few people have suggested that I posted comments which advocated changing the IPv6 model at this late stage of development. I would just like to refer those people to my first post to this list where I made this comments to Myron Szymanskyj. > I think the arguement is when do you > stop adding bits :) Currently > they are using 128bit addresses which > provides a substansial yield. This would suggest that I am in favour of the current model no? > Perhaps what they should look at is a > 16bit part (or less) section in the header > that can be used to define the size > of the address space, and routers can > inteligently handle each packet. Now this is were it gets a little sticky, it sounds like I am saying that we modify the current model. I guess the point is that people should read a message to the end before hitting the reply button and flaming me. The following paragraph finializes the statement. > Now that IPv6 is basically agreed upon > (am I wrong?) I think we will have to > wait for IPvX for that facility, and even > then it may be deemed to computationally > intensive for routers to handle and > still maintain speed. Not to mention > other problems that may arrise. Here I say that even if we could implement variable length address fields it may be computationally intensive, I also make quite clear that I am not refering to IPv6 when I make these comments. I realise that most of you did not reply to my original message, many may have not even read it. This is for those of you who read later comments out of context and therefor did not fully understand me view on the matter. So to sum up, I believe IPv6 is great, I also believe that we will eventually exhaust the address space, however I believe that we do not need to think of it now because down the track we will want to build in extra features to the protocol which will require it to be redesigned. Variable length addresses was one point I put forward for a future specificaion, howeve I do recognise the obvious problems with this, for example expensive computations on routers to handle it, and the mind bender of routing addresses of variable lengths into networks with different size addresses. I hope this clears up my point of view that confused myself with Myron Szymanskyj who suggested adding an additional bit to the address space/ or header which I personally thought was pointless at this late stage. Cheers, Mitch Denny warbyte@ezymail.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 Dec 21 15:15:46 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id PAA15666 for ipng-dist; Mon, 21 Dec 1998 15:02:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id PAA15659 for ; Mon, 21 Dec 1998 15:02: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 PAA22058 for ; Mon, 21 Dec 1998 15:02:40 -0800 Received: from alphatje.NL.net (alphatje.NL.net [193.78.240.11]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA19796 for ; Mon, 21 Dec 1998 15:02:41 -0800 (PST) Received: from db52-7.Den-Bosch.NL.net ([212.206.201.8]:4135 "HELO acnllelo" ident: "NO-IDENT-SERVICE[2]") by alphatje.NL.net with SMTP id <232274-4657>; Tue, 22 Dec 1998 00:01:37 +0100 Received: by localhost with Microsoft MAPI; Tue, 22 Dec 1998 00:02:22 +0100 Message-ID: <01BE2D3E.5957C860.e.lopes.cardozo@aranea.nl> From: Ernst Lopes Cardozo To: Internet Protocol Subject: (IPng 6947) Quality of Service (rather long) Date: Tue, 22 Dec 1998 00:02:20 +0100 Organization: Aranea Consult BV X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 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, QoS and all that - let me try to chip in my 0.009 Euro (that will be about US$ 0.02). After reading RFC 2460 I got the feeling we are moving backward: Priority turned Traffic Type with no apparent semantics and Flow ID is now a field who's usage is being studied. It seems QoS is a hard nut to crack. Why is that? Firstly, defining the problem seems very difficult. It is about economics - but the relative costs of things like bandwidth, processing/routing power, as well as the business model for the networks are all changing violently. If the network is lightly loaded (say < 20%), a very coarse priority system would probably suffice to provide acceptable behavior for all applications. On the other hand, if we would have a very intelligent QoS system, we might be able to load the network up to 80%. This means the value of a 'very intelligent QoS system' over a coarse priority system is a factor 4 in transmission costs. Transmission costs are decreasing at a fantastic rate; a lot faster, it seems, than routing/switching costs. Soon only the very long haul links may be expensive enough to warrant a 'very intelligent QoS system'. [I think we already see the same effect in local and campus networks, where bandwidth is too cheap to make ATM really viable.] Scaling. With the increase of transmission *speed*, applications that were difficult yesterday will be easy tomorrow. Today, a histogram of pings from The Netherlands to the US shows an average roundtrip of 320 ms, with a spread of about 70 ms (and up to 5% timeouts). If in 12 month time every link in the network would have 10 times today's speed, a ping histogram would show about 77 ms average with a spread of 8 ms. In each case, about 50 ms of the total delay is propagation delay. That means that the queuing, routing and packetization delay would be less than the propagation delay - even for a priority-less network as today's Internet! This, of course, will not happen. The main reason it will not happen is that, with the increase of the network speed, the relative load on the network will increase. In fact, I firmly believe that today's Internet follows a Rule of Constant Network Delay. Let me explain. For a large number of users and usage's, the Internet has a constant cost. If a user sits down for a surfing session, there is no real economic feedback that determines whether he clicks another link, pulls another clip, etc. Far more important is his waiting time. Sometimes, it takes 15 minutes to consume the first megabyte, at other moments he may have pulled ten times as much in the same amount of time. So the response time of the network has a large influence on the amount of bits a user pulls through the net. This constitutes a feedback loop that insures that the net is always filled up to the point where we start complaining. What else can explain that the often predicted meltdown has never occurred and that, despite huge and sudden increments in capacity, the net seems to be about as slow as it was a year ago, and two years ago, etc. [From measurements using fixed-size transfers it has been reported that the net has gained 60% in speed over the last two years. This is not in contradiction to the above: in the two years, the average transfer (webpage) has increased 60% in size, so the network had to become faster to yield the same apparent response time for the users: yes, the net grows faster when the applications grow fatter!] Back to priority. Actually, 'priority' seems to imply 'importance'. This is not always what we need. A voice packet is not more 'important' than a ftp segment, the voice packet just has to be delivered within a bounded time. While the ftp user actually gains from having his packets delivered faster, the voice listener has but one desire: to receive the packet before it is too late. A truly 'very intelligent QoS system' would sort it's queues based on the 'urgend-ness' of each packet. A voice packet that still has 10 ms time and is almost at its destination might be queued behind an ftp packet. In practice, this is probably very difficult. It would mean time stamping voice-like (real-time) packets and routers would need an estimate of the remaining travel time for each destination. Synchronizing clocks down to milliseconds in a large network is tricky. For some other traffic types we may want to implement 'importance'. Let's look at an Intranet. Some users are running transaction-type applications. The amount of traffic they generate depends on the number of invoices, orders, etc. that need to be process, which in turn depends of the business. If the network is slow, the users and hence the business waist time waiting for the network. Telling these users to slow down to relieve the networks is hardly an option. Some other users are using more 'optional' type applications. They are browsing the intranet servers, looking a the CEO's last peptalk, reading the latest company press releases, etc. While each of these applications is useful in itself, the company would probably rather slow down these users than their transaction-processing colleagues. Here 'importance' seems to be the factor that should steer the queuing algorithm. Actually, we may even want to give the browsing user a busy-tone at times: "sorry, the network is currently to busy, please try later". Another angle: the cost of QoS. When the ATM folks started to implement QoS, it seems they had the average telephone call in mind: 4 minutes in Europe, 6 minutes in the US. Now I try to imagine how a QoS-enabled network deals with a simple HTTP session. The DNS queries are clearly too short to set up and tear down a connection, let alone a QoS routed session. Then the browser pulls a page from the web server: 15k text and scripts, 7 figures ranging from 400 bytes to 70k, 30 seconds background sound (streaming, of course). The next mouse click starts a 100 second video clip. Frankly, I don't see how a network could give each of these sessions is own QoS treatment. The signaling necessary would be a multiple of the application traffic and the "call processing" capacity in the network would be enormous. Does anybody have a figure for the average duration (or number of bytes) of TCP sessions in the Internet? Remember, once we have that 1 Mb local loop, downloading a page will be a matter of milliseconds... Today, interactive voice seems the most delay-sensitive large-scale application; in the future, we may have applications that require 'tactile feedback' over the net, bringing the delay requirement down by another order of magnitude. Whether that will require very special handling or just a little help at the queues is anybody's guess. Conclusion: we should look for a structure that allows fairly simple, localized prioritization with room for extensions. Choosing a QoS scheme that will carry us for years seems a big gamble. Ernst Lopes Cardozo Tel. +31-(0)73-646.1660 Aranea Consult e.lopes.cardozo@aranea.nl Principal Consultant http://www.aranea.nl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 16:12:29 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id QAA15709 for ipng-dist; Mon, 21 Dec 1998 16:01:33 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id QAA15702 for ; Mon, 21 Dec 1998 16:01: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 QAA20278 for ; Mon, 21 Dec 1998 16:01:19 -0800 Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA20517 for ; Mon, 21 Dec 1998 16:01:12 -0800 (PST) Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.1/8.9.1) with SMTP id TAA21374 for ; Mon, 21 Dec 1998 19:01:40 -0500 (EST) Date: Mon, 21 Dec 1998 19:01:40 -0500 (EST) From: "John F. Leser" Reply-To: "John F. Leser" To: ipng@sunroof.eng.sun.com Subject: (IPng 6948) Re: An simple idea thrown into the air. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Unless I'm mistaken, wouldn't it be possible to extend the address space of IPv6 as much as need by using IPv6 in IPv6 encapsulation? This would allow an entire V6 address space to be accessed through one 'top level' address. The only limit to encapsulation is MTU, so the capability for expansion is essentially infinite, since a linear growth in MTU increases address space exponentially. This would be an effective answer to the "many addresses at one host/small site" issue that some are raising. ***************************************************************** John Leser InterOperability Lab IP/Routing Consortium Engineer University of New Hampshire 7 Leavitt Lane, Room 106 Tel: (603) 862-0090 Durham, NH 03824-3525 Fax: (603) 862-4181 Email: jfl@iol.unh.edu Web: http://www.iol.unh.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 21 16:23:57 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id QAA15733 for ipng-dist; Mon, 21 Dec 1998 16:12:51 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id QAA15720 for ; Mon, 21 Dec 1998 16:12:39 -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 QAA11540 for ; Mon, 21 Dec 1998 16:12:38 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA25727 for ; Mon, 21 Dec 1998 16:12:38 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA29925; Mon, 21 Dec 1998 16:12:37 -0800 (PST) Message-Id: <3.0.5.32.19981221161211.00921a00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 21 Dec 1998 16:12:11 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6949) W.G. Last Call on "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an IPng working group last call for comments on advancing the following document as an Informational RFC: Title : Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 Author(s) : M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang Filename : draft-ietf-ipngwg-esd-analysis-03.txt Pages : 50 Date : 20-Nov-98 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on January 4, 1999. 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 Dec 21 16:26:55 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) id QAA15763 for ipng-dist; Mon, 21 Dec 1998 16:22:59 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta3+Sun/8.9.2.Beta3) with SMTP id QAA15756 for ; Mon, 21 Dec 1998 16:22: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 QAA12533 for ; Mon, 21 Dec 1998 16:22:48 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA00017 for ; Mon, 21 Dec 1998 16:22:49 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA00387; Mon, 21 Dec 1998 16:22:48 -0800 (PST) Message-Id: <3.0.5.32.19981221162221.00922e90@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 21 Dec 1998 16:22:21 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6950) W.G. Last Call on IPv6 Addressing Specifications for Draft Standard 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 two IPv6 addressing specifications as a Draft Standards: RFC2373 IP Version 6 Addressing Architecture RFC2374 An Aggregatable Global Unicast Address Format An implementation report for these RFC's is available at: ftp://playground.sun.com/pub/ipng/implementation-reports as: add-arch-aggregat.txt 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 January 4, 1999. 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 Dec 22 03:08:27 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id DAA16382 for ipng-dist; Tue, 22 Dec 1998 03:03:55 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id DAA16375 for ; Tue, 22 Dec 1998 03:03: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 DAA19275 for ; Tue, 22 Dec 1998 03:03:41 -0800 Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA11221 for ; Tue, 22 Dec 1998 03:03:40 -0800 (PST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA25276; Tue, 22 Dec 1998 11:03:37 GMT Received: from hursley.ibm.com (9-20-31-131.dhcp.hursley.ibm.com [9.20.31.131]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA19744; Tue, 22 Dec 1998 11:03:36 GMT Message-ID: <367F7C52.9CD24121@hursley.ibm.com> Date: Tue, 22 Dec 1998 11:02:42 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Ernst Lopes Cardozo CC: Internet Protocol Subject: (IPng 6951) Re: Quality of Service (rather long) References: <01BE2D3E.5957C860.e.lopes.cardozo@aranea.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ernst, The Traffic Class field is defined by the Differentiated Services working group. See RFC 2474 and 2475. The sort of issues you raise are extensively discussed in that working group and in the various groups associated with Integrated Services and RSVP. They are largely independent of IPv4 versus IPv6. It's a matter of fact that more work is needed on the Flow ID field, although some people will tell you that they know how to use it today. Brian Carpenter (Co-chair, diffserv WG) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 22 07:32:14 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id HAA16589 for ipng-dist; Tue, 22 Dec 1998 07:24:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id HAA16582 for ; Tue, 22 Dec 1998 07:24:12 -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 HAA01383 for ; Tue, 22 Dec 1998 07:24:11 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA15156 for ; Tue, 22 Dec 1998 07:24:11 -0800 (PST) Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id KAA02704; Tue, 22 Dec 1998 10:24:10 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA28720; Tue, 22 Dec 1998 10:24:07 -0500 Message-Id: <199812221524.AA28720@quarry.zk3.dec.com> To: Brian E Carpenter Cc: Ernst Lopes Cardozo , Internet Protocol Subject: (IPng 6952) Re: Quality of Service (rather long) In-Reply-To: Your message of "Tue, 22 Dec 1998 11:02:42 GMT." <367F7C52.9CD24121@hursley.ibm.com> Date: Tue, 22 Dec 1998 10:24:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >It's a matter of fact that more work is needed on the Flow ID field, >although some people will tell you that they know how to use it >today. For sure. We can use it today for RSVP per the flowspec and it works fine as long as it is enclosed by an Intranet. Folks Intranets using RSVP for IPv4 work like a champ and with IPv6 even better because of the flow ID. Yes it is being used. /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 Dec 22 08:29:44 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id IAA16661 for ipng-dist; Tue, 22 Dec 1998 08:21:15 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id IAA16654 for ; Tue, 22 Dec 1998 08:21: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 IAA29818 for ; Tue, 22 Dec 1998 08:21:07 -0800 Received: from theoryx (theoryx.cs.uni-bonn.de [131.220.4.211]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA15635 for ; Tue, 22 Dec 1998 08:20:57 -0800 (PST) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theoryx (8.9.1a/8.9.1) with ESMTP id RAA13112; Tue, 22 Dec 1998 17:20:20 +0100 (MET) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id RAA16256; Tue, 22 Dec 1998 17:20:19 +0100 (MET) Message-ID: <19981222172019.B16200@cs.uni-bonn.de> Date: Tue, 22 Dec 1998 17:20:19 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Cc: Thomas Narten Subject: (IPng 6953) ARCnet draft: new version available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, a new version of the ARCnet draft has been available for a few days as http://search.ietf.org/internet-drafts/draft-souvatzis-ipv6-arcnet-05.txt There is a major change: SMC assigned a seperate System Code (what we would call protocol id) to IPv6, and I've made the necessary changes (several people suggested this). Also, the requirements wrt. MTU handling have been clarified (suggested by Thomas Narten). [These changes were suggested during the last call period.] As an editing change, I've inserted the recently assigned RFC numbers, instead of referencing the Internet Drafts, and fixed a typo (ARCIP4->ARCIPV4). Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 22 10:49:59 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id KAA16809 for ipng-dist; Tue, 22 Dec 1998 10:38:04 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id KAA16802 for ; Tue, 22 Dec 1998 10:37: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 KAA09261 for ; Tue, 22 Dec 1998 10:37:55 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA13186 for ; Tue, 22 Dec 1998 10:37:54 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id KAA23570; Tue, 22 Dec 1998 10:36:13 -0800 (PST) Message-Id: <3.0.5.32.19981222103544.00993de0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 22 Dec 1998 10:35:44 -0800 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: (IPng 6954) Request to Advance "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" 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, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Author(s) : B. Carpenter, C. Jung Filename : draft-ietf-ipngwg-6over4-01.txt Pages : 9 Date : December 1998 A working group last call for this document was completed on November 16, 1998. The current draft reflects comments received during the last call. 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 Tue Dec 22 12:35:10 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id MAA16960 for ipng-dist; Tue, 22 Dec 1998 12:25:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id MAA16953 for ; Tue, 22 Dec 1998 12:25: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 MAA16867 for ; Tue, 22 Dec 1998 12:25:02 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA19084 for ; Tue, 22 Dec 1998 12:25:01 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA20012; Tue, 22 Dec 1998 15:24:46 -0500 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 PAA31668; Tue, 22 Dec 1998 15:24:49 -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 PAA18740; Tue, 22 Dec 1998 15:24:48 -0500 (EST) Message-Id: <199812222024.PAA18740@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: Bob Hinden cc: Jeffrey Burgan , deering@cisco.com, dbj@cs.cmu.edu, ipng@sunroof.eng.sun.com Subject: (IPng 6955) Re: Request to Advance "Reserved IPv6 Subnet Anycast Addresses" In-reply-to: Your message of "Mon, 09 Nov 1998 10:30:14 PST." <3.0.5.32.19981109103014.00a1f620@mailhost.iprg.nokia.com> Date: Tue, 22 Dec 1998 15:24:48 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Title : Reserved IPv6 Subnet Anycast Addresses > Author(s) : D. Johnson, S. Deering > Filename : draft-ietf-ipngwg-resv-anycast-01.txt > Pages : 5 > Date : 19-Oct-98 Couple of things, one minor, one maybe not. > 5. IANA Considerations > > This document defines a set of reserved subnet anycast addresses, > based on a set of anycast identifiers within each subnet prefix > in the IPv6 unicast address space. As future needs arise, new > anycast identifiers may be defined. Such anycast identifiers MUST be > reserved within all subnet prefixes, and so the assignment of these > anycast identifiers requires centralized administration. New values > SHOULD be assigned in descending numerical order and are expected to > be assigned only with IESG approval. how about adding "as defined in [RFC 2434]" to the end of the last sentence to tie it with what I assume is the intended definition of "IESG Approval". Actually, is "IESG Approval" really the policy what the WG wants to select? This allows one to assign anycast addresses without there even being an RFC describing its use. Seems like "IETF Consensus" or "Standards Action" might be more appropriate. Also, MUST/MAY/SHOULD language is used without definition. (Suggestion: reference rfc 2119). 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 Dec 22 13:21:54 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA17047 for ipng-dist; Tue, 22 Dec 1998 13:11:51 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA17040 for ; Tue, 22 Dec 1998 13:11: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 NAA29381 for ; Tue, 22 Dec 1998 13:11:41 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA18382 for ; Tue, 22 Dec 1998 13:11:38 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA28931; Tue, 22 Dec 1998 13:10:29 -0800 (PST) Message-Id: <3.0.5.32.19981222131000.009f5590@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 22 Dec 1998 13:10:00 -0800 To: Thomas Narten From: Bob Hinden Subject: (IPng 6956) Re: Request to Advance "Reserved IPv6 Subnet Anycast Addresses" Cc: Bob Hinden , Jeffrey Burgan , deering@cisco.com, dbj@cs.cmu.edu, ipng@sunroof.eng.sun.com In-Reply-To: <199812222024.PAA18740@cichlid.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I think the authors are on holiday so I will answer. >> 5. IANA Considerations >> >> This document defines a set of reserved subnet anycast addresses, >> based on a set of anycast identifiers within each subnet prefix >> in the IPv6 unicast address space. As future needs arise, new >> anycast identifiers may be defined. Such anycast identifiers MUST be >> reserved within all subnet prefixes, and so the assignment of these >> anycast identifiers requires centralized administration. New values >> SHOULD be assigned in descending numerical order and are expected to >> be assigned only with IESG approval. > >how about adding "as defined in [RFC 2434]" to the end of the last >sentence to tie it with what I assume is the intended definition of >"IESG Approval". > >Actually, is "IESG Approval" really the policy what the WG wants to >select? This allows one to assign anycast addresses without there >even being an RFC describing its use. Seems like "IETF Consensus" or >"Standards Action" might be more appropriate. I don't think we want to require that these can only be assigned to standards track protocols (i.e., an experimental protocol should also be OK) but agree the protocol should be documented. How about something like the following: New values SHOULD be assigned in descending numerical order and SHOULD be assigned in conjunction with the publication of an RFC defining the protocol using the assignment. >Also, MUST/MAY/SHOULD language is used without definition. >(Suggestion: reference rfc 2119). Yes, this should be added as well. I assume that these changes can be made after the IESG last call is completed. 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 Tue Dec 22 13:33:04 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA17126 for ipng-dist; Tue, 22 Dec 1998 13:29:53 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA17119 for ; Tue, 22 Dec 1998 13:29: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 NAA12197 for ; Tue, 22 Dec 1998 13:29:42 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA00397 for ; Tue, 22 Dec 1998 13:29:40 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08462; Tue, 22 Dec 1998 16:29:33 -0500 (EST) Message-Id: <199812222129.QAA08462@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6959) I-D ACTION:draft-ietf-ipngwg-6over4-01.txt Date: Tue, 22 Dec 1998 16:29:33 -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 : Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Author(s) : B. Carpenter, C. Jung Filename : draft-ietf-ipngwg-6over4-01.txt Pages : 9 Date : 16-Dec-98 This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a 'virtual Ethernet.' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-6over4-01.txt Internet-Drafts are also 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-6over4-01.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org 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-6over4-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: <19981222143705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-6over4-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-6over4-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981222143705.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 Dec 22 13:33:17 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA17086 for ipng-dist; Tue, 22 Dec 1998 13:22:15 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA17078 for ; Tue, 22 Dec 1998 13:21: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 NAA11381 for ; Tue, 22 Dec 1998 13:21:55 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA25074 for ; Tue, 22 Dec 1998 13:21:54 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA34410; Tue, 22 Dec 1998 16:21:38 -0500 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 QAA28654; Tue, 22 Dec 1998 16:21:41 -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 QAA15520; Tue, 22 Dec 1998 16:21:40 -0500 (EST) Message-Id: <199812222121.QAA15520@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: Bob Hinden cc: Jeffrey Burgan , deering@cisco.com, dbj@cs.cmu.edu, ipng@sunroof.eng.sun.com Subject: (IPng 6957) Re: Request to Advance "Reserved IPv6 Subnet Anycast Addresses" In-reply-to: Your message of "Tue, 22 Dec 1998 13:10:00 PST." <3.0.5.32.19981222131000.009f5590@mailhost.iprg.nokia.com> Date: Tue, 22 Dec 1998 16:21:40 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't think we want to require that these can only be assigned to > standards track protocols (i.e., an experimental protocol should also be > OK) but agree the protocol should be documented. How about something like > the following: > New values SHOULD be assigned in descending numerical order and SHOULD > be assigned in conjunction with the publication of an RFC defining the > protocol using the assignment. The "politically correct" way of stating this is to say something like: New values SHOULD be assigned in descending numerical order and are to be assigned according to IETF Consensus as defined in [RFC 2434]. (i.e., 2434 has a list of common IANA recipes one can choose from) > I assume that these changes can be made after the IESG last call is > completed. Yep. 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 Dec 22 13:33:11 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA17108 for ipng-dist; Tue, 22 Dec 1998 13:26:05 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA17101 for ; Tue, 22 Dec 1998 13:25:39 -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 NAA11776 for ; Tue, 22 Dec 1998 13:25:39 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA27581 for ; Tue, 22 Dec 1998 13:25:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08225; Tue, 22 Dec 1998 16:25:29 -0500 (EST) Message-Id: <199812222125.QAA08225@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6958) I-D ACTION:draft-ietf-ipngwg-dns-lookups-03.txt Date: Tue, 22 Dec 1998 16:25:29 -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 Extensions to Support IP Version 6 Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-03.txt Pages : 15 Date : 16-Dec-98 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering, and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new domain to hold the top-level delegation information and a zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-03.txt Internet-Drafts are also 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-03.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org 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-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: <19981222144200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981222144200.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 Dec 22 13:34:38 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA17145 for ipng-dist; Tue, 22 Dec 1998 13:32:15 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA17134 for ; Tue, 22 Dec 1998 13:32: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 NAA12434 for ; Tue, 22 Dec 1998 13:32:00 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA01853 for ; Tue, 22 Dec 1998 13:31:53 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08839; Tue, 22 Dec 1998 16:31:47 -0500 (EST) Message-Id: <199812222131.QAA08839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6960) I-D ACTION:draft-souvatzis-ipv6-arcnet-05.txt Date: Tue, 22 Dec 1998 16:31:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. 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 : Transmission of IPv6 Packets over ARCnet Networks Author(s) : I. Souvatzis Filename : draft-souvatzis-ipv6-arcnet-05.txt Pages : 6 Date : 16-Dec-98 This memo specifies a frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in [DISC], when those messages are transmitted on an ARCnet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-souvatzis-ipv6-arcnet-05.txt Internet-Drafts are also 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-souvatzis-ipv6-arcnet-05.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org 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-souvatzis-ipv6-arcnet-05.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: <19981222150224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-souvatzis-ipv6-arcnet-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-souvatzis-ipv6-arcnet-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981222150224.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 Dec 22 14:02:38 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA17387 for ipng-dist; Tue, 22 Dec 1998 13:55:22 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA17380 for ; Tue, 22 Dec 1998 13:55:11 -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 NAA09991 for ; Tue, 22 Dec 1998 13:55:09 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA15832 for ; Tue, 22 Dec 1998 13:55:09 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10037; Tue, 22 Dec 1998 16:55:00 -0500 (EST) Message-Id: <199812222155.QAA10037@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6962) I-D ACTION:draft-ietf-ipngwg-iana-tla-01.txt Date: Tue, 22 Dec 1998 16:55:00 -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 : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-01.txt Pages : 5 Date : 17-Dec-98 This document proposes initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries and continued management of the IP6.INT domain. It is intended as technical input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. It is not intended for any official IETF status. The IAB and IESG have authorized the Internet Assigned Numbers Authority (IANA) as the appropriate entity to have the responsibility for the management of the IPv6 address space as defined in [ALLOC]. The proposed initial assignment described in the document is consistent with: - RFC 2373,'IP Version 6 Addressing Architecture' [ARCH] - RFC 2374 'An Aggregatable Global Unicast Address Format' [AGGR] - RFC 2450 'Proposed TLA and NLA Assignment Rules' [TLA-RULES] The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC 2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-01.txt Internet-Drafts are also 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-iana-tla-01.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org 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-iana-tla-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: <19981222151243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iana-tla-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981222151243.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 Dec 22 14:02:38 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA17378 for ipng-dist; Tue, 22 Dec 1998 13:53:17 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA17371 for ; Tue, 22 Dec 1998 13:53:05 -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 NAA15063 for ; Tue, 22 Dec 1998 13:53:05 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA14426 for ; Tue, 22 Dec 1998 13:53:04 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA01229; Tue, 22 Dec 1998 13:51:50 -0800 (PST) Message-Id: <3.0.5.32.19981222134931.009f78f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 22 Dec 1998 13:49:31 -0800 To: Thomas Narten From: Bob Hinden Subject: (IPng 6961) Re: Request to Advance "Reserved IPv6 Subnet Anycast Addresses" Cc: Bob Hinden , Jeffrey Burgan , deering@cisco.com, dbj@cs.cmu.edu, ipng@sunroof.eng.sun.com In-Reply-To: <199812222121.QAA15520@cichlid.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >The "politically correct" way of stating this is to say something >like: > > New values SHOULD be assigned in descending numerical order and > are to be assigned according to IETF Consensus as defined in [RFC > 2434]. > >(i.e., 2434 has a list of common IANA recipes one can choose from) Yes, I agree. 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 Tue Dec 22 14:22:07 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id OAA17497 for ipng-dist; Tue, 22 Dec 1998 14:12:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id OAA17490 for ; Tue, 22 Dec 1998 14:11:59 -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 OAA02157 for ; Tue, 22 Dec 1998 14:11:57 -0800 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA26079 for ; Tue, 22 Dec 1998 14:11:57 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 22 Dec 1998 14:11:51 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF819A1@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 6963) IPV6_MULTICAST_HOPS Date: Tue, 22 Dec 1998 14:11:50 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a couple interpretation questions regarding IPV6_MULTICAST_HOPS in draft-ietf-ipngwg-bsd-api-new-04.txt. The draft says The interpretation of the argument is the same as for the IPV6_UNICAST_HOPS option: x < -1: return an error of EINVAL x == -1: use kernel default 0 <= x <= 255: use x x >= 256: return an error of EINVAL If IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 today) 1. The draft says that if the application specifies x == -1, then the "kernel default" should be used. Is the kernel default 1 or is the kernel default perhaps something else (eg the hop limit value learned from RAs)? I would assume the latter since the application could specify the former directly. 2. (This also applies to IPV6_UNICAST_HOPS.) If the application specifies x == 0, what should happen? Normally packets with a Hop Limit of zero are discarded. RFC 1122 (for IPv4) says that hosts MUST NOT send a packet with a TTL of zero. Does this rule hold for v6? Perhaps if an application specifies x == 0, then only loopback should be allowed and the packet should not be put out on a link? 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 Dec 22 14:40:44 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id OAA17592 for ipng-dist; Tue, 22 Dec 1998 14:31:57 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id OAA17582 for ; Tue, 22 Dec 1998 14:31:47 -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 OAA14695 for ; Tue, 22 Dec 1998 14:31:45 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA08259 for ; Tue, 22 Dec 1998 14:31:46 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 22 Dec 1998 14:31:46 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF819A2@RED-MSG-50> From: Richard Draves To: "'IPng List'" Cc: "'Marc Fiuczynski'" Subject: (IPng 6964) route distribution via ND Date: Tue, 22 Dec 1998 14:31:45 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marc Fiuczynski and I came up with a simple idea for distributing routes via Neighbor Discovery. The basic problem we want to solve is letting routers inform hosts about routes. For example, we don't want to manually configure hosts to know that a certain v6 prefix should be routed to Marc's v6-v4 translator. One solution is not to bother with this: let hosts send to a default router, and the default router can redirect as necessary. But the redirect overhead might be undesirable in some environments. My understanding of v4 practice is that hosts will sometimes "snoop" routing protocols like RIP and so learn routes. One can view ND as performing distribution of routes. For example receipt of an RA with a non-zero router lifetime communicates a default route (/0 route). A prefix-information option with the L bit communicates an on-link prefix (a /64 route). Why not define an option to let RAs communicate routes more generally? For example, define a new flag bit (call it the N bit) for prefix information options to say that this prefix should be added to the receiving host's route table, with the router sending the RA as the next-hop for the prefix? This is more desirable than snooping random routing protocols. Hosts must implement ND anyway so there is very little implementation overhead. Some possible problems that have occurred to us: 1. Currently the conceptual data structures are simple - there's no routing table, just an on-link prefix list and a default router list. Answer: simple hosts can ignore these options. They will send to a default router which can redirect. 2. Growth in size of ND messages, upper limit to number of routes that can be communicated in one ND message. Answer: yes, not suitable for super complex topologies. Routers should aggregate and only distribute a few prefixes, if any, this way. 3. Should this be a variation of the prefix information option or separate option? There are only a few flag bits left. And in most scenarios, I don't see the N bit being turned on in conjunction with another bit. So defining a separate option type probably wouldn't hurt. On the other hand, using the prefix information option means it takes very little additional code to support this. Anyway, we've implemented this idea and it's working great for us so far. Is it worth writing up as an I-D? 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 Dec 22 14:52:53 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id OAA17650 for ipng-dist; Tue, 22 Dec 1998 14:43:28 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id OAA17643 for ; Tue, 22 Dec 1998 14:43:14 -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 OAA21675 for ; Tue, 22 Dec 1998 14:43:14 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA14815 for ; Tue, 22 Dec 1998 14:43:13 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id WAA13607; Tue, 22 Dec 1998 22:34:09 GMT Message-Id: <199812222234.WAA13607@inner.net> To: Richard Draves cc: "'IPng List'" Subject: (IPng 6965) Re: IPV6_MULTICAST_HOPS In-reply-to: Your message of "Tue, 22 Dec 1998 14:11:50 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF819A1@RED-MSG-50> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 22 Dec 1998 12:42:19 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D8100AF819A1@RED-MSG-50>, you write: >The draft says > The interpretation of the argument is the same > as for the IPV6_UNICAST_HOPS option: > x < -1: return an error of EINVAL > x == -1: use kernel default > 0 <= x <= 255: use x > x >= 256: return an error of EINVAL > If IPV6_MULTICAST_HOPS is not set, the default is 1 > (same as IPv4 today) > >1. The draft says that if the application specifies x == -1, then the >"kernel default" should be used. Is the kernel default 1 or is the kernel >default perhaps something else (eg the hop limit value learned from RAs)? I >would assume the latter since the application could specify the former >directly. In a "real" BSD, that kernel default might also come from a sysctl variable. In a MS world, it might be a registry entry. The idea is that the system's default should be configurable (e.g., by a sysadmin). Doing it this way also allows you to change the default on a running system and have the change immediately affect applications. (that is the possibly non- obvious difference between specifying -1 if the default is x and specifying x directly) >2. (This also applies to IPV6_UNICAST_HOPS.) If the application specifies x >== 0, what should happen? Normally packets with a Hop Limit of zero are >discarded. RFC 1122 (for IPv4) says that hosts MUST NOT send a packet with a >TTL of zero. Does this rule hold for v6? Perhaps if an application specifies >x == 0, then only loopback should be allowed and the packet should not be >put out on a link? That might be a sensible use for this. I can think of security-oriented applications where I want to guarantee that traffic stays local, even if people are playing games like making the loopback address go somewhere it's not supposed to. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 22 15:11:16 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id PAA17714 for ipng-dist; Tue, 22 Dec 1998 15:02:07 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id PAA17707 for ; Tue, 22 Dec 1998 15:01: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 PAA24537 for ; Tue, 22 Dec 1998 15:01:45 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA26075 for ; Tue, 22 Dec 1998 15:01:43 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id WAA13627; Tue, 22 Dec 1998 22:52:39 GMT Message-Id: <199812222252.WAA13627@inner.net> To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: (IPng 6966) Re: route distribution via ND In-reply-to: Your message of "Tue, 22 Dec 1998 14:31:45 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF819A2@RED-MSG-50> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 22 Dec 1998 13:00:48 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D8100AF819A2@RED-MSG-50>, you write: >One can view ND as performing distribution of routes. For example receipt of >an RA with a non-zero router lifetime communicates a default route (/0 >route). A prefix-information option with the L bit communicates an on-link >prefix (a /64 route). > >Why not define an option to let RAs communicate routes more generally? For >example, define a new flag bit (call it the N bit) for prefix information >options to say that this prefix should be added to the receiving host's >route table, with the router sending the RA as the next-hop for the prefix? Unless I'm highly confused or the specs changed, ND already does this and was intended all along to do this. Advertise a prefix with autonomous off and on-link off. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 22 15:11:30 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id PAA17730 for ipng-dist; Tue, 22 Dec 1998 15:04:41 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id PAA17723 for ; Tue, 22 Dec 1998 15:04: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 PAA20720 for ; Tue, 22 Dec 1998 15:04:28 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA27642 for ; Tue, 22 Dec 1998 15:04:27 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 22 Dec 1998 15:04:26 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF819A3@RED-MSG-50> From: Richard Draves To: "'Craig Metz'" Cc: "'IPng List'" Subject: (IPng 6967) Re: IPV6_MULTICAST_HOPS Date: Tue, 22 Dec 1998 15:04:17 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >The draft says > > The interpretation of the argument is the same > > as for the IPV6_UNICAST_HOPS option: > > x < -1: return an error of EINVAL > > x == -1: use kernel default > > 0 <= x <= 255: use x > > x >= 256: return an error of EINVAL > > If IPV6_MULTICAST_HOPS is not set, the default is 1 > > (same as IPv4 today) > In a "real" BSD, that kernel default might also come from a > sysctl variable. > In a MS world, it might be a registry entry. The idea is that > the system's > default should be configurable (e.g., by a sysadmin). To clarify: my understanding is that if IPV6_MULTICAST_HOPS is not set on a socket, then the Hop Limit in outgoing multicast packets will be 1. If I set IPV6_MULTICAST_HOPS to -1, then then Hop Limit in outgoing multicast packets will be some default value (depending on sysctl in BSD, the registry in NT, and the contents of received RAs - and calculated when the packet is sent, not when IPV6_MULTICAST_HOPS is set to -1) and this default value can be something other than 1. 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 Dec 22 15:52:51 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id PAA17886 for ipng-dist; Tue, 22 Dec 1998 15:44:41 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id PAA17879 for ; Tue, 22 Dec 1998 15:44: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 PAA24195 for ; Tue, 22 Dec 1998 15:44:30 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA19395 for ; Tue, 22 Dec 1998 15:44:29 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id XAA13695; Tue, 22 Dec 1998 23:35:25 GMT Message-Id: <199812222335.XAA13695@inner.net> To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: (IPng 6969) Re: IPV6_MULTICAST_HOPS In-reply-to: Your message of "Tue, 22 Dec 1998 15:04:17 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF819A3@RED-MSG-50> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 22 Dec 1998 13:43:37 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D8100AF819A3@RED-MSG-50>, you write: >To clarify: my understanding is that if IPV6_MULTICAST_HOPS is not set on a >socket, then the Hop Limit in outgoing multicast packets will be 1. I thought that the hop limit is the system (kernel) default, which might or might not be 1. I haven't looked at this part of the API in a couple of years, so I could very well be wrong. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 22 15:53:12 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id PAA17877 for ipng-dist; Tue, 22 Dec 1998 15:43:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id PAA17870 for ; Tue, 22 Dec 1998 15:42: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 PAA18937 for ; Tue, 22 Dec 1998 15:42:38 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA18446 for ; Tue, 22 Dec 1998 15:42:40 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id RAA26956 for ; Tue, 22 Dec 1998 17:42:39 -0600 (CST) Message-Id: <199812222342.RAA26956@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 6968) Re: route distribution via ND In-reply-to: Your message of Tue, 22 Dec 1998 13:00:48 EST. <199812222252.WAA13627@inner.net> Date: Tue, 22 Dec 1998 17:42:39 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Why not define an option to let RAs communicate routes more generally? For > > example, define a new flag bit (call it the N bit) for prefix information > > options to say that this prefix should be added to the receiving host's > > route table, with the router sending the RA as the next-hop for the prefix? I don't think this scales at all, and it doesn't replace the redirect sufficiently. There could be zillions of routes you might want to advertise, and you might want the first-hop router to be chosen based on more factors than just the destination. (E.g., the source address or the traffic class.) > Unless I'm highly confused or the specs changed, ND already does > this and was intended all along to do this. Advertise a prefix with > autonomous off and on-link off. No, no, not at all. See, for exmaple, RFC 2461, page 53: The default behavior (see Section 5.2) when sending a packet to an address for which no information is known about the on-link status of the address is to forward the packet to a default router; the reception of a Prefix Information option with the "on-link " (L) flag set to zero does not change this behavior. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 22 16:19:39 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id QAA17957 for ipng-dist; Tue, 22 Dec 1998 16:06:31 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id QAA17945 for ; Tue, 22 Dec 1998 16:06: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 QAA01252 for ; Tue, 22 Dec 1998 16:06:20 -0800 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA01039 for ; Tue, 22 Dec 1998 16:06:19 -0800 (PST) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Tue, 22 Dec 1998 16:06:18 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF819AA@RED-MSG-50> From: Richard Draves To: ipng@sunroof.eng.sun.com Subject: (IPng 6970) Re: route distribution via ND Date: Tue, 22 Dec 1998 16:06:12 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't think this scales at all, and it doesn't replace the redirect > sufficiently. There could be zillions of routes you might want to > advertise, and you might want the first-hop router to be chosen based > on more factors than just the destination. (E.g., the source address > or the traffic class.) Yes, it does not replace redirect. I was not suggesting eliminating redirect. The idea is that in some common scenarios, redirects can be avoided through a simple mechanism to inform hosts about routes. It will not scale to all environments. In more complex environments redirect can be used. 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 Wed Dec 23 04:47:26 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id EAA18498 for ipng-dist; Wed, 23 Dec 1998 04:36:54 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id EAA18491 for ; Wed, 23 Dec 1998 04:36: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 EAA18414 for ; Wed, 23 Dec 1998 04:36:41 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA01949 for ; Wed, 23 Dec 1998 04:36:41 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA26661; Wed, 23 Dec 1998 07:36:38 -0500 (EST) Message-Id: <199812231236.HAA26661@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6973) Last Call: Reserved IPv6 Subnet Anycast Addresses to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 23 Dec 1998 07:36:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Reserved IPv6 Subnet Anycast Addresses as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 12, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-resv-anycast-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 23 08:04:35 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id HAA18621 for ipng-dist; Wed, 23 Dec 1998 07:58:26 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id HAA18598; Wed, 23 Dec 1998 07:55:33 -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 HAA10710; Wed, 23 Dec 1998 07:55:33 -0800 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA18545; Wed, 23 Dec 1998 07:55:32 -0800 (PST) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id QAA24629; Wed, 23 Dec 1998 16:55:30 +0100 (MET) Message-Id: <199812231555.QAA24629@imag.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 23 Dec 1998 16:54:26 +0100 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@ISI.EDU From: Alain Durand Subject: (IPng 6974) Interim meeting Web server Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I've set up a web server to gather information about the interim meeting in Grenoble http://www.ipv6.imag.fr/ietf1999.html This server is dual stack IPv4 & IPv6, so onecan browse it from the 6bone. It will be updated periodicaly. - 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 Wed Dec 23 08:37:11 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id IAA18652 for ipng-dist; Wed, 23 Dec 1998 08:28:06 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id IAA18645 for ; Wed, 23 Dec 1998 08:27:53 -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 IAA02550 for ; Wed, 23 Dec 1998 08:27:52 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA05845 for ; Wed, 23 Dec 1998 08:27:51 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA01416; Wed, 23 Dec 1998 11:27:46 -0500 (EST) Message-Id: <199812231627.LAA01416@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6975) Last Call: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 23 Dec 1998 11:27:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Transmission of IPv6 over IPv4 Domains without Explicit Tunnels as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 15, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-6over4-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 23 13:53:14 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id NAA18860 for ipng-dist; Wed, 23 Dec 1998 13:42:02 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id NAA18853 for ; Wed, 23 Dec 1998 13:41:53 -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 NAA18492 for ; Wed, 23 Dec 1998 13:41:53 -0800 Received: from send104.yahoomail.com (send104.yahoomail.com [205.180.60.122]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA05105 for ; Wed, 23 Dec 1998 13:41:53 -0800 (PST) Message-ID: <19981223214231.9749.rocketmail@send104.yahoomail.com> Received: from [138.111.39.131] by send104.yahoomail.com; Wed, 23 Dec 1998 13:42:31 PST Date: Wed, 23 Dec 1998 13:42:31 -0800 (PST) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6976) Reg: IPv4 getting a IPv6 packet. To: Internet Protocol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What happens when a IPv4 node receives (if at all) a IPv6 packet. Is the IPV4 nodes discards the packet for version mismatch. -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Dec 23 14:22:49 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id OAA18948 for ipng-dist; Wed, 23 Dec 1998 14:14:21 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id OAA18941 for ; Wed, 23 Dec 1998 14:14: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 OAA00063 for ; Wed, 23 Dec 1998 14:14:09 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA22668 for ; Wed, 23 Dec 1998 14:14:09 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA02353; Wed, 23 Dec 1998 16:14:07 -0600 (CST) Message-Id: <199812232214.QAA02353@gungnir.fnal.gov> To: "Raghu V.V.J Vadapalli" Cc: Internet Protocol From: "Matt Crawford" X-Mailer: Microsoft Outlook98 Subject: (IPng 6977) Re: Reg: IPv4 getting a IPv6 packet. In-reply-to: Your message of Wed, 23 Dec 1998 13:42:31 PST. <19981223214231.9749.rocketmail@send104.yahoomail.com> Date: Wed, 23 Dec 1998 16:14:07 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What happens when a IPv4 node receives (if at all) a IPv6 packet. Is > the IPV4 nodes discards the packet for version mismatch. Since IPv6 has a different link-layer encapsulation code point on every medium I can think of (for example 86DD hex instead of 0800 hex for ethernet and the like), it should never happen that *the IPv4 stack* on such a node receives an IPv6 packet. But if it does happen, the fact that 6 is not equal to 4 should stop further processing. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 23 14:44:15 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id OAA18965 for ipng-dist; Wed, 23 Dec 1998 14:26:59 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id OAA18958 for ; Wed, 23 Dec 1998 14:26: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 OAA01763 for ; Wed, 23 Dec 1998 14:26:49 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA29307 for ; Wed, 23 Dec 1998 14:26:48 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA09044; Wed, 23 Dec 1998 14:26:47 -0800 (PST) Message-Id: <3.0.5.32.19981223142617.008018f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 23 Dec 1998 14:26:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6978) IPng W.G. Minutes for December IETF Cc: minutes@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Working Group December IETF Bob Hinden / Nokia Steve Deering / Cisco Co-Chairs Steve Deering introduced the meeting. Two meeting slots were scheduled. Bob Hinden took and edited the minutes. Thursday 3:30PM - 5:30PM Friday 9:00AM - 11:30AM The agenda was reviewed. The resulting agenda was: Agenda: - Introduction / S. Deering - Review Agenda / S. Deering - Unified IPv6/IPsec Stack / K. Kamamoto - Document Status / R. Hinden - IPv6 Code Points / R. Hinden - IPv6 6REN Status and Plans / R. Fink - Addressing to Draft Standard / R. Hinden - Initial IANA Sub-TLA Assignments / R. Hinden - IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter - Basic API Revision / J. Bound - DNS Extension to Support IP Version 6 / M. Crawford - Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering - Jumbograms / S. Deering - Router Renumbering / M. Crawford - Multicast Listener Discovery Protocol / S. Deering - Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 / L. Zhang, et. al. - Site Prefixes in Neighbor Discovery / E. Nordmark - Future IPv6 Direction / S. Deering - Mobile IPv6 Status / D. Johnson - IPv6 TCP and anycast address / Jun-ichiro Itoh - RPC and NFS over IPv6 / L. Wu - Tunnel Broker / A. Durand ------------------------------------------------------------------------ ------------------------------------------------------------------------ Unified IPv6/IPsec Stack / K. Kamamoto -------------------------------------- We decided to merge our code: - INRIA - NRL - Kame Project - to provide a single free reference code Targets are BSD variants - FreeBSD - NetBSD - OpenBSD - BSD/OS Schedule - Hopefully by next summer Document Status / R. Hinden --------------------------- - RFC Published o RFC2460 Internet Protocol, Version 6 Specification (DS) o RFC2463 ICMPv6 (DS) o RFC2461 Neighbor Discovery for IP Version 6 (IPv6) (DS) o RFC2462 IPv6 Stateless Address Autoconfiguration (DS) o RFC2454 MIB for IPv6: UDP (PS) o RFC2452 MIB for IPv6: TCP (PS) o RFC2465 MIB for IPv6: Textual Conventions & General Group (PS) o RFC2466 MIB for IPv6: ICMPv6 Group (PS) o RFC2472 IPv6 over PPP (PS) o RFC2471 IPv6 Testing Address Allocation (Experimental) o RFC2470 IPv6 Packets over Token Ring Networks (PS) o RFC2467 IPv6 Packets over FDDI Networks (PS) o RFC2464 IPv6 Packets over Ethernet Networks (PS) o RFC2450 Proposed TLA and NLA Assignment Rules (I) o RFC2473 Generic Packet Tunneling in IPv6 Specification (PS) - IETF Last Call completed for Proposed Standard o IP Header Compression / Nov 97 - Waiting for new draft o IPv6 over ARCnet Networks - Waiting for new draft o Router Renumbering for IPv6 - IESG Comments - Submitted to IESG for Proposed Standard o IPv6 Router Alert Option - IESG wants to reconcile w/ IPv4 Router Alert o Reserved IPv6 Subnet Anycast Addresses o DNS Extensions to Support IP Version 6 - IPng Working Group Last Call Completed for Proposed Standard o IPv6 Jumbo Payload Option o Transmission of IPv6 over IPv4 Domains without Explicit Tunnels - IPng Working Group Last Call Completed for Informational o Basic Socket Interface Extensions for IPv6 - Waiting for new draft o Initial IPv6 Sub-TLA ID Assignments - IPng Working Group Last Call Completed for Experimental o IPv6 Name Lookups Through ICMP IPv6 Code Points / R. Hinden ---------------------------- - Assignments for: o ICMPv6 Parameters o IP Version 6 Parameters - Accepted by IANA - Available on IANA Assigned Numbers Web Site: http://www.iana.org/numbers.html Carpenter: Important to carefully document IANA<->WG procedures for parameter assignment. Best to do as an RFC with big stamp of approval from the IESG. Addressing to Draft Standard / R. Hinden ---------------------------------------- - Addressing Documents o RFC2373 IPv6 Addressing Architecture o RFC2374 An Aggregatable Global Unicast Address Format - Implementation reports available at: ftp://playground.sun.com/pub/ipng/implementation-reports/ file name: add-arch-aggregat.txt o Additional reports desirable - Start working group last call for Draft Standard Implementation reports available. Bob proposes to start last call at this point for advancement of these 2 documents to Draft Standard. No objections. ACTION: Document editor will start working group last call to move the IPv6 addressing specifications to Draft Standard. Initial IANA Sub-TLA Assignments / R. Hinden -------------------------------------------- - Regional IP Registries plan to start allocating IPv6 addresses in Q1 1999 o Responding to requests from ISPs planning production IPv6 service - RIRs each need initial blocks of Sub-TLA ID's to assign - New draft to propose initial Sub-TLA ID Blocks: "Initial IPv6 Sub-TLA ID Assignments" Background | 3 | 13 | 13 | 19 | 16 | 64 | +----+------+-------+---------+------+--------------------------+ | FP | TLA |Sub-TLA| NLA | SLA | Interface ID | | | ID |ID | ID | ID | | +----+------+-------+---------+------+--------------------------+ ^ | | FP = 001 = Format Prefix TLA ID = 0x0001 = Top-Level Aggregation Identifier Sub-TLA ID Assignments Binary Range (Hex) Assignment ---------------- --------------- ------------------- 0 0000 00XX XXXX 0x0000 - 0x003F IANA 0 0000 01XX XXXX 0x0040 - 0x007F APNIC 0 0000 10XX XXXX 0x0080 - 0x00BF ARIN 0 0000 11XX XXXX 0x00C0 - 0x00FF RIPE NCC 0 0001 00XX XXXX 0x0100 - 0x013F (future assignment) 0 0001 01XX XXXX 0x0140 - 0x017F (future assignment) 0 0001 10XX XXXX 0x0180 - 0x01BF (future assignment) 0 0001 11XX XXXX 0x01C0 - 0x01FF (future assignment) 0 0010 00XX XXXX 0x0200 - 0x023F (future assignment) . . . . . . . . . 1 1111 11XX XXXX 0x1FC0 - 0x1FFF (future assignment) Where "X" indicates "0" or "1". Carpenter: Tuesday night, the IAB sent a request to IANA to assign blocks of sub-tla's to APNIC, ARIN, and RIPE-NCC in the same manner as specified in the draft. IPv6 6REN Status and Plans / R. Fink ------------------------------------ IPv6 Research and Education Networks Initiative The problem - Given the several years it will take to integrate existing implementations of IPv6 into production release products - and the several years it will take to work out all the details of making Internet applications work transparently over IPv6 - what do we do during this interval to maintain momentum for IPv6...? Where we are - We have standards, we have lots of implementations... we now need deployment - The R&E network community can now contribute substantially to IPv6, in the way it did to establish the Internet, ... - by creating production IPv6 networks suitable for real applications to use A start - In early October, ESnet established native IPv6 over ATM peering with CAIRN, Internet2/vBNS and CA*net2 - In December, with WIDE - and established an open participation initiative, the 6REN, to act as a rallying point for all RENs world-wide to provide production IPv6 service Isn't this just the 6bone? - The 6bone is a testbed network, operated under a testbed AUP, and is not operationally robust due to this fact - The 6ren is going to promote and coordinate production quality IPv6 service - The 6ren is NOT a network 6REN participation - Free and open to all Research and Education Networks that provide IPv6 service - Other for-profit and not-for-profit IPv6 networks are also encouraged to participate on this basis as well - The 6REN is more like a NANOG for IPv6 Work underway - A planning/formation meeting was held during this IETF Orlando meeting week - Existing 6bone pTLAs are being approached to find out can participate in this effort More work - Working with David Kessens to provide network registry service similar to that provided for the 6bone - Reverse DNS (ip6.int) registry planned to be provided through ISI, under IANA oversight, as done now for 6bone - ESnet will provide transit for the 6bone to all 6ren participants (with some proviso) next line - Convert the early participants to production IPv6 addresses as soon as the registries start handing out Sub-TLAs early next year - Work on making these networks provide production quality IPv6 service Also of interest - Effort is underway to help Australia and China RENs to develop plans and proposals to provide country-wide production IPv6 service o AARNET - the Australian Academic and Research Network o CERNET - the China Education and Research Network The Environment Today - State as of mid-December 1998 +------------+ Direct native IPoverATM /| Internet 2 | PVC links w/ BGP4+ peering / +------------+ / +-------+ / +------+ | |/ | | | ESnet |----------------| WIDE | | |\ | | +-------+ \ +------+ | \ | \ | \ +-------+ \+-------+ | CA*net| | CAIRN | +-------+ +-------+ Providing... - Motivation to run real Internet applications over a native IPv6 infrastructure - A possible incentive might be using it to provide a "quality" path - ... and because it's the "right" thing to do :-) Applications and IPv6 - Remember, no application we know of needs IPv6 to run - This is a feature, not a "bug" - This feature is the way we guarantee transitioning from IPv4 to IPv6 is transparent as possible Join the 6REN Initiative - See the new web site for the 6REN: http://6ren.net -Contact Bob Fink if you have any questions Bound: Corporate America doe snot have to wait for Microsoft. There are reasons to deploy now. IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter ---------------------------------------------------- Working group last call. Draft discussed here and in NGTRANS. Comments: Section 7 of document will be removed because it was half baked and draft will be reissued. ACTION: Document editor to send "IPv6 over IPv4 w/out Explicit Tunnels" to IESG for PS when new draft is out. Basic API Revision / J. Bound ------------------------------ As soon as new ID is out, DE is submitted for Informational. ACTION: Document editor to send "Basic API Revision to IESG for informational when new draft is out. DNS Extension to Support IP Version 6 / Matt Crawford ----------------------------------------------------- Document Status - Chairs requested ADs to advance it on October 15, 1998. - Depends on two dnsind wg drafts, which that chair passed to ADs Sep 22 & Sep 27. - One or both of which depend on "EDNS0" draft that just need a an IANA considerations section. Implementation / Experimentation - A6, binary labels and DNAME will be in BIND 9. - Experimental variant of 8.2 may be available sooner. Deployment Concerns - What if site is partitioned from the internet for an extended period? o At least two classes of solutions, including a spectrum of configurations choices in zone. - Need applicability statement o Glue records need scrutiny - ... to see how much of the same protection is appropriate. - What if your provider or DNS parent makes a mistake? o Same foot, same gun, new bullet. Router Renumbering / M. Crawford -------------------------------- Two small sets of IESG comments received - Editorial and wording preferences - Request for instructions to implementors and user regarding retransmission strategy. New draft should resolve IESG issues and allow this to move forward. Jumbograms / S. Deering ----------------------- It was reported that we now have two interoperable implementations. Can this move to Draft Standard now? Will this satisfy IESG requirements? It was already at proposed when it was part of IPv6 specification. Internet AD answered that it would be better to start at Proposed Standard. Comment to combine this with TCP/UDP jumbograms to produce one Jumbogram documents. After some discussion, documents authors will decide appropriate approach. Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- A new version of the draft is needed. Also, found problem with behavior when query time of zero. Needs to be defined meaning of zero. Zero will mean zero delay. Deering will issue new draft. It was noted that is dependent of IPv6 Router Alert. Concern raised about attack w/ zero value. Need to make sure these messages can not be forwarded from routers. ACTION: Document Editor will start w.g. last call for "Multicast Listener Discovery Protocol" for Proposed Standard once new ID is published. Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 / L. Zhang, et. al. ------------------------------------------------------------------------ History - Feb '97: IPng interim meeting on GSE proposal - draft-00 in summer '97, mostly reporting on the meeting discussion and consensus, received lots positive feedback and comments. - The authors all got overloaded, dragged on the revision for a looooong time period Current State and Next Step - draft--3 (this IETF) mostly focus on the analysis of pro's and con's of separating locators and identifiers: o Overloading address field with both functions has its architectural importance o The separation introduces new issues that have no clear solutions - Request WG last call to publish the analysis as an Info RFC. ACTION: Document editor will issue w.g. last call for publishing "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6" as an Informational RFC. Site Prefixes in Neighbor Discovery / E. Nordmark ------------------------------------------------- Site prefixes in Neighbor Discovery Outline - Site model including mobile nodes - Proposed protocol - Mobility issues Model - An interface belongs to (at most) one site. - A link belongs to (at most) one site. - A node (host or router) can have interfaces in multiple sites. - Site boundaries pass through nodes - not through links. Model for mobile nodes away from home - Always considered to have one interface in its home site. - This interface is the conceptual tunnel to its home agent and nodes in the home site. - Implies that mobile nodes are "multi-sited". Proposal - Routers advertise "site prefixes" - global address prefixes assigned to the site. - Nodes use the site prefixes to determine what global addresses are part of the site. - Site local (and global) addresses stored in the (global) DNS. - "Resolver" filters out site local addresses unless one or more global addresses match a site prefix. o Site locals only used when peer is known to be in same site as sender. Prefix option format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|S|Resvd1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Site PLength | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S site prefix flag: Site PLength is valid. Site PLength: Number of bits in site prefix. Example - RRset in DNS 2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1 fec0::987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 2000:1:2:34:X:Y:W:Z2 fec0::34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 - Advertised site prefixes: 2837:a:b::0/48 2000:1:2::0/48 - Addresses used by application: fec0::987:X:Y:W:Z1 fec0::34:X:Y:W:Z2 - Instead if site prefix list is empty apps use: 2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 2000:1:2:34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 Question about motivation. Beneficial, if you think internet is not going to renumber, wants to use site local addresses for all internal traffic. Only have external traffic use global addresses. Make internal traffic impervious to renumbering. Comments: This is a big deal and makes DNS resolver very complex. Thinks draft has not been read/understood. Thinks we should do this. Should we add this to BIND9? Some work in resolver. Another motivation for this is that site local address are the IPv6 equivalent of "Net10" private address space. Some people think having private addresses are important. This draft helps make this work. Allows site to use both private and public with not difficult transition. Impact of deployment? Can we get all implementations done in timely manner? Requiring two-faced DNS would be a mistake. Mobile nodes - Will acquire global care of address(es). - Might acquire a site-local care of address. (but not useful). - Retain any site local address from home site. o Only use this when communicating over the conceptual interface to the home site. - Detect when moving away from the home site and back. o Using the advertised site prefixes. Home agents - No changes. Proper source address selection when originating packets sufficient. Correspondent nodes - When the binding cache for a site local destination has a global care of address: o Include a Home Agent option containing the site local source address. - Ensures that the source address of the IPv6 header is a global address when the packet leaves the site. Summary - All nodes must start ignoring site local addresses returned from the DNS. - As site prefixes become advertised these addresses can be used. Questions/Comments: This works by matching up something in ND messages w/ what is in DNS. Could also do DNS-DNS matching. Reply: This wouldn't work for Mobile nodes. Deering: Some people are unhappy with this. Any impact on firewalls? No Question about leakage of internal structure of DNS information outside of network. How would work w/reverse zones. Answer in draft. Can construct reverse addresses Jim Bound thinks this will help deployment. Chair took poll to see if having to make resolver changes to support this is too hard. No strong objection. Strong agreement to continue this work. Future IPv6 Direction / S. Deering ---------------------------------- What should happen next? Lots of this we could do? Or not. - more auto config, discovery of names, etc. What chairs had in mind was to hold an interim IPv6 meeting. Tentatively first week of February. Review state of IPv6 protocols and transition mechanisms. Identify new works, new approaches, etc. Initial proposal to meet at LBNL in S.F. Bay area. First two day would be combined NGTRANS and IPng first two days. Third day would be coordination, 6REN, 6BONE, etc. Polled room to see who could attend: Many would attend. Another proposal to have meeting in Europe or Japan. Possible sponsors should talk to Chairs after meeting. Editor Note: Subsequent to the meeting it has been announced that the Interim meeting will be held on February 2-4 in Grenoble France. Details sent to IPng and NGTRANS mailing lists. Mobile IPv6 Status / D. Johnson ------------------------------- Completed w.g. last call and has been submitted to IESG. IETF last call should occur soon. New Encoding for Operational Information Unique Identifier Sub-Option Home Agents List Sub-Option Dynamic Home Agent Address Discovery Details Comment: This and RR need to handle "R" bit behavior correctly. Miscellaneous Changes Question: Should we put the required part for every host in separate document. Would highlight this functions. Several comments that this is not necessary. ACTION: Document Editor will produce web page that lists required IPv6 specifications. Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering --------------------------------------------------------------- Previously submitted to IESG for PS. Waiting for IETF last call. IPv6 TCP and anycast address / Jun-ichiro Itoh ---------------------------------------------- Problem in TCP and anycast - Anycast addr MUST NOT be used as source addr - Can not disconnect TCP connection to anycast addr, by TCP RST o Source address must match the SYN's destination - Sender must wait till the TCP SYN timeout comes Sender Receiver S R, Anycast A SYN _______________ \______________\ / ______________ /_______________/ \ RST When this situation happens - Any situations possible o No way to distinguish anycast addr - Anycast addr in DNS database o telnet host.foo.com makes connection to the addr - Addr typed in by hand - Addr given to client from some server - We need a common way to disconnect TCP to anycast addr Proposed Solution - Transmit ICMP addr unreachable o No restriction on source addr o More quick disconnection possible Sender Receiver S R, Anycast A SYN _______________ SYN \______________\ / ______________ /_______________/ \ ICMP addr unreach - Implemented into KAME IPv6 stack - Works fine against BSD-based TCP stack o Listen to ICMP errors, disconnect TCP connection if # exceeds limit Comments: This should not be the behavior. TCP is not supposed to close connections on receipt of ICMP error messages. This error does not usually indicate "permeant" error. BSD is not a good model for this behavior. Issues - Per-address notification, not per-port o OK since TCP to anycast is always disallowed - Security o Malicious router can disconnect any TCP session o Problem is in ICMP, not new - Future update in anycast to allow TCP? o Implementations MUST make a flog to disable this - Need your experience for non-BSD TCP o Experiments welcome, at terminal room - UDP6 suffers from this problem too... o Example: name server on anycast addr Deering: Was hoping there would be a proposal to change TCP to allow connection initialization using any anycast address. Special option in TCP to allow this. Asked if author interested in creating a TCP option. Reply: Likes idea but think there are security problems to deal with this. Problem w/ UDP is not a severe as with TCP. Some UDP applications already work w/ multicast. DNS is a problem. Would like to experiment with this, then submit an internet draft for consideration by the w.g. RPC and NFS over IPv6 / L. Wu ----------------------------- RPC is supposed to be transport independent. Why would it ever be an issue for RPC over IPv6? - RPC service lookup protocol o Overview of RPC Service Lookup protocol o What are the issues - RPC-API RPC service lookup protocol Overview - RPC Service Lookup protocol enables client and server to bind dynamically. - It was also know as PORT MAPPER - Now it's evolved from the PORT MAPPER (version2) to RPCBIND (version 3&4). However PORT MAPPER is more widely deployed. +----------------+ +--------+ | | | |------------------------->| | | Client | | Server | | |<-------------------------| | +--------+ | | | | +----------------+ Version 2: protocol = 32-bit integer, Port = 32 bit integer Version 3&4: protocol = string, port = string RPC IPv6 Service lookup Issues? - How to lookup IPv6 RCP services? o Using PORT MAPPER o Using RPCBIND o Enforce IPv6 RPC services to use the port as IPv4 service? Using PORT MAPPER - Portmapper Request: - Proposing: o Create a new protocol number to indicate services running tcp over IPv6 and udp over IPv6. There is no restriction in the protocol to be coincide with IANA number. or o Have PORT MAPPER listens on a different port than 111 for IPv6 service Editor's Note: in slide, they don't mean changing TCP protocol number, just local identifier inside of implementation for port mapper. Using RPCBIND RPCBIND request: - Proposing netid to be: tcp6 - for service running TCP over IPv6 udp6 - for service running UCP over IPv6 Enforcing IPv6 service port - If we are enforcing IPv6 service port to be the same as IPv4 service on a dual stack hosts. There won't be any issues with IPv6 service lookup. - Proposing: o Not to support the above idea, because it's not possible to differentiate a RPC service only support IPv4 on a dual stack host. Discussion. RPC API - There are two major sets of RPC-APIs: o Socket based RPC-API, as known as TS-RPC o TLI/XTI based RPC-API, also known as TI-RPC TS-RPC API - Many APIs embedded sockaddr_in as parameters, for example: clntudp_create(sockaddr_in *raddr, rpcprog_t, prog, rpcvers_t vers, register int *sockp, u_int sendsz, u_int recvsz) - Proposing o Create new API that support sockaddr_in6 TI-RPC API - It's not an issue for TI-RPC APIs since no sockaddr_in structure is exposed SUMMARY - Use TI-RPC APIs - Have a separate service port for IPv4 and IPv6 service, and use RPCBIND for RPC service lookup with netid of TCP6 and UDP6 to specify services over IPv6 - Leave PORT MAPPER for IPv4 service lookup only. If want to extend it for IPv6, we have to resolve the issues. - Current TS-RPC API is not able to support IPv6. Tunnel Broker / A. Durand ------------------------- Tunnel Broker / Server Web page +-----+ +-----+ +-----+ | | /| S | | B |\ | | / | | | | \ +-----+ Tunnel / +-----+ +-----+ \ IPv6 target ^ | Broker / +------+ | | +-----+ | | | | +------>| B | IPv6 netowrk | | | | / +------| |\ | | | | / / +-----+ \4 +------+ 1 | | 2 3/ / \ \ / | | / /5 \ V / | V / / \ +-----+ +-----+ / +----+ / / \ | | | | / | |/ / 6 | S | | S |/ | |=======================| | | | +----+ +-----+ +-----+ Dual stack IPv4 host Tunnel server The basic idea is to get the address of a tunnel broker from a web page (step 1 & 2), then running a tunnel broker protocol to the tunnel broker (steps 3 & 5) automatically obtain the address (similar to the way DHCP provides addresses) obtain a tunnel endpoint address of a tunnel server (step 6). The tunnel broker would communicate with the tunnel server as part of this process (step 4). Discussion, many questions. Plans on experimenting w/ this. Later might need to standardize a tunnel broker protocol. Brian C: Does this replace 6over4 approach. Reply: No, it is complementary. ---------------------------------------------------------------- ---------------------------------------------------------------- Meeting adjourned ---------------------------------------------------------------- ---------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 23 16:57:10 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id QAA19111 for ipng-dist; Wed, 23 Dec 1998 16:47:59 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id QAA19104 for ; Wed, 23 Dec 1998 16:47: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 QAA05099 for ; Wed, 23 Dec 1998 16:47:50 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA06310 for ; Wed, 23 Dec 1998 16:47:49 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA14057; Wed, 23 Dec 1998 16:47:47 -0800 (PST) Message-Id: <3.0.5.32.19981223164716.007bcc90@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 23 Dec 1998 16:47:16 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6979) Update to IPng Web Pages Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I updated to the IPng web pages at: http://playground.sun.com/ipng Changes include a new page with specifications listed by IETF standardization status, new RFCs and IDs, meeting minutes, and an announcement (w/ link) about the interim meeting in Grenoble. Comments and corrections to me. I would also like to wish everyone a Happy Holiday. 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 Dec 23 21:01:55 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id UAA19223 for ipng-dist; Wed, 23 Dec 1998 20:53:14 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id UAA19202; Wed, 23 Dec 1998 20:50: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 UAA28775; Wed, 23 Dec 1998 20:50:16 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA26490; Wed, 23 Dec 1998 20:50:17 -0800 (PST) Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0c) with SMTP id XAA01888; Wed, 23 Dec 1998 23:50:48 -0500 (EST) Received: from bywasted.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA27688; Wed, 23 Dec 1998 23:50:15 -0500 Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id XAA0000017545; Wed, 23 Dec 1998 23:50:15 -0500 (EST) From: Jim Bound Message-Id: <199812240450.XAA0000017545@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 6980) Interim Meeting Agenda Date: Wed, 23 Dec 1998 23:50:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chairs, Can we get an initial formal agenda for the Interim meeting for the first two days. Inquiring managers want to know what the agenda is for approval of International Travel. I will wing it for now but we really need one soon. 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 Dec 24 01:58:34 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id BAA19337 for ipng-dist; Thu, 24 Dec 1998 01:48:38 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id BAA19330; Thu, 24 Dec 1998 01:48: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 BAA05557; Thu, 24 Dec 1998 01:48:27 -0800 Received: from ezymail.ezymail.com ([203.61.203.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA19510; Thu, 24 Dec 1998 01:48:23 -0800 (PST) Received: from wdc-ws000000 ([203.108.83.26]) by ezymail.ezymail.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 1-666L) with SMTP id AAA322; Thu, 24 Dec 1998 19:51:27 +1000 Reply-To: From: "Mitch Denny" To: "Jim Bound" , , Subject: (IPng 6981) RE: Interim Meeting Agenda Date: Thu, 24 Dec 1998 20:47:13 +1000 Message-ID: <000101be2f2a$c4100a30$0141000a@wdc-ws000000.resource.mu.mel.au.wdc.com> 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-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <199812240450.XAA0000017545@wasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Just print a page with a random smatering of acronyms. That ought to confuse them :) Cheers, (and Merry Christmas) Mitch Denny warbyte@ezymail.com > -----Original Message----- > From: owner-ipng@sunroof.Eng.Sun.COM > [mailto:owner-ipng@sunroof.Eng.Sun.COM]On Behalf Of Jim Bound > Sent: Thursday, December 24, 1998 2:50 PM > To: ipng@sunroof.Eng.Sun.COM; ngtrans@sunroof.Eng.Sun.COM > Subject: (IPng 6980) Interim Meeting Agenda > > > Chairs, > > Can we get an initial formal agenda for the Interim meeting for the > first two days. Inquiring managers want to know what the agenda is for > approval of International Travel. I will wing it for now but we really > need one soon. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 28 07:27:02 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id HAA21721 for ipng-dist; Mon, 28 Dec 1998 07:20:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id HAA21714 for ; Mon, 28 Dec 1998 07:20:38 -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 HAA28907 for ; Mon, 28 Dec 1998 07:20:37 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA14273 for ; Mon, 28 Dec 1998 07:20:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20294; Mon, 28 Dec 1998 10:20:34 -0500 (EST) Message-Id: <199812281520.KAA20294@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6983) I-D ACTION:draft-degermark-ipv6-hc-08.txt Date: Mon, 28 Dec 1998 10:20:34 -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 Header Compression Author(s) : M. Degermark, B. Nordgren, S. Pink Filename : draft-degermark-ipv6-hc-08.txt Pages : 47 Date : 16-Dec-98 This document describes how to compress multiple IP headers and TCP and UDP headers per-hop over point-to-point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low- and medium-speed links. The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-degermark-ipv6-hc-08.txt Internet-Drafts are also 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-degermark-ipv6-hc-08.txt". Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org 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-degermark-ipv6-hc-08.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: <19981228091726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-degermark-ipv6-hc-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-degermark-ipv6-hc-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981228091726.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 Dec 28 11:35:15 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id LAA22102 for ipng-dist; Mon, 28 Dec 1998 11:30:28 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id LAA22095 for ; Mon, 28 Dec 1998 11:30: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 LAA26979 for ; Mon, 28 Dec 1998 11:30:18 -0800 Received: from exchsrv1.cs.washington.edu (exchsrv1.cs.washington.edu [128.95.3.128]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA04984 for ; Mon, 28 Dec 1998 11:30:18 -0800 (PST) Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.1960.3) id ; Mon, 28 Dec 1998 11:30:14 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5F4F98FF@exchsrv1.cs.washington.edu> From: Marc Fiuczynski To: "'Craig Metz'" , Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6984) Re: route distribution via ND Date: Mon, 28 Dec 1998 11:30:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, >From: Craig Metz [mailto:cmetz@inner.net] >In message <4D0A23B3F74DD111ACCD00805F31D8100AF819A2@RED-MSG-50>, you write: >>One can view ND as performing distribution of routes. For example receipt of >>an RA with a non-zero router lifetime communicates a default route (/0 >>route). A prefix-information option with the L bit communicates an on-link >>prefix (a /64 route). >> >>Why not define an option to let RAs communicate routes more generally? For >>example, define a new flag bit (call it the N bit) for prefix information >>options to say that this prefix should be added to the receiving host's >>route table, with the router sending the RA as the next-hop for the prefix? > > Unless I'm highly confused or the specs changed, ND already does this and was >intended all along to do this. Advertise a prefix with autonomous off and >on-link off. Reading RFC 2461 it is not clear to me that ND does what we were more explicitly proposing. In section 4.6.2 it states the following for the L bit: [L is a ] 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off- link. Additionally, the description for the prefix information option states: The Prefix Information option provide hosts with on-link prefixes and prefixes for Address Autoconfiguration. After reading this (and more of the RFC) it isn't clear to me how the prefix option should be processed if the L bit (and other bits) are not set. I can see how one might "interpret" that the prefix information should then be used to create a route to the router sending the RA, but the text does not explicitly state that. It seems that a simple clarification to the description of the prefix information option would help. Something along the lines of explicitly stating that the prefix option indicates the next-hop for the supplied prefix if and only if all of the flag bits are off. This is functionally equivalent to introducing a new bit (as Richard and I did), yet saves us from wasting this particular bit as it should never need to be set in conjunction with any of the existing or proposed prefix option flag bits. Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 30 04:48:03 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id EAA22970 for ipng-dist; Wed, 30 Dec 1998 04:40:15 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id EAA22963 for ; Wed, 30 Dec 1998 04:40: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 EAA09275 for ; Wed, 30 Dec 1998 04:40:02 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA08189 for ; Wed, 30 Dec 1998 04:40:03 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA00770; Wed, 30 Dec 1998 07:39:29 -0500 (EST) Message-Id: <199812301239.HAA00770@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6986) Protocol Action: IP Header Compression to Proposed Standard Date: Wed, 30 Dec 1998 07:39:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IP Header Compression' 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 describes how to compress multiple IP headers and TCP and UDP headers per-hop over point-to-point links. The methods can be applied to IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low- and medium-speed links. The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links. Working Group Summary Their was consensus within the working group for this document. Protocol Quality This document has been reviewed for the IESG by Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 30 05:23:35 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id FAA23037 for ipng-dist; Wed, 30 Dec 1998 05:15:15 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id FAA23030 for ; Wed, 30 Dec 1998 05:15: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 FAA20796 for ; Wed, 30 Dec 1998 05:15:04 -0800 Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA15109 for ; Wed, 30 Dec 1998 05:15:05 -0800 (PST) Received: from hygro.raleigh.ibm.com (user-152-16-66-194.adsl.duke.edu [152.16.66.194]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id IAA11243; Wed, 30 Dec 1998 08:14:59 -0500 (EST) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.8.7/8.7.3) with ESMTP id IAA00548; Wed, 30 Dec 1998 08:16:56 -0500 Message-Id: <199812301316.IAA00548@hygro.raleigh.ibm.com> To: Richard Draves cc: "'IPng List'" , "'Marc Fiuczynski'" Subject: (IPng 6987) Re: route distribution via ND In-Reply-To: Message from Richard Draves of "Tue, 22 Dec 1998 14:31:45 PST." <4D0A23B3F74DD111ACCD00805F31D8100AF819A2@RED-MSG-50> Date: Wed, 30 Dec 1998 08:16:56 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The basic problem we want to solve is letting routers inform hosts about > routes. For example, we don't want to manually configure hosts to know that > a certain v6 prefix should be routed to Marc's v6-v4 translator. Note that the need to have prefix routes installed in hosts is only necessary if the host has multiple interfaces (i.e., is multihomed). If there is just one interface, using a single default route and redirects will handle everything just fine. > One solution is not to bother with this: let hosts send to a default > router, and the default router can redirect as necessary. But the > redirect overhead might be undesirable in some environments. I'd like to better understand this argument. The overhead of one redirect amortized over the life of every "flow" is almost always going to be noise in the overall scheme of things. What part of the overhead is undesirable? Note also, that if prefixes were propagated via ND, one can still construct scenarios where advertising prefixes would result in *more* redirects than if prefixes were not advertised at all. For example, if the advertised prefix was a large aggregate, more specific prefixes of the aggregate might need go out through a different path. > My understanding of v4 practice is that hosts will sometimes "snoop" > routing protocols like RIP and so learn routes. I would argue this is only useful/necessary on multihomed hosts, where having a list of default routers doesn't help in choosing the correct outgoing interface. (Once an interface has been selected, redirects can be used to find the best router on that interface.) > One can view ND as performing distribution of routes. For example > receipt of an RA with a non-zero router lifetime communicates a > default route (/0 route). A prefix-information option with the L bit > communicates an on-link prefix (a /64 route). > Why not define an option to let RAs communicate routes more > generally? For example, define a new flag bit (call it the N bit) > for prefix information options to say that this prefix should be > added to the receiving host's route table, with the router sending > the RA as the next-hop for the prefix? I think it is worth stepping back and understanding the actual problem that needs solving. If it is to handle the multihomed host case, it seems like it might also be useful to have a metric, so that a host could select the router with the "shorter" route for a prefix. Once you add a metric, seems like you've reinvented RIP. Why not just use it? Indeed, a client (receive-only) version of RIP wouldn't have to be large and would seem to do the job already. > This is more desirable than snooping random routing protocols. Hosts must > implement ND anyway so there is very little implementation overhead. I agree that snooping "random" routing protocols is undesirable. But I see nothing wrong with using RIP as a "last hop" technology for communicating routing information from routers to hosts. One could still run OSPF (or whatever) on the network, just using RIP for the last hop. Or if RIP doesn't quite do all the right things for this, define a protocol that does. 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 Dec 30 05:23:36 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id FAA23046 for ipng-dist; Wed, 30 Dec 1998 05:15:39 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id FAA23039 for ; Wed, 30 Dec 1998 05:15: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 FAA20823 for ; Wed, 30 Dec 1998 05:15:28 -0800 Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA15175 for ; Wed, 30 Dec 1998 05:15:28 -0800 (PST) Received: from hygro.raleigh.ibm.com (user-152-16-66-194.adsl.duke.edu [152.16.66.194]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id IAA11247; Wed, 30 Dec 1998 08:15:27 -0500 (EST) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.8.7/8.7.3) with ESMTP id IAA00557; Wed, 30 Dec 1998 08:17:25 -0500 Message-Id: <199812301317.IAA00557@hygro.raleigh.ibm.com> To: Marc Fiuczynski cc: "'Craig Metz'" , Richard Draves , ipng@sunroof.eng.sun.com Subject: (IPng 6988) Re: route distribution via ND In-Reply-To: Message from Marc Fiuczynski of "Mon, 28 Dec 1998 11:30:09 PST." <055A195871E5D1119F8100A0C9499B5F4F98FF@exchsrv1.cs.washington.edu> Date: Wed, 30 Dec 1998 08:17:25 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > After reading this (and more of the RFC) it isn't clear to me how the > prefix option should be processed if the L bit (and other bits) are not > set. There are a number of bits defined in the prefix information option. If a particular bit is set, there are instructions on what that means. If a bit is not set, one is supposed to do *nothing* special. Look at it as if there are optional fields. How do you process an optional field in a packet if the optional field is omitted? You don't do *anything* at all! > I can see how one might "interpret" that the prefix information > should then be used to create a route to the router sending the RA, but > the text does not explicitly state that. The text attempted to explictely say "do nothing" (see, for instance the message from Matt Crawford). > It seems that a simple clarification to the description of the > prefix information option would help. Something along the lines of > explicitly stating that the prefix option indicates the next-hop for > the supplied prefix if and only if all of the flag bits are off. This is not what what the current document is intended to say. Thus, this "clarification" would be a change in existing behavior. 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 Dec 30 06:53:31 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id GAA23121 for ipng-dist; Wed, 30 Dec 1998 06:50:43 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id GAA23114 for ; Wed, 30 Dec 1998 06:50:22 -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 GAA24019 for ; Wed, 30 Dec 1998 06:50:20 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA07102 for ; Wed, 30 Dec 1998 06:50:11 -0800 (PST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id GAA28191; Wed, 30 Dec 1998 06:50:07 -0800 (PST) From: Bill Manning Message-Id: <199812301450.GAA28191@zephyr.isi.edu> Subject: (IPng 6989) Re: route distribution via ND To: narten@raleigh.ibm.com (Thomas Narten) Date: Wed, 30 Dec 1998 06:50:07 -0800 (PST) Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com, mef@cs.washington.edu In-Reply-To: <199812301316.IAA00548@hygro.raleigh.ibm.com> from "Thomas Narten" at Dec 30, 98 08:16:56 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 > > Why not define an option to let RAs communicate routes more > > generally? For example, define a new flag bit (call it the N bit) > > for prefix information options to say that this prefix should be > > added to the receiving host's route table, with the router sending > > the RA as the next-hop for the prefix? > > I think it is worth stepping back and understanding the actual problem > that needs solving. If it is to handle the multihomed host case, it > seems like it might also be useful to have a metric, so that a host > could select the router with the "shorter" route for a prefix. Once > you add a metric, seems like you've reinvented RIP. Why not just use > it? Indeed, a client (receive-only) version of RIP wouldn't have to be > large and would seem to do the job already. > > > This is more desirable than snooping random routing protocols. Hosts must > > implement ND anyway so there is very little implementation overhead. > > I agree that snooping "random" routing protocols is undesirable. But I > see nothing wrong with using RIP as a "last hop" technology for > communicating routing information from routers to hosts. One could > still run OSPF (or whatever) on the network, just using RIP for the > last hop. > > Or if RIP doesn't quite do all the right things for this, define a > protocol that does. > > Thomas I presume that you are refering to RIPv2 here and not RIPv1. IPv6 has inherited the concept of classless delegation and so the base of any such work should come from the RIPv2 spec. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 30 10:20:26 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id KAA23262 for ipng-dist; Wed, 30 Dec 1998 10:18:13 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id KAA23255 for ; Wed, 30 Dec 1998 10:18:05 -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 KAA21503 for ; Wed, 30 Dec 1998 10:18:03 -0800 Received: from exchsrv1.cs.washington.edu (exchsrv1.cs.washington.edu [128.95.3.128]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA11142 for ; Wed, 30 Dec 1998 10:18:04 -0800 (PST) Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.1960.3) id ; Wed, 30 Dec 1998 10:18:03 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5F4F9915@exchsrv1.cs.washington.edu> From: Marc Fiuczynski To: "'Thomas Narten'" Cc: "'Craig Metz'" , Richard Draves , ipng@sunroof.eng.sun.com Subject: (IPng 6990) Re: route distribution via ND Date: Wed, 30 Dec 1998 10:17:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Thomas Narten [mailto:narten@raleigh.ibm.com] >Sent: Wednesday, December 30, 1998 5:17 AM >To: Marc Fiuczynski >Cc: 'Craig Metz'; Richard Draves; ipng@sunroof.Eng.Sun.COM >Subject: (IPng 6988) Re: route distribution via ND > >> After reading this (and more of the RFC) it isn't clear >> to me how the prefix option should be processed if the >> L bit (and other bits) are not >> set. > >There are a number of bits defined in the prefix information >option. If a particular bit is set, there are instructions on what >that means. If a bit is not set, one is supposed to do *nothing* >special. Look at it as if there are optional fields. How do you >process an optional field in a packet if the optional field is >omitted? You don't do *anything* at all! I completely agree that if an option bit is off that one should just ignore the particular handling of the option. Someone else suggested that the mechanism that Richard and I were proposing was already handled when one left the autonomous and on-link option flag bits off. This is the reason Richard and I wanted to introduce a new bit in the option information flags. Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 30 10:45:39 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id KAA23288 for ipng-dist; Wed, 30 Dec 1998 10:34:04 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id KAA23281 for ; Wed, 30 Dec 1998 10:33: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 KAA08542 for ; Wed, 30 Dec 1998 10:33:54 -0800 Received: from exchsrv1.cs.washington.edu (exchsrv1.cs.washington.edu [128.95.3.128]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA16679 for ; Wed, 30 Dec 1998 10:33:54 -0800 (PST) Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.1960.3) id ; Wed, 30 Dec 1998 10:33:53 -0800 Message-ID: <055A195871E5D1119F8100A0C9499B5F4F9916@exchsrv1.cs.washington.edu> From: Marc Fiuczynski To: "'Thomas Narten'" , Richard Draves Cc: "'IPng List'" Subject: (IPng 6991) RE: route distribution via ND Date: Wed, 30 Dec 1998 10:33:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Thomas Narten [mailto:narten@raleigh.ibm.com] >Sent: Wednesday, December 30, 1998 5:17 AM >To: Richard Draves >Cc: 'IPng List'; 'Marc Fiuczynski' >Subject: Re: (IPng 6964) route distribution via ND > > >> The basic problem we want to solve is letting routers >> inform hosts about routes. For example, we don't want >> to manually configure hosts to know that a certain v6 >> prefix should be routed to Marc's v6-v4 translator. > >Note that the need to have prefix routes installed in >hosts is only necessary if the host has multiple interfaces >(i.e., is multihomed). If there is just one interface, >using a single default route and redirects will handle >everything just fine. Just so that I am crystal clear about this. What should happen for the following simple scenario: Clients sending packets with a prefix P *must* be sent via a stub-router S. This stub-router may not have the capability to act as a default router. The question is how do clients learn about the route for prefix P to stub-router S? One approach is to have a default-router send redirects. What if there is no default router in this particular environment? Another approach is to distributed routes via RIP. What if the clients are too primitive (e.g., an IPv6-capable embedded device)? Our approach is to use the existing ND support to distribute simple routes for particular prefixes using the prefix information option. Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Dec 30 18:27:25 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id SAA23503 for ipng-dist; Wed, 30 Dec 1998 18:12:32 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id SAA23496 for ; Wed, 30 Dec 1998 18:12: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 SAA10910 for ; Wed, 30 Dec 1998 18:12:22 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id SAA06320 for ; Wed, 30 Dec 1998 18:12:19 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id CA15584; Thu, 31 Dec 1998 13:12:09 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Marc Fiuczynski Cc: "'IPng List'" Subject: (IPng 6992) Re: route distribution via ND In-Reply-To: Your message of "Wed, 30 Dec 1998 10:33:51 -0800." <055A195871E5D1119F8100A0C9499B5F4F9916@exchsrv1.cs.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Dec 1998 13:12:08 +1100 Message-Id: <1333.915070328@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 30 Dec 1998 10:33:51 -0800 From: Marc Fiuczynski Message-ID: <055A195871E5D1119F8100A0C9499B5F4F9916@exchsrv1.cs.washington.edu> | This stub-router may not have the capability to act as a default router. It would not be much of a router, but let's leave that aside. | The question is how do clients learn about the route for prefix P to | stub-router S? >From some other router, via a redirect, or via RIP, most likely. | One approach is to have a default-router send redirects. What if there | is no default router in this particular environment? "Default router" is a misnomer, "default" is not a property of the router, it is an attribution provided to it by the host. Any router that is truly a router should do. If there is only S (it is the only router), then it will do (must do) - regardless of what it might do to packets sent to it with unknown addreses. If there is some other router, then it will suffice. If you are postulating an environment with some number (> 1) of brain dead semi-routers, that can't really route, but do forward some packets, then I think that is an environment that we ought to explicitly discourage (and certainly not fudge any protocols to support). | Another approach is to distributed routes via RIP. Yes, that one works well. I have been using RIP that way for years (routing is done via OSPF, hosts, most of which of significance here are multi-homed, learn what exists where by listening to RIP. [Aside to Bill Manning: see rfc2080] | What if the clients are too primitive | (e.g., an IPv6-capable embedded device)? It is hard to imagine a device too primitive to support receive only RIP. It is certainly no more complex that supporting the same functionality in ND packets. Certainly there might be a little extra packet recognition logic involved, but this is really on the side of being so trivial as to be not worthy of mention. 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 Dec 30 20:36:27 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id UAA23545 for ipng-dist; Wed, 30 Dec 1998 20:26:40 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka [129.146.65.47] (may be forged)) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id UAA23538 for ; Wed, 30 Dec 1998 20:26:28 -0800 (PST) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA04008; Wed, 30 Dec 1998 20:26:25 -0800 Message-Id: <199812310426.UAA04008@hsmpka.eng.sun.com> Date: Wed, 30 Dec 1998 20:22:11 -0800 (PST) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 6993) Re: route distribution via ND To: kre@munnari.OZ.AU Cc: mef@cs.washington.edu, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Q7WCMJQdMt9L6kL0NimkBA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, > "Default router" is a misnomer, "default" is not a property of the router, > it is an attribution provided to it by the host. O.K. so far... > Any router that is truly > a router should do. I've been present in a number of discussions where some pretty sharp people didn't agree on -what- exactly a router should do... But, still, O.K. so far... > If you are postulating an environment with some number (> 1) of brain dead > semi-routers, that can't really route, but do forward some packets, then > I think that is an environment that we ought to explicitly discourage (and > certainly not fudge any protocols to support). Here I think you go too far. Q1) Is it legitimate (in your model of a collection of interconnected networks) for a network entity to agree to forward packets that it receives (somehow) and yet not to run a "routing protocol"? Q2) If someone can build a small embedded system that incorporates such a network entity, and it is IPv6 addressable, why is it so bad for that entity to only want to forward a small number of packets? I can easily imagine uses for such devices. Q3) Even if such a network entity might have enough memory to run extra protocols, what if there were a great many of them, each of which only wanted to handle a few packets, and all of them had a network interface on a very busy network link so that none of them wanted to be a default router? I'm not saying whether or not Router Advertisements ought to be doctored up to supply this functionality, but I don't think it's so clearly undesirable. I'm also not claiming that IPv6 was designed for the case in (Q3), but I don't understand the need to declare that case out of bounds. 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 Dec 30 21:42:06 1998 Received: by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) id VAA23609 for ipng-dist; Wed, 30 Dec 1998 21:39:11 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.2.Beta4+Sun/8.9.2.Beta4) with SMTP id VAA23602 for ; Wed, 30 Dec 1998 21:39:02 -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 VAA17856 for ; Wed, 30 Dec 1998 21:39:03 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id VAA22564 for ; Wed, 30 Dec 1998 21:38:54 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.57) id FA01679; Thu, 31 Dec 1998 16:38:44 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Charles Perkins Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6994) Re: route distribution via ND In-Reply-To: Your message of "Wed, 30 Dec 1998 20:22:11 -0800." <199812310426.UAA04008@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Dec 1998 16:38:43 +1100 Message-Id: <2304.915082723@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 30 Dec 1998 20:22:11 -0800 (PST) From: Charles Perkins Message-ID: <199812310426.UAA04008@hsmpka.eng.sun.com> | Q1) Is it legitimate (in your model of a collection of interconnected | networks) for a network entity to agree to forward packets that it | receives (somehow) and yet not to run a "routing protocol"? It has to get its forwarding information from somewhere. That somewhere is a routing protocol (even if this means a human sitting at a keyboard once a decade typing "route to abc/nn via pqr" type statements.) So, no, it isn't, as without a routing protocol it cannot work. Note that we're talking exclucively of layer 3 forwarding devices here - that is ones where the entity that originated the layer 2 packet explicitly addressed it (at layer 2) to the device in question. Devices that spoof layer 2 type addresses, and such, to extract some packets from a layer 2 net and send them elsewhere are a different thing entirely (they most probably need some kind of routing too, but not at layer 3). Lastly, to perhaps avoid the need for further discussion, no, I don't necessarily see it as a requirement that a dynamic routing protocol be used. Nor do I see that as relevant here. (I also don't see send only RIP from "routers" or listen only RIP on hosts as a dynamic routing protocol of any substance). | Q2) If someone can build a small embedded system that incorporates | such a network entity, and it is IPv6 addressable, why is it so | bad for that entity to only want to forward a small number of | packets? Nothing wrong with that at all. Certainly nothing I recall saying, or intended to say, was supposed to require any specific ability to handle any particular packet volume. | Q3) Even if such a network entity might have enough memory to run | extra protocols, what if there were a great many of them, each | of which only wanted to handle a few packets, and all of them | had a network interface on a very busy network link so that none | of them wanted to be a default router? Somehow the hosts have to discover where to send the packets. I doubt that manual configuration of the hosts is the answer here (it wouldn't be for the large number of postulated routing devices either, I suspect). However that is to be done, something is going to have to be sending some kind of announcements to the hosts telling them where to send the packets. For this, whether it is ND, or RIP seems to be fairly irrelevant. Since RIP already accomplishes exactly this (and aside from indicating which destinations can be forwarded to the router in question, allows the router to indicate just how good a path it things it has to the destination in question, so the host can select the best of possibly many paths). RIP to me looks like a better fit as a protocol that will supply the relevant information than ND. About all that RIP lacks, and ND has, that might be useful are TTLs. That causes RIP to require protocol assumed TTLs, and consequently a higher packet frequency (the protocol assumed TTL has to be low enough to handle routes that change). This just might be the justification required to invent a new protocol. I certainly don't see that the TTL missing from RIP is any more (or even as) serious as the metric missing from the RA (were it to be extended to this purpose - without that no metric is needed of course). Then there's the question of redirects - the assumption has been that redirects are too hard, somehow, for these devices to issue. There are two issues here - first traffic loads. If, for whatever reason (perhaps a new node that has seen an RA only from the device in question) a host decides that it ought to be sending everything it has to this device, if the device does not redirect, the host will slowly, at best, realise that it has picked a poor default. If it does send a redirect, then it can get rid of most such traffic quite quickly. Then there's the question of where to redirect to. Unless we're assuming a half duplex device here, it is going to have to answer that question for traffic coming the other way in any case - that has to be forwarded somewhere, a redirect would be to wherever packets coming the other way would be sent. In theory that could be a "default router" which the device had been configured to use - and which would then issue its own redirect - but if such a device exists, it will be announcing itself in its RAs as a more preferred router than these other devices, and hosts will be using that as their default router instead of this imagined device - consequently it isn't likely to be required to send many redirects. If the only thing on the net are these devices, then they're going to have to learn about each other somehow, and which packets should go where - knowing that is sufficient to send redirects, and if someone really built a net out of just these devices, that is presumably what they'd want to occur. Now what's left is the case where the devices are half duplex - they take packets and send them, but never return any (and hence don't need to have any clue at all where they would send packets on the net in question if one arrives). There are two cases here - one is where there is no return path at all - hosts on the net in question have send only access (to everywhere, other than the level 2 net in question). Personally I doubt this is a very likely configuration... (no access is possible, send only access seems useless). On the other hand, if there is a router somewhere which can return packets from these outside sources, then it must know the relevant routing information, it can send redirects, and it would be the device to advertise itself as a more preferred router, and hosts could send to it, and be redirected. That would fail only if it also is a half dupplex (incoming) device, unable to receive from the local cable. It seems to me that to get this far we're indulging in flights of fantasy that are unrealistic in the extreme... It is all very well to imagine building baby devices that have just the absolute minimum that could be conceivably be required to function as an IPv6 (or v4) router or host - but actually making the device be able to do anything useful in a practical sense just about always is going to require more than was first imagined (much more for routers than hosts). 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 --------------------------------------------------------------------