From owner-ipng@sunroof.eng.sun.com Mon Oct 1 04:04:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91B4QML001998 for ; Mon, 1 Oct 2001 04:04:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91B4QoO001997 for ipng-dist; Mon, 1 Oct 2001 04:04:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91B4MML001990 for ; Mon, 1 Oct 2001 04:04:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14932 for ; Mon, 1 Oct 2001 04:04:23 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08254 for ; Mon, 1 Oct 2001 04:04:22 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10822; Mon, 1 Oct 2001 07:04:18 -0400 (EDT) Message-Id: <200110011104.HAA10822@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-default-addr-select-06.txt Date: Mon, 01 Oct 2001 07:04:17 -0400 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 : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-06.txt Pages : 22 Date : 28-Sep-01 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-default-addr-select-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-06.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: <20010928122532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-default-addr-select-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010928122532.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 Oct 1 06:23:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91DNEML002091 for ; Mon, 1 Oct 2001 06:23:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91DNEpV002090 for ipng-dist; Mon, 1 Oct 2001 06:23:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91DN9ML002083 for ; Mon, 1 Oct 2001 06:23:09 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f91DN7v11160; Mon, 1 Oct 2001 15:23:07 +0200 (MET DST) Date: Mon, 1 Oct 2001 15:18:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt To: Brian Haberman Cc: Thomas Narten , Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So, since I am the common denominator between the two drafts, I must > claim responsibility. The SSM overview draft should state that > FF3x::/32 is the SSM range for IPv6. But the uni-based document says that everything with a plen=0 is an SSM address, right? So the documents wouldn't be quite consistent even if SSM says FF3X::/32. 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 Mon Oct 1 11:50:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91IouML003131 for ; Mon, 1 Oct 2001 11:50:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91IouGV003130 for ipng-dist; Mon, 1 Oct 2001 11:50:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91IooML003123 for ; Mon, 1 Oct 2001 11:50:51 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f91Iohv18259; Mon, 1 Oct 2001 20:50:44 +0200 (MET DST) Date: Mon, 1 Oct 2001 12:42:28 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt To: Brian Haberman Cc: Thomas Narten , Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <3BB35CFA.DB63556@americasm06.nt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So, since I am the common denominator between the two drafts, I must > claim responsibility. The SSM overview draft should state that > FF3x::/32 is the SSM range for IPv6. But the uni-based document says that everything with a plen=0 is an SSM address, right? So the documents wouldn't be quite consistent even if SSM says FF3X::/32. 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 Mon Oct 1 16:46:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91NkdML003440 for ; Mon, 1 Oct 2001 16:46:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f91NkcGU003439 for ipng-dist; Mon, 1 Oct 2001 16:46:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f91NkZML003432 for ; Mon, 1 Oct 2001 16:46:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29892; Mon, 1 Oct 2001 16:46:37 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05619; Mon, 1 Oct 2001 16:46:37 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA08831; Mon, 1 Oct 2001 16:46:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f91NkW426222; Mon, 1 Oct 2001 16:46:32 -0700 X-mProtect: Mon, 1 Oct 2001 16:46:32 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdB7inc8; Mon, 01 Oct 2001 16:46:29 PDT Message-Id: <4.3.2.7.2.20011001164134.022d3ca8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Oct 2001 16:46:28 -0700 To: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Bob Hinden Subject: Request to Advance "Default Address Selection for IPv6" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, 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 : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-06.txt Pages : 22 Date : 28-Sep-01 A working group last call for this document was completed on June 7, 2001. The "-06" draft was produced in response to comments made during the w.g. last call and subsequent discussion. The document was discussed at the London IETF and the w.g. agreed advancing it to Proposed Standard once the new draft was published. 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 Oct 2 18:16:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f931GUML007403 for ; Tue, 2 Oct 2001 18:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f931GU2p007402 for ipng-dist; Tue, 2 Oct 2001 18:16:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f931GQML007395 for ; Tue, 2 Oct 2001 18:16:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01183 for ; Tue, 2 Oct 2001 18:15:57 -0700 (PDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA19588 for ; Tue, 2 Oct 2001 19:16:58 -0600 (MDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA01499 for ; Wed, 3 Oct 2001 11:14:44 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA21202 for ; Wed, 3 Oct 2001 11:15:50 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 11:15:48 +1000 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ECE7@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: ipng@sunroof.eng.sun.com Cc: "'Richard Draves'" Subject: RE: Request to Advance "Default Address Selection for IPv6" Date: Wed, 3 Oct 2001 11:15:47 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm resending this mail, I think it's still applicable to the latest version. This was sent after the Seattle meeting. Hesham -----Original Message----- From: Erik Nordmark [SMTP:Erik.Nordmark@eng.sun.com] Sent: Tuesday, 5 June 2001 12:23 To: Hesham Soliman (ERA) Cc: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" > Rich, > > Based on our private discussion in Seattle, think it would > be useful to add a sending rule for mapped addresses > as follows: > > - If the destination address is an IPv4-mapped IPv6 address, and > - If the host is an IPv6-only host > the source address MUST be an IPv6-translated address. I think this makes sense as long as we preface it very clearly with Nodes that implement SIIT (does not apply to other nodes) ... Without that preface adding these rules will do nothing but adding confusion. Erik -----Original Message----- From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] Sent: Tuesday, 5 June 2001 8:40 To: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Rich, Based on our private discussion in Seattle, think it would be useful to add a sending rule for mapped addresses as follows: - If the destination address is an IPv4-mapped IPv6 address, and - If the host is an IPv6-only host the source address MUST be an IPv6-translated address. Comments ? Hesham > -----Original Message----- > From: Bob Hinden [SMTP:hinden@iprg.nokia.com] > Sent: Tuesday, 2 October 2001 9:46 > To: Erik.Nordmark@eng.sun.com; narten@raleigh.ibm.com > Cc: scoya@ietf.org; ipng@sunroof.eng.sun.com > Subject: Request to Advance "Default Address Selection for IPv6" > > Erik, 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 : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-06.txt > Pages : 22 > Date : 28-Sep-01 > > A working group last call for this document was completed on June 7, > 2001. The "-06" draft was produced in response to comments made during > the > w.g. last call and subsequent discussion. The document was discussed at > the London IETF and the w.g. agreed advancing it to Proposed Standard once > > the new draft was published. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 3 07:08:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93E88ML008822 for ; Wed, 3 Oct 2001 07:08:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93E88Mw008821 for ipng-dist; Wed, 3 Oct 2001 07:08:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93E83ML008812 for ; Wed, 3 Oct 2001 07:08:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16668 for ; Wed, 3 Oct 2001 07:08:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11423 for ; Wed, 3 Oct 2001 08:08:47 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA24733; Wed, 3 Oct 2001 23:07:41 +0900 (JST) Date: Wed, 03 Oct 2001 23:06:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: , Subject: Re: comments about temp-addresses-v2-00 In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FCD2@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FCD2@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, and sorry for the delayed response... >>>>> On Wed, 19 Sep 2001 12:58:41 -0700, >>>>> "Richard Draves" said: >> Our current implementation checks the duplication at the >> generation of actual addresses as well as at the generation >> of interface identifiers. > In my implementation, I don't do any checks directly on the generated > interface identifier. Instead when I create a temporary address, I check > for known anycast addresses, collisions with existing addresses, etc. If > there is a problem, then I generate a new interface identifier and > repeat. This avoids any timing windows. > This is not quite equivalent to what the draft specifies. For example > suppose an interface A has an EUI-64 based interface identifier IDA and > derived link-local address LIDA. Now interface B is using temporary > addresses with global prefix P and happens to generate interface > identifier IDA. Then my implementation will proceed to create a > temporary address PIDA whereas the draft would prevent interface B from > using IDA. > Is there some reason that the more restrictive behavior specified in the > draft is necessary? Actually, I don't see any strong reason for the restrictive behavior (and that's why I asked this question). I implemented the spec this way just for conformance. So, if there is really no strong reason, I guess the spec can be loosened. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. 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 Wed Oct 3 10:30:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93HUmML009337 for ; Wed, 3 Oct 2001 10:30:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93HUmFh009336 for ipng-dist; Wed, 3 Oct 2001 10:30:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93HUhML009329 for ; Wed, 3 Oct 2001 10:30:43 -0700 (PDT) Received: from marlin.sun.com (vpn-129-150-5-9.EBay.Sun.COM [129.150.5.9]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93HUhBH581857; Wed, 3 Oct 2001 10:30:44 -0700 (PDT) Message-Id: <5.1.0.14.0.20011003102527.00b3c818@jurassic.eng.sun.com> X-Sender: durand@jurassic.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Oct 2001 10:29:01 -0700 To: Bob Hinden , Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com, deering@cisco.com From: Alain Durand Subject: Re: Request to Advance "Default Address Selection for IPv6" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20011001164134.022d3ca8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Steve, I think that the -06 document still does not address the comment I sent to the mailing list right after London IETF. >2. The current draft does longest prefix match on 128 bits. > In the case of a dual-rail network where each hosts has > 2 interfaces > > prefix P1/64 > ------------------------------------------------------ > | h1 | h2 |h3 > ------------------------------------------------------ > prefix P2/64 > > In this case, the choice of network 1 or network 2 depend > on the actual MAC address of the hosts. > This is a situation that is very difficult to understand/debug > by network administrator. > > I would like to suggest to do longest prefix match only on the 64 > most significant bits. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 3 16:25:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NPMML009921 for ; Wed, 3 Oct 2001 16:25:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93NPMuT009920 for ipng-dist; Wed, 3 Oct 2001 16:25:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NPKML009913 for ; Wed, 3 Oct 2001 16:25:20 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f93NMh509773 for ipng@sunroof.eng.sun.com; Wed, 3 Oct 2001 16:22:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PGnZ7B027241 for ; Tue, 25 Sep 2001 09:49:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28874 for ; Tue, 25 Sep 2001 09:49:38 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01927 for ; Tue, 25 Sep 2001 10:50:32 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA07545 for ; Tue, 25 Sep 2001 09:39:55 -0700 (MST)] Received: [from ont14a-bdc.canada.css.mot.com (ont14a-bdc.canada.css.mot.com [199.1.20.72]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA08339 for ; Tue, 25 Sep 2001 09:48:14 -0700 (MST)] Received: by ont14a-bdc.canada.css.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 25 Sep 2001 12:48:09 -0400 Message-ID: <28F1A76E98BDD31189A1009027DE31CF022AAA75@ont14a-bdc.canada.css.mot.com> From: Delecki Andrew-Y10658 To: "'Jari Arkko'" , ipng@sunroof.eng.sun.com Subject: RE: Cellular host requirements, 01 & next steps Date: Tue, 25 Sep 2001 12:47:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C145E1.D3EA9990" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C145E1.D3EA9990 Content-Type: text/plain Hi all, Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1 without any criticism. This text specifies non-compliant with respect to RFC 2462 implementation of the stateless address autoconfiguration, which received heavy criticism from IPNG folks during joint 3GPP-IETF meeting in Seattle (May 31, 2001). The draft represents merely compilation of texts from various sources without any effort to make it consistent across all relevant specifications. At present form, it doesn't represent any valid concept for cellular IPv6 hosts as it absorbs without any criticism deviant implementations of the fundamental concept of IPv6: stateless address autoconfiguration. Andrew Delecki Motorola -----Original Message----- From: Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] Sent: Monday, September 24, 2001 11:08 PM To: ipng@sunroof.eng.sun.com Subject: Cellular host requirements, 01 & next steps Hello, I'd like to announce that we have produced a new version of the cellular host requirements draft. Before it makes to the official I-D directories you can access it at http://standards.ericsson.net/hesham/draft-manyfolks-ipv6-cellular-host-01.txt We appreciate all the input we've gotten on the draft, and have tried to take it all in account in this new version. Further input would also be much appreciated, so keep those comments coming! Also, I'd like to ask the groups' opinion on how to proceed with this work. On a technical level, I feel that most people seem to agree on the main issues though some work of course remains. However, in London we didn't actually decide what to do with this draft. Basically, we'd be interested in getting this work on Standards Track and get it finalized as soon as possible. There is an opportunity for IPv6 in a very large number of hosts, starting from the release 5 of 3GPP. I think we should seize that opportunity - and in a consistent, interoperable manner towards the rest of the IPv6 Internet. One way of helping this to happen is to have an RFC whose support can be required from the terminal devices. How can we get there in the best possible way? Can we get this as an official work item in the WG? Jari Arkko -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C145E1.D3EA9990 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cellular host requirements, 01 & next steps

Hi all,

Appendix A of the draft, uses text from 3GPP TS = 23.060, Clause 9.2.1.1 without any criticism.

This text specifies non-compliant with respect to RFC = 2462 implementation of the stateless address autoconfiguration, which = received heavy criticism from IPNG folks during joint 3GPP-IETF meeting = in Seattle (May 31, 2001).

The draft represents merely compilation of texts from = various sources without any effort to make it consistent across all = relevant specifications.

At present form, it doesn't represent any valid = concept for cellular IPv6 hosts as it absorbs without any criticism = deviant implementations of the fundamental concept of IPv6: stateless = address autoconfiguration.

Andrew Delecki

Motorola




-----Original Message-----
mailto:Jari.Arkko@lmf.ericsso= n.se]
Sent: Monday, September 24, 2001 11:08 PM
To: ipng@sunroof.eng.sun.com
Subject: Cellular host requirements, 01 & next = steps



Hello,

I'd like to announce that we have produced a new = version
of the cellular host requirements draft. Before it = makes
to the official I-D directories you can access it = at

http://standards.ericsson.net/hesham/draft-manyfolks-i= pv6-cellular-host-01.txt

We appreciate all the input we've gotten on the = draft,
and have tried to take it all in account in this = new
version. Further input would also be much = appreciated,
so keep those comments coming!

Also, I'd like to ask the groups' opinion on how = to
proceed with this work. On a technical level, I = feel
that most people seem to agree on the main = issues
though some work of course remains.

However, in London we didn't actually decide what = to
do with this draft.

Basically, we'd be interested in getting this work = on
Standards Track and get it finalized as soon as = possible.
There is an opportunity for IPv6 in a very large = number
of hosts, starting from the release 5 of 3GPP. I = think
we should seize that opportunity - and in a = consistent,
interoperable manner towards the rest of the IPv6 = Internet.
One way of helping this to happen is to have an RFC = whose
support can be required from the terminal devices. = How
can we get there in the best possible way? Can we = get this
as an official work item in the WG?

Jari Arkko
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C145E1.D3EA9990-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 3 16:26:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NQPML009938 for ; Wed, 3 Oct 2001 16:26:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93NQP0x009937 for ipng-dist; Wed, 3 Oct 2001 16:26:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NQNML009930 for ; Wed, 3 Oct 2001 16:26:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f93NNkK09803 for ipng@sunroof.eng.sun.com; Wed, 3 Oct 2001 16:23:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f911jxML001268 for ; Sun, 30 Sep 2001 18:45:59 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06745 for ; Sun, 30 Sep 2001 18:46:02 -0700 (PDT) Received: from cyberlib.itb.ac.id (cyberlib.itb.ac.id [167.205.4.25]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA24767 for ; Sun, 30 Sep 2001 18:45:55 -0700 (PDT) Received: (qmail 50944 invoked by uid 1143); 1 Oct 2001 08:51:36 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Oct 2001 08:51:36 -0000 Date: Mon, 1 Oct 2001 08:51:36 +0000 (GMT) From: "Rendo A.W" To: "Oliver, Michael W." cc: ipng@sunroof.eng.sun.com, 6bone@isi.edu, users@ipv6.org Subject: Re: FreeBSD_4.4 + ipfilter_3.4.20 + IPv6 = headache... In-Reply-To: <1DA741CA6767A144BAA4F10012536C27A8C2@LKLDDC01.GARGANTUAN.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with you, I also failed in make tunnel for ipv6 in FreeBSD 4.4-Stable. The gif interface didn't appear and I can't use stf for tunnelling. Can anyone explain me how to make tunneling in FreeBSD 4.4-Stable ? Thank you and sorry about my poor english. # RENDO A.W >> On Sun, 30 Sep 2001, Oliver, Michael W. wrote: > I realize that this may be somewhat off topic, but please hear me out. I > have been spending the past few days trying to build a FreeBSD 4.4 STABLE > firewall, using the included ipfilter 3.4.20 port, that supports IPv6 > filtering. I have been completely unsuccessful up to now. I have also > bypassed the port and downloaded 3.4.20 from ftp://coombs.anu.edu.au/ and, > following the instructions from a Zama pdf > (ftp://www.zamanetworks.com/pub/knowledgebase/techdocs/Implementing%20an%20I > Pv6%20and%20IPv4%20IPF%20firewall%20on%20FreeBSD%204.2.pdf), tried to > compile. Now, I know that the Zama pdf instructions are for ipfilter > 3.4.16, but that version isn't available anymore. Anyway, the patch fails > when I try to apply it.... > > Has anyone tried this setup yet? I have posted this to the FreeBSD > newsgroups, but I figured that I would send it here also since this may be > too 'out there' for the newsgroups. Thanks in advance! > > --------------- > |* * * *|~~~~~~~| > | * * * |~~~~~~~| Michael Oliver, CCNP oliver.michael@gargantuan.com > |* * * *|~~~~~~~| > |~~~~~~~~~~~~~~~| http://michael.gargantuan.com/ > |~~~~~~~~~~~~~~~| > |~~~~~~~~~~~~~~~| God bless America and all of her patriots. > |~~~~~~~~~~~~~~~| > --------------- > > --------------------------------------------------------------------- > The IPv6 Users Mailing List > Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.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 Wed Oct 3 16:27:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NRLML009955 for ; Wed, 3 Oct 2001 16:27:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93NRLsJ009954 for ipng-dist; Wed, 3 Oct 2001 16:27:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NRIML009947 for ; Wed, 3 Oct 2001 16:27:18 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f93NOf409833 for ipng@sunroof.eng.sun.com; Wed, 3 Oct 2001 16:24:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f931siML007537 for ; Tue, 2 Oct 2001 18:54:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07740 for ; Tue, 2 Oct 2001 18:54:28 -0700 (PDT) Received: from mailcity.com (fes3.whowhere.com [209.185.123.188]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA21541 for ; Tue, 2 Oct 2001 19:54:16 -0600 (MDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Oct 2 18:54:10 2001 To: "Oliver, Michael W." , "Rendo A.W" Date: Wed, 03 Oct 2001 09:54:10 +0800 From: "kim chua" Message-ID: Mime-Version: 1.0 Cc: ipng@sunroof.eng.sun.com, 6bone@isi.edu, users@ipv6.org X-Sent-Mail: off Reply-To: chuakk@lycos.com X-Mailer: MailCity Service Subject: Re: FreeBSD_4.4 + ipfilter_3.4.20 + IPv6 = headache... X-Sender-Ip: 203.115.225.6 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think you need to create gif interface first: ifconfig gif create hope this helps, Chua K K NTT MSC Cyberjaya Malaysia -- On Mon, 1 Oct 2001 08:51:36 Rendo A.W wrote: > >I agree with you, I also failed in make tunnel for ipv6 in FreeBSD >4.4-Stable. The gif interface didn't appear and I can't use stf for >tunnelling. >Can anyone explain me how to make tunneling in FreeBSD 4.4-Stable ? > >Thank you and sorry about my poor english. > ># RENDO A.W >> > >On Sun, 30 Sep 2001, Oliver, Michael W. wrote: > >> I realize that this may be somewhat off topic, but please hear me out. I >> have been spending the past few days trying to build a FreeBSD 4.4 STABLE >> firewall, using the included ipfilter 3.4.20 port, that supports IPv6 >> filtering. I have been completely unsuccessful up to now. I have also >> bypassed the port and downloaded 3.4.20 from ftp://coombs.anu.edu.au/ and, >> following the instructions from a Zama pdf >> (ftp://www.zamanetworks.com/pub/knowledgebase/techdocs/Implementing%20an%20I >> Pv6%20and%20IPv4%20IPF%20firewall%20on%20FreeBSD%204.2.pdf), tried to >> compile. Now, I know that the Zama pdf instructions are for ipfilter >> 3.4.16, but that version isn't available anymore. Anyway, the patch fails >> when I try to apply it.... >> >> Has anyone tried this setup yet? I have posted this to the FreeBSD >> newsgroups, but I figured that I would send it here also since this may be >> too 'out there' for the newsgroups. Thanks in advance! >> >> --------------- >> |* * * *|~~~~~~~| >> | * * * |~~~~~~~| Michael Oliver, CCNP oliver.michael@gargantuan.com >> |* * * *|~~~~~~~| >> |~~~~~~~~~~~~~~~| http://michael.gargantuan.com/ >> |~~~~~~~~~~~~~~~| >> |~~~~~~~~~~~~~~~| God bless America and all of her patriots. >> |~~~~~~~~~~~~~~~| >> --------------- >> >> --------------------------------------------------------------------- >> The IPv6 Users Mailing List >> Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org >> > > >--------------------------------------------------------------------- >The IPv6 Users Mailing List >Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org > Make a difference, help support the relief efforts in the U.S. http://clubs.lycos.com/live/events/september11.asp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 3 16:27:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NRgML009965 for ; Wed, 3 Oct 2001 16:27:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93NRg4L009964 for ipng-dist; Wed, 3 Oct 2001 16:27:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NRdML009957 for ; Wed, 3 Oct 2001 16:27:39 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f93NP2009863 for ipng@sunroof.eng.sun.com; Wed, 3 Oct 2001 16:25:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f933IeML007758 for ; Tue, 2 Oct 2001 20:18:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06414 for ; Tue, 2 Oct 2001 20:18:42 -0700 (PDT) Received: from cyberlib.itb.ac.id (cyberlib.itb.ac.id [167.205.4.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA29969 for ; Tue, 2 Oct 2001 21:19:41 -0600 (MDT) Received: (qmail 12788 invoked by uid 1143); 3 Oct 2001 10:24:03 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Oct 2001 10:24:03 -0000 Date: Wed, 3 Oct 2001 10:24:03 +0000 (GMT) From: "Rendo A.W" To: kim chua cc: "Oliver, Michael W." , ipng@sunroof.eng.sun.com, 6bone@isi.edu, users@ipv6.org Subject: Re: FreeBSD_4.4 + ipfilter_3.4.20 + IPv6 = headache... 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 how could i do that if gif interface didn't exist ? this is the error message root >> ifconfig gif create ifconfig: interface gif does not exist # RENDO A.W >> On Wed, 3 Oct 2001, kim chua wrote: > I think you need to create gif interface first: > > ifconfig gif create > > hope this helps, > > Chua K K > NTT MSC > Cyberjaya > Malaysia > -- > > On Mon, 1 Oct 2001 08:51:36 > Rendo A.W wrote: > > > >I agree with you, I also failed in make tunnel for ipv6 in FreeBSD > >4.4-Stable. The gif interface didn't appear and I can't use stf for > >tunnelling. > >Can anyone explain me how to make tunneling in FreeBSD 4.4-Stable ? > > > >Thank you and sorry about my poor english. > > > ># RENDO A.W >> > > > >On Sun, 30 Sep 2001, Oliver, Michael W. wrote: > > > >> I realize that this may be somewhat off topic, but please hear me out. I > >> have been spending the past few days trying to build a FreeBSD 4.4 STABLE > >> firewall, using the included ipfilter 3.4.20 port, that supports IPv6 > >> filtering. I have been completely unsuccessful up to now. I have also > >> bypassed the port and downloaded 3.4.20 from ftp://coombs.anu.edu.au/ and, > >> following the instructions from a Zama pdf > >> (ftp://www.zamanetworks.com/pub/knowledgebase/techdocs/Implementing%20an%20I > >> Pv6%20and%20IPv4%20IPF%20firewall%20on%20FreeBSD%204.2.pdf), tried to > >> compile. Now, I know that the Zama pdf instructions are for ipfilter > >> 3.4.16, but that version isn't available anymore. Anyway, the patch fails > >> when I try to apply it.... > >> > >> Has anyone tried this setup yet? I have posted this to the FreeBSD > >> newsgroups, but I figured that I would send it here also since this may be > >> too 'out there' for the newsgroups. Thanks in advance! > >> > >> --------------- > >> |* * * *|~~~~~~~| > >> | * * * |~~~~~~~| Michael Oliver, CCNP oliver.michael@gargantuan.com > >> |* * * *|~~~~~~~| > >> |~~~~~~~~~~~~~~~| http://michael.gargantuan.com/ > >> |~~~~~~~~~~~~~~~| > >> |~~~~~~~~~~~~~~~| God bless America and all of her patriots. > >> |~~~~~~~~~~~~~~~| > >> --------------- > >> > >> --------------------------------------------------------------------- > >> The IPv6 Users Mailing List > >> Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org > >> > > > > > >--------------------------------------------------------------------- > >The IPv6 Users Mailing List > >Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org > > > > > Make a difference, help support the relief efforts in the U.S. > http://clubs.lycos.com/live/events/september11.asp > > --------------------------------------------------------------------- > The IPv6 Users Mailing List > Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.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 Wed Oct 3 16:28:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NSAML009988 for ; Wed, 3 Oct 2001 16:28:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93NS9id009987 for ipng-dist; Wed, 3 Oct 2001 16:28:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NS6ML009980 for ; Wed, 3 Oct 2001 16:28:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f93NPTx09893 for ipng@sunroof.eng.sun.com; Wed, 3 Oct 2001 16:25:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93HPnML009318 for ; Wed, 3 Oct 2001 10:25:49 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29544 for ; Wed, 3 Oct 2001 10:25:51 -0700 (PDT) Received: from ouafouaf.tycool.net (ouafouaf.tycool.net [207.20.244.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21782 for ; Wed, 3 Oct 2001 10:25:51 -0700 (PDT) Received: from rouget.tycool.net (localhost [127.0.0.1]) by ouafouaf.tycool.net (8.9.3+Sun/8.9.3) with ESMTP id KAA28535 for ; Wed, 3 Oct 2001 10:22:56 -0700 (PDT) Message-Id: <5.1.0.14.0.20010810030132.01c69f30@jurassic> X-Sender: alain@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Oct 2001 10:25:47 -0700 To: ipng@sunroof.eng.sun.com From: Alain Durand Subject: Source address selection draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I missed this part of the IPng discussion on source address selection/ destination address ordering. There were two points I would have like to make: 1- Some of this text is clearly in the scope of standard track. e.g. deprecated vs non deprecated Some other parts are more questionable, are would better fit in a Best Current Practise (BCP) document. e.g privacy extension, 6to4, other non-native addresses.... We have recently discovered some issues with ISATAP that ended up in modified text in the draft. I'm sure such other similar problems will be discovered in the future. It will be much easier to reissue the BCP part than to modify the complete RFC if it ever reach DS status. So I would have like to re-iterate my suggestion to split the document in two: framework, obvious rules... goes standard track other rules, values in various tables goes BCP 2. The current draft does longest prefix match on 128 bits. In the case of a dual-rail network where each hosts has 2 interfaces prefix P1/64 ------------------------------------------------------ | h1 | h2 |h3 ------------------------------------------------------ prefix P2/64 In this case, the choice of network 1 or network 2 depend on the actual MAC address of the hosts. This is a situation that is very difficult to understand/debug by network administrator. I would like to suggest to do longest prefix match only on the 64 most significant bits. - 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 Oct 3 16:50:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NoLML010234 for ; Wed, 3 Oct 2001 16:50:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f93NoL1t010233 for ipng-dist; Wed, 3 Oct 2001 16:50:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f93NoHML010226 for ; Wed, 3 Oct 2001 16:50:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20641 for ; Wed, 3 Oct 2001 16:50:18 -0700 (PDT) Received: from bsdbox.org (bsdbox.org [66.114.64.95]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA27317 for ; Wed, 3 Oct 2001 17:51:21 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=bsdbox.org ident=lazy) by bsdbox.org with esmtp (Exim 3.30 #1) id 15ovkl-0003oV-00; Wed, 03 Oct 2001 19:48:40 -0400 Message-ID: <3BBBA3D7.537C2599@bsdbox.org> Date: Wed, 03 Oct 2001 19:48:39 -0400 From: lazy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Rendo A.W" CC: kim chua , "Oliver, Michael W." , ipng@sunroof.eng.sun.com, 6bone@isi.edu, users@ipv6.org Subject: Re: FreeBSD_4.4 + ipfilter_3.4.20 + IPv6 = headache... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is it supposed to exist? ;) Check your kernel configuration and make sure you have it enabled, the line should look something similar to: pseudo-device gif 4 // lazy "Rendo A.W" wrote: > > how could i do that if gif interface didn't exist ? > this is the error message > > root >> ifconfig gif create > ifconfig: interface gif does not exist > > # RENDO A.W >> > > On Wed, 3 Oct 2001, kim chua wrote: > > > I think you need to create gif interface first: > > > > ifconfig gif create > > > > hope this helps, > > > > Chua K K > > NTT MSC > > Cyberjaya > > Malaysia > > -- > > > > On Mon, 1 Oct 2001 08:51:36 > > Rendo A.W wrote: > > > > > >I agree with you, I also failed in make tunnel for ipv6 in FreeBSD > > >4.4-Stable. The gif interface didn't appear and I can't use stf for > > >tunnelling. > > >Can anyone explain me how to make tunneling in FreeBSD 4.4-Stable ? > > > > > >Thank you and sorry about my poor english. > > > > > ># RENDO A.W >> > > > > > >On Sun, 30 Sep 2001, Oliver, Michael W. wrote: > > > > > >> I realize that this may be somewhat off topic, but please hear me out. I > > >> have been spending the past few days trying to build a FreeBSD 4.4 STABLE > > >> firewall, using the included ipfilter 3.4.20 port, that supports IPv6 > > >> filtering. I have been completely unsuccessful up to now. I have also > > >> bypassed the port and downloaded 3.4.20 from ftp://coombs.anu.edu.au/ and, > > >> following the instructions from a Zama pdf > > >> (ftp://www.zamanetworks.com/pub/knowledgebase/techdocs/Implementing%20an%20I > > >> Pv6%20and%20IPv4%20IPF%20firewall%20on%20FreeBSD%204.2.pdf), tried to > > >> compile. Now, I know that the Zama pdf instructions are for ipfilter > > >> 3.4.16, but that version isn't available anymore. Anyway, the patch fails > > >> when I try to apply it.... > > >> > > >> Has anyone tried this setup yet? I have posted this to the FreeBSD > > >> newsgroups, but I figured that I would send it here also since this may be > > >> too 'out there' for the newsgroups. Thanks in advance! > > >> > > >> --------------- > > >> |* * * *|~~~~~~~| > > >> | * * * |~~~~~~~| Michael Oliver, CCNP oliver.michael@gargantuan.com > > >> |* * * *|~~~~~~~| > > >> |~~~~~~~~~~~~~~~| http://michael.gargantuan.com/ > > >> |~~~~~~~~~~~~~~~| > > >> |~~~~~~~~~~~~~~~| God bless America and all of her patriots. > > >> |~~~~~~~~~~~~~~~| > > >> --------------- > > >> > > >> --------------------------------------------------------------------- > > >> The IPv6 Users Mailing List > > >> Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org > > >> > > > > > > > > >--------------------------------------------------------------------- > > >The IPv6 Users Mailing List > > >Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org > > > > > > > > > Make a difference, help support the relief efforts in the U.S. > > http://clubs.lycos.com/live/events/september11.asp > > > > --------------------------------------------------------------------- > > The IPv6 Users Mailing List > > Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.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 > -------------------------------------------------------------------- -- ..:: Too many people... Too few neurons. PGP: RSA 2048bit 0xB7673053 (keyserver.pgp.com) Web: http://packetjunkie.net http://bsdbox.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 Wed Oct 3 17:13:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f940DSML010275 for ; Wed, 3 Oct 2001 17:13:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f940DSCG010274 for ipng-dist; Wed, 3 Oct 2001 17:13:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f940DOML010267 for ; Wed, 3 Oct 2001 17:13:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17284 for ; Wed, 3 Oct 2001 17:13:26 -0700 (PDT) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25819 for ; Wed, 3 Oct 2001 17:13:25 -0700 (PDT) Received: from jariws1 ([62.248.238.237]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011004001324.LZJM1085.fep06-app.kolumbus.fi@jariws1>; Thu, 4 Oct 2001 03:13:24 +0300 Message-ID: <00a201c14c69$6e9dd8c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Delecki Andrew-Y10658" , "'Jari Arkko'" , References: <28F1A76E98BDD31189A1009027DE31CF022AAA75@ont14a-bdc.canada.css.mot.com> Subject: Re: Cellular host requirements, 01 & next steps Date: Thu, 4 Oct 2001 03:13:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RE: Cellular host requirements, 01 & next stepsHi Andrew, > Appendix A of the draft, uses text from 3GPP TS > 23.060, Clause 9.2.1.1 without any criticism. Yes we do reference the current 3GPP specs. We are also quite aware of the criticism of the specs, and we support the process on making the 3GPP specifications better. However, there already is a design team in place in this WG to produce such improvement proposals. Are you aware of this effort? Design team, can you comment on how you are proceeding? But back to our draft. The 3GPP specifications come in "Releases", and the improvements affect only the future releases, not the old ones. Also, appendix A is there for information - to avoid the need to find the 3GPP specs - and to allow us to explain the special case under 2.5.1 and 2.6.1. (We propably should have made clearer that there's a difference to the IPv6 standard way.) The purpose of our draft is primarily to describe what cellular hosts in general need to do wrt IPv6. In addition to this, we want to provide concrete examples on particular cellular networks and their problems, insofar as that information exists today. The example part is more like "here's how your run IPv6 on X" rather than "let's design the best possible Y to run IPv6". However, you are right in the sense that we should propably more clearly highlight the issue in the draft, and indicate that the specific examples that apply to 3GPP are relevant for a particular version (Release 99), and future versions may have a different situation. Hope this clarifies the situation, Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 3 17:28:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f940SZML010294 for ; Wed, 3 Oct 2001 17:28:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f940SZpF010293 for ipng-dist; Wed, 3 Oct 2001 17:28:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f940SVML010286 for ; Wed, 3 Oct 2001 17:28:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27349 for ; Wed, 3 Oct 2001 17:28:34 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00377 for ; Wed, 3 Oct 2001 17:28:33 -0700 (PDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f940Sr716219 for ; Wed, 3 Oct 2001 19:28:53 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Oct 2001 19:28:32 -0500 content-class: urn:content-classes:message Subject: RE: Cellular host requirements, 01 & next steps Date: Wed, 3 Oct 2001 19:28:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cellular host requirements, 01 & next steps X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcFMaZjBujl2RrhZEdWpWgBQi2kYTQAAIYrQ From: "Soininen Jonne (NET/MtView)" To: "'ext Jari Arkko'" , "Delecki Andrew-Y10658" , "'Jari Arkko'" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f940SWML010287 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Andrew and Jari, >However, there already is a design team in place >in this WG to produce such improvement proposals. >Are you aware of this effort? Design team, can >you comment on how you are proceeding? Yes, the design team is looking at this problem. I think we are about to get ready in the near future, and the document will be out for WG to comment. Thus, I do not think that the cellular requirements document should address this issue. Cheers, Jonne. -----Original Message----- From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Wednesday, October 03, 2001 5:14 PM To: Delecki Andrew-Y10658; 'Jari Arkko'; ipng@sunroof.eng.sun.com Subject: Re: Cellular host requirements, 01 & next steps RE: Cellular host requirements, 01 & next stepsHi Andrew, > Appendix A of the draft, uses text from 3GPP TS > 23.060, Clause 9.2.1.1 without any criticism. Yes we do reference the current 3GPP specs. We are also quite aware of the criticism of the specs, and we support the process on making the 3GPP specifications better. However, there already is a design team in place in this WG to produce such improvement proposals. Are you aware of this effort? Design team, can you comment on how you are proceeding? But back to our draft. The 3GPP specifications come in "Releases", and the improvements affect only the future releases, not the old ones. Also, appendix A is there for information - to avoid the need to find the 3GPP specs - and to allow us to explain the special case under 2.5.1 and 2.6.1. (We propably should have made clearer that there's a difference to the IPv6 standard way.) The purpose of our draft is primarily to describe what cellular hosts in general need to do wrt IPv6. In addition to this, we want to provide concrete examples on particular cellular networks and their problems, insofar as that information exists today. The example part is more like "here's how your run IPv6 on X" rather than "let's design the best possible Y to run IPv6". However, you are right in the sense that we should propably more clearly highlight the issue in the draft, and indicate that the specific examples that apply to 3GPP are relevant for a particular version (Release 99), and future versions may have a different situation. Hope this clarifies the situation, Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 4 06:54:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94DsWML012268 for ; Thu, 4 Oct 2001 06:54:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94DsWxe012267 for ipng-dist; Thu, 4 Oct 2001 06:54:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94DsQML012260 for ; Thu, 4 Oct 2001 06:54:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20537 for ; Thu, 4 Oct 2001 06:54:27 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03925 for ; Thu, 4 Oct 2001 07:54:16 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA00883 for ; Thu, 4 Oct 2001 06:54:26 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA15478 for ; Thu, 4 Oct 2001 06:45:36 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Thu, 4 Oct 2001 06:54:25 -0700 Received: from crm.mot.com (durga.crm.mot.com [140.101.173.45]) by thorgal.crm.mot.com (Postfix) with ESMTP id EFC912ED24; Thu, 4 Oct 2001 15:50:41 +0200 (CEST) Message-Id: <3BBC6A0D.3040E7EF@crm.mot.com> Date: Thu, 04 Oct 2001 15:54:21 +0200 From: Alexandru Petrescu Reply-To: "alexandru.petrescu" Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Delecki Andrew-Y10658 Cc: "'Jari Arkko'" , ipng@sunroof.eng.sun.com Subject: Re: Cellular host requirements, 01 & next steps References: <28F1A76E98BDD31189A1009027DE31CF022AAA75@ont14a-bdc.canada.css.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1 > without any criticism. The funniest thing of the 3GPP "stateless autoconf" is that GGSN provides the "unique interface identifier" (an equivalent of an EUI-64) to the mobile as if the mobile would not know its own unique ID. OTOH, I can understand this if 3GPP considers there'll be a sort of "tunnel" between mobile and GGSN, like in PPP. But in that case they just can't state this is stateless autoconf. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 4 07:41:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EfJML012546 for ; Thu, 4 Oct 2001 07:41:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94EfJTO012545 for ipng-dist; Thu, 4 Oct 2001 07:41:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94EfDML012529 for ; Thu, 4 Oct 2001 07:41:13 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26440 for ; Thu, 4 Oct 2001 07:41:14 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23251 for ; Thu, 4 Oct 2001 07:41:11 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f94Ef9C25365; Thu, 4 Oct 2001 16:41:09 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA21335; Thu, 4 Oct 2001 16:41:09 +0200 Message-ID: <3BBC7472.100B1BE2@era.ericsson.se> Date: Thu, 04 Oct 2001 16:38:42 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "alexandru.petrescu" CC: Delecki Andrew-Y10658 , "'Jari Arkko'" , ipng@sunroof.eng.sun.com Subject: Re: Cellular host requirements, 01 & next steps References: <28F1A76E98BDD31189A1009027DE31CF022AAA75@ont14a-bdc.canada.css.mot.com> <3BBC6A0D.3040E7EF@crm.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexandru Petrescu wrote: > > > Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1 > > without any criticism. > > The funniest thing of the 3GPP "stateless autoconf" is that GGSN > provides the "unique interface identifier" (an equivalent of an EUI-64) > to the mobile as if the mobile would not know its own unique ID. The reason for this, AFAIK, is to get rid of DAD on the GGSN side. If the GGSN hands out IDs from a pool it can easily keep control of what IDs are unused and DAD becomes a simple task. On the other hand, if the GGSN was to do real DAD, it would have to scan a probably *huge* address space to detect collisions, as the GGSN is the only node that knows all the addresses used since the terminals never talk directly to each other. /Mattias > > OTOH, I can understand this if 3GPP considers there'll be a sort > of "tunnel" between mobile and GGSN, like in PPP. But in that > case they just can't state this is stateless autoconf. > > Alex > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 4 08:30:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94FU7ML012952 for ; Thu, 4 Oct 2001 08:30:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94FU76s012951 for ipng-dist; Thu, 4 Oct 2001 08:30:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94FU3ML012941 for ; Thu, 4 Oct 2001 08:30:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13027 for ; Thu, 4 Oct 2001 08:30:01 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25953 for ; Thu, 4 Oct 2001 09:29:50 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f94FUK712809 for ; Thu, 4 Oct 2001 10:30:20 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Oct 2001 10:29:59 -0500 content-class: urn:content-classes:message Subject: RE: Cellular host requirements, 01 & next steps Date: Thu, 4 Oct 2001 10:29:58 -0500 Message-ID: MIME-Version: 1.0 X-MS-Has-Attach: Content-Type: text/plain; charset="iso-8859-1" X-MS-TNEF-Correlator: Thread-Topic: Cellular host requirements, 01 & next steps Thread-Index: AcFM4w+ajHwXzrjUEdWJUwAIx6TWpQABZZ4A X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Soininen Jonne (NET/MtView)" To: "'ext Mattias Pettersson'" , "alexandru.petrescu" Cc: "Delecki Andrew-Y10658" , "'Jari Arkko'" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f94FU4ML012942 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mattias and Alexandru, as Mattias states it is important that GGSN does not have to do DAD. Thus, the same method is used as with PPPv6. In addition, there is nothing in the mobile that could reliably be used as the interface identifier. Especially, as the mobile can actually have many PDP Contexts open with different IP Addresses. Cheers, Jonne. -----Original Message----- From: ext Mattias Pettersson [mailto:mattias.pettersson@era.ericsson.se] Sent: Thursday, October 04, 2001 7:39 AM To: alexandru.petrescu Cc: Delecki Andrew-Y10658; 'Jari Arkko'; ipng@sunroof.eng.sun.com Subject: Re: Cellular host requirements, 01 & next steps Alexandru Petrescu wrote: > > > Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1 > > without any criticism. > > The funniest thing of the 3GPP "stateless autoconf" is that GGSN > provides the "unique interface identifier" (an equivalent of an EUI-64) > to the mobile as if the mobile would not know its own unique ID. The reason for this, AFAIK, is to get rid of DAD on the GGSN side. If the GGSN hands out IDs from a pool it can easily keep control of what IDs are unused and DAD becomes a simple task. On the other hand, if the GGSN was to do real DAD, it would have to scan a probably *huge* address space to detect collisions, as the GGSN is the only node that knows all the addresses used since the terminals never talk directly to each other. /Mattias > > OTOH, I can understand this if 3GPP considers there'll be a sort > of "tunnel" between mobile and GGSN, like in PPP. But in that > case they just can't state this is stateless autoconf. > > Alex > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 4 09:11:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94GBqML013201 for ; Thu, 4 Oct 2001 09:11:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94GBqXv013200 for ipng-dist; Thu, 4 Oct 2001 09:11:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94GBmML013193 for ; Thu, 4 Oct 2001 09:11:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22222 for ; Thu, 4 Oct 2001 09:11:50 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21664 for ; Thu, 4 Oct 2001 09:11:50 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA16795 for ; Thu, 4 Oct 2001 09:11:49 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA11037 for ; Thu, 4 Oct 2001 09:11:49 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Thu, 4 Oct 2001 09:11:48 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 12F352ED2F; Thu, 4 Oct 2001 18:08:05 +0200 (CEST) To: Mattias Pettersson Cc: Delecki Andrew-Y10658 , "'Jari Arkko'" , Subject: Re: Cellular host requirements, 01 & next steps References: <28F1A76E98BDD31189A1009027DE31CF022AAA75@ont14a-bdc.canada.css.mot.com> <3BBC6A0D.3040E7EF@crm.mot.com> <3BBC7472.100B1BE2@era.ericsson.se> From: Alexandru Petrescu Date: 04 Oct 2001 20:11:40 +0200 In-Reply-To: <3BBC7472.100B1BE2@era.ericsson.se> Message-Id: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mattias Pettersson writes: > Alexandru Petrescu wrote: > > > > > Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1 > > > without any criticism. > > > > The funniest thing of the 3GPP "stateless autoconf" is that GGSN > > provides the "unique interface identifier" (an equivalent of an EUI-64) > > to the mobile as if the mobile would not know its own unique ID. > > The reason for this, AFAIK, is to get rid of DAD on the GGSN side. If > the GGSN hands out IDs from a pool it can easily keep control of what > IDs are unused and DAD becomes a simple task. Mattias, thank you for your remarks. It looks to me that the whole autoconf/DAD idea has been designed with a shared medium in mind. However, I understand this "shareness" at level 3, and not lower. It's probably possible to design a 3GPP L2 under IP that makes an "unshared" L1/2 look like a "shared" media to IP. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 4 12:36:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94JaCML014026 for ; Thu, 4 Oct 2001 12:36:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94JaBeg014025 for ipng-dist; Thu, 4 Oct 2001 12:36:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94Ja2ML014018 for ; Thu, 4 Oct 2001 12:36:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19515 for ; Thu, 4 Oct 2001 12:36:04 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02180 for ; Thu, 4 Oct 2001 13:37:08 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f94Ja6w15157 for ; Thu, 4 Oct 2001 14:36:06 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Oct 2001 14:35:59 -0500 content-class: urn:content-classes:message Subject: RE: Cellular host requirements, 01 & next steps Date: Thu, 4 Oct 2001 14:35:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cellular host requirements, 01 & next steps Thread-Index: AcFM8Es4aeNVSrjhEdWpWgBQi2kYTQAGoPWQ X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Soininen Jonne (NET/MtView)" To: "'ext Alexandru Petrescu'" , "Mattias Pettersson" Cc: "Delecki Andrew-Y10658" , "'Jari Arkko'" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f94Ja6ML014019 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alex, I think this is general question on behavior on point-to-point links - not 3GPP specifically. I would guess that other links that share the same characteristics, e.g. modem links, have the same problems on the address autoconfig/DAD. Anyways, I guess the issues of GPRS L1/L2 should be left for 3GPP to decide. I do not think we can fix any issues on design decisions of GPRS link-characteristics here. Cheers, Jonne. -----Original Message----- From: ext Alexandru Petrescu [mailto:petrescu@crm.mot.com] Sent: Thursday, October 04, 2001 11:12 AM To: Mattias Pettersson Cc: Delecki Andrew-Y10658; 'Jari Arkko'; ipng@sunroof.eng.sun.com Subject: Re: Cellular host requirements, 01 & next steps Mattias Pettersson writes: > Alexandru Petrescu wrote: > > > > > Appendix A of the draft, uses text from 3GPP TS 23.060, Clause 9.2.1.1 > > > without any criticism. > > > > The funniest thing of the 3GPP "stateless autoconf" is that GGSN > > provides the "unique interface identifier" (an equivalent of an EUI-64) > > to the mobile as if the mobile would not know its own unique ID. > > The reason for this, AFAIK, is to get rid of DAD on the GGSN side. If > the GGSN hands out IDs from a pool it can easily keep control of what > IDs are unused and DAD becomes a simple task. Mattias, thank you for your remarks. It looks to me that the whole autoconf/DAD idea has been designed with a shared medium in mind. However, I understand this "shareness" at level 3, and not lower. It's probably possible to design a 3GPP L2 under IP that makes an "unshared" L1/2 look like a "shared" media to IP. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 4 16:24:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94NOIML014589 for ; Thu, 4 Oct 2001 16:24:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f94NOIBb014588 for ipng-dist; Thu, 4 Oct 2001 16:24:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94NOEML014581 for ; Thu, 4 Oct 2001 16:24:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17839 for ; Thu, 4 Oct 2001 16:24:17 -0700 (PDT) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25883 for ; Thu, 4 Oct 2001 17:25:22 -0600 (MDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel2.hp.com (Postfix) with ESMTP id E1010183A for ; Thu, 4 Oct 2001 19:24:15 -0400 (EDT) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id D544F1F514 for ; Thu, 4 Oct 2001 19:24:15 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 19:24:15 -0400 Message-ID: From: "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" To: ipng@sunroof.eng.sun.com Subject: Question on Site-Local-Addressing Date: Thu, 4 Oct 2001 19:23:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi ! With reference to "site-local-addresses", what is the definition of a "site"? Are two nodes in two different sites because of the configuration of routing on the Routers in between them OR BGP running on a Router in between them OR through address allocation mechanisms OR some other mechanism? In particular, I would like to know how to determine if a given "site-local-address" belongs to the same site as mine (i.e., my node). Is it possible to tell by looking at the addresses of "my node" and the "given site-local-address"? Sorry, if this is a silly question. Thanks in advance for your help. Best Regards, Swamy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 5 00:45:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f957jtML015052 for ; Fri, 5 Oct 2001 00:45:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f957jtV0015051 for ipng-dist; Fri, 5 Oct 2001 00:45:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f957jpML015044 for ; Fri, 5 Oct 2001 00:45:51 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21154 for ; Fri, 5 Oct 2001 00:45:52 -0700 (PDT) Received: from HKISRV06.teleware.fi (mail.teleware.fi [193.65.76.33]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25143 for ; Fri, 5 Oct 2001 00:45:50 -0700 (PDT) Received: from hkisrv08.teleware.fi ([10.204.2.28]) by HKISRV06.teleware.fi with Microsoft SMTPSVC(5.0.2195.1600); Fri, 5 Oct 2001 10:45:05 +0300 content-class: urn:content-classes:message Subject: RE: Question on Site-Local-Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 5 Oct 2001 10:45:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Site-Local-Addressing Thread-Index: AcFNLA+A5eo+nDItTh+mwuGCIs5OZAAQ0DwA From: "Anssi Porttikivi" To: "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" , X-OriginalArrivalTime: 05 Oct 2001 07:45:05.0440 (UTC) FILETIME=[A5FABA00:01C14D71] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f957jqML015045 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk That has been discussed, and is generally confusing. The confusing idea is that unicast "site" scope and all multicast scopes (which are basically defined separately from unicast scopes) with bigger number than 3 (subnet-local) but smaller than hex E "global" are administratively configured, i.e. your routers will look at the multicast packets and send them wherever your multicast routing protocols are administered to forward them. >From http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-02.tx t - Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site). And From ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-06.txt (Multicast scopes:) 0 reserved 1 interface-local scope 2 link-local scope 3 subnet-local scope 4 admin-local scope 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope F reserved -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 5 01:14:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f958EaML015115 for ; Fri, 5 Oct 2001 01:14:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f958EZoo015114 for ipng-dist; Fri, 5 Oct 2001 01:14:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f958EVML015107 for ; Fri, 5 Oct 2001 01:14:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24013 for ; Fri, 5 Oct 2001 01:14:35 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17069 for ; Fri, 5 Oct 2001 01:14:34 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id BAA29966 for ; Fri, 5 Oct 2001 01:14:34 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id BAA17353 for ; Fri, 5 Oct 2001 01:14:33 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Fri, 5 Oct 2001 03:14:23 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 97D7E2ED24; Fri, 5 Oct 2001 10:10:45 +0200 (CEST) X-Gnus-Agent-Meta-Information: mail nil To: "Soininen Jonne (NET/MtView)" Cc: "'ext Mattias Pettersson'" , "Delecki Andrew-Y10658" , "'Jari Arkko'" , Subject: Re: Cellular host requirements, 01 & next steps References: From: Alexandru Petrescu Date: 05 Oct 2001 02:10:35 +0200 In-Reply-To: Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 Lines: 24 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 f958EWML015108 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Soininen Jonne (NET/MtView)" writes: > as Mattias states it is important that GGSN does not have to do DAD. Hi Jonne. At first I thought I misunderstood what Mattias wrote; but now that you re-state it, I really don't understand: is GGSN involved when mobile does DAD? Or I might have a totally different mental model of it. > Especially, as the mobile can actually have many PDP Contexts open > with different IP Addresses. Is there any effort somewhere that tries to "flatten" those underlying channels into an entity that could present itself as a "shared" medium to the above IP (and not channels; I understand channels lend themselves to Point-to-Point approaches)? Thanks for any info. I think it's that entity's address that could lead to a unique ID. Again, in my understanding, the whole point of a node doing DAD is that it doesn't have to obtain that address from a central server. Automagic à la Apple. Distributed. But, if the mobile is required to get something from a server and required not to do DAD, then why not getting the whole address from the GGSN? Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 5 01:39:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f958dBML015226 for ; Fri, 5 Oct 2001 01:39:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f958dBRV015225 for ipng-dist; Fri, 5 Oct 2001 01:39:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f958d7ML015216 for ; Fri, 5 Oct 2001 01:39:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23480 for ; Fri, 5 Oct 2001 01:39:11 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25389 for ; Fri, 5 Oct 2001 01:39:11 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id BAA20487 for ; Fri, 5 Oct 2001 01:39:10 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id BAA03241 for ; Fri, 5 Oct 2001 01:39:10 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Fri, 5 Oct 2001 03:39:09 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id EB7102ED2F; Fri, 5 Oct 2001 10:35:23 +0200 (CEST) To: "Soininen Jonne (NET/MtView)" Cc: "Mattias Pettersson" , "Delecki Andrew-Y10658" , "'Jari Arkko'" , Subject: Re: Cellular host requirements, 01 & next steps References: From: Alexandru Petrescu Date: 05 Oct 2001 12:39:00 +0200 In-Reply-To: Message-Id: Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Soininen Jonne (NET/MtView)" writes: > Anyways, I guess the issues of GPRS L1/L2 should be left for 3GPP to > decide. I do not think we can fix any issues on design decisions of GPRS > link-characteristics here. That's correct, this is not to be discussed here. Thanks for all your remarks, very useful for my understanding, Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 5 09:21:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95GLRML015828 for ; Fri, 5 Oct 2001 09:21:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f95GLRgd015827 for ipng-dist; Fri, 5 Oct 2001 09:21:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95GLNML015820 for ; Fri, 5 Oct 2001 09:21:23 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03607 for ; Fri, 5 Oct 2001 09:21:22 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12816 for ; Fri, 5 Oct 2001 09:21:17 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 05 Oct 2001 09:21:04 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 801933A49DDE487AA31888F4FDE58797 for plus 2 more; Fri, 05 Oct 2001 09:21:04 -0700 From: "Tony Hain" To: "Anssi Porttikivi" , "MANDAVILLI,SWAMY J \(HP-FtCollins,ex1\)" , Subject: RE: Question on Site-Local-Addressing Date: Fri, 5 Oct 2001 09:21:04 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 Importance: Normal In-Reply-To: X-SLUIDL: 9ABBC178-C6D74075-859F4E84-06323B75 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anssi Porttikivi wrote: > ... A personal > residence may be treated as a site (for example, when the > residence obtains Internet access via a public Internet > service provider), or as a part of a site (for example, > when the residence obtains Internet access via an > employer's or school's site). To be precise, Internet access is orthogonal to the definition of site-local. > - Site-local scope, for uniquely identifying interfaces > within a single site only. A "site" is, by intent, not > rigorously defined, but is typically expected to cover a > region of topology that belongs to a single organization > and is located within a single geographic location, such > as an office, an office complex, or a campus. This part is sufficient. 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 Fri Oct 5 15:29:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95MTqML016596 for ; Fri, 5 Oct 2001 15:29:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f95MTq28016595 for ipng-dist; Fri, 5 Oct 2001 15:29:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95MTWML016588 for ; Fri, 5 Oct 2001 15:29:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06523 for ; Fri, 5 Oct 2001 15:29:33 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA29312 for ; Fri, 5 Oct 2001 16:29:21 -0600 (MDT) Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Oct 2001 15:27:42 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 5 Oct 2001 15:27:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request to Advance "Default Address Selection for IPv6" Date: Fri, 5 Oct 2001 15:27:41 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FD10@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to Advance "Default Address Selection for IPv6" Thread-Index: AcFMMgZnCBZznbPsTYKrcvpcEpef4gBuR5Qg From: "Richard Draves" To: "Alain Durand" Cc: , "Bob Hinden" , , , X-OriginalArrivalTime: 05 Oct 2001 22:27:42.0062 (UTC) FILETIME=[F295F8E0:01C14DEC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f95MTYML016589 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that the -06 document still does not address the > comment I sent to > the mailing list > right after London IETF. I did not see that comment, but I remember that you raised this issue at the Redmond interim meeting, along with the related issue of ISATAP/6over4 subnets being preferred over native subnets. I followed Erik's suggestion and added rule 7 in section 5 (destination address ordering) to fix these issues. > >2. The current draft does longest prefix match on 128 bits. > > In the case of a dual-rail network where each hosts has > > 2 interfaces > > > > prefix P1/64 > > ------------------------------------------------------ > > | h1 | h2 |h3 > > ------------------------------------------------------ > > prefix P2/64 > > > > In this case, the choice of network 1 or network 2 depend > > on the actual MAC address of the hosts. > > This is a situation that is very difficult to understand/debug > > by network administrator. > > > > I would like to suggest to do longest prefix match only > on the 64 > > most significant bits. If there is some reason to prefer the P1 network over the P2 network (maybe one is faster/better than the other?), then I think rule 7 is the way to accomplish it. The administrator should give interfaces on the two networks different preferences or metrics. I'm a bit reluctant to build in the constant 64. Admittedly it's already a magic number for IPv6, but I'm not excited about embedding knowledge of it in yet another place. If we do change the draft to cut-off longest-prefix matching at 64 bits, then it would not necessarily lead to predictable behavior in your scenario. The choice of P1 vs P2 would then come down to the order in which destination addresses are returned from DNS, which may or may not be predictable depending on the DNS servers and how the addresses are put into the DNS. This is why I think rule 7 is the better solution for the administrator in your scenario. 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 Fri Oct 5 15:38:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95McSML016657 for ; Fri, 5 Oct 2001 15:38:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f95McSjh016656 for ipng-dist; Fri, 5 Oct 2001 15:38:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95McQML016649 for ; Fri, 5 Oct 2001 15:38:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f95MZki18731 for ipng@sunroof.eng.sun.com; Fri, 5 Oct 2001 15:35:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f94KxfML014316 for ; Thu, 4 Oct 2001 13:59:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11992 for ; Thu, 4 Oct 2001 13:59:41 -0700 (PDT) Received: from localhost.localdomain (h201.s231.netsol.com [216.168.231.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13476 for ; Thu, 4 Oct 2001 14:59:29 -0600 (MDT) Received: (from pete@localhost) by localhost.localdomain (8.11.6/8.11.6) id f94KvbD03648; Thu, 4 Oct 2001 16:57:37 -0400 Date: Thu, 4 Oct 2001 16:57:37 -0400 From: Pete Toscano To: "Rendo A.W" Cc: lazy , kim chua , "Oliver, Michael W." , ipng@sunroof.eng.sun.com, 6bone@ISI.EDU, users@ipv6.org Subject: Re: FreeBSD_4.4 + ipfilter_3.4.20 + IPv6 = headache... Message-ID: <20011004165737.C3547@tesla.admin.cto.netsol.com> Mail-Followup-To: "Rendo A.W" , lazy , kim chua , "Oliver, Michael W." , ipng@sunroof.eng.sun.com, 6bone@ISI.EDU, users@ipv6.org References: <3BBBA3D7.537C2599@bsdbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BBBA3D7.537C2599@bsdbox.org> User-Agent: Mutt/1.3.20i X-Uptime: 4:39pm up 7 days, 23:08, 6 users, load average: 0.00, 0.03, 0.00 X-Married: 690 days, 19 hours, 54 minutes, and 1 seconds Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ah, my friends, I encountered the same problem back when I made my FreeBSD IPv6 firewall and I have your answer. =8] Somewhere around about that 4.3-to-4.4 cutover time, the kernel was changed to not automatically create the gif interfaces. You need to use the gifconfig command. The tip-off for me was some changes in /etc/defaults/rc.conf. Grep through /etc/defaults/rc.conf for gif. Okay, I'll do that for you. This is what you get: ==================== gif_interfaces="NO" # List of GIF tunnels (or "NO"). #gif_interfaces="gif0 gif1" # Examples typically for a router. #gifconfig_gif0="10.1.1.1 10.1.2.1" # Examples typically for a router. #gifconfig_gif1="10.1.1.2 10.1.2.2" # Examples typically for a router. ==================== Ah-ha! I added something very similar to my /etc/rc.conf file and everything was good. Well, everything with respect to the gif interface problems. Here's sort of what I added: ==================== gif_interfaces="gif0" gifconfig_gif0="m1.m2.m3.m4 b1.b2.b3.b4" ipv6_ifconfig_gif0="3ffe:mX::mY:0:0:e 3ffe:bX::bY:0:0:d prefixlen 128" ==================== The first two lines are used to create the gif interfaces and configure their IPv4 end-points. Add as many gif interfaces to gif_interfaces as you need and for each one, add a gifconfig_gifX line (X >= 0). The first IPv4 address is mine, the second is the address at the other end of the tunnel. The third line (IPv6) configures the gif interface. (Actually, this isn't specific to the gif interface, but for the sake of being complete...) Upon restart, the interfaces all started up fine. HTH, pete On Wed, 03 Oct 2001, lazy wrote: > Is it supposed to exist? ;) > > Check your kernel configuration and make sure you > have it enabled, the line should look something > similar to: > pseudo-device gif 4 > > // lazy > > > "Rendo A.W" wrote: > > > > how could i do that if gif interface didn't exist ? > > this is the error message > > > > root >> ifconfig gif create > > ifconfig: interface gif does not exist > > > > # RENDO A.W >> > > > > On Wed, 3 Oct 2001, kim chua wrote: > > > > > I think you need to create gif interface first: > > > > > > ifconfig gif create > > > > > > hope this helps, > > > > > > Chua K K > > > NTT MSC > > > Cyberjaya > > > Malaysia > > > -- > > > > > > On Mon, 1 Oct 2001 08:51:36 > > > Rendo A.W wrote: > > > > > > > >I agree with you, I also failed in make tunnel for ipv6 in FreeBSD > > > >4.4-Stable. The gif interface didn't appear and I can't use stf for > > > >tunnelling. > > > >Can anyone explain me how to make tunneling in FreeBSD 4.4-Stable ? > > > > > > > >Thank you and sorry about my poor english. > > > > > > > ># RENDO A.W >> > > > > > > > >On Sun, 30 Sep 2001, Oliver, Michael W. wrote: > > > > > > > >> I realize that this may be somewhat off topic, but please hear me out. I > > > >> have been spending the past few days trying to build a FreeBSD 4.4 STABLE > > > >> firewall, using the included ipfilter 3.4.20 port, that supports IPv6 > > > >> filtering. I have been completely unsuccessful up to now. I have also > > > >> bypassed the port and downloaded 3.4.20 from ftp://coombs.anu.edu.au/ and, > > > >> following the instructions from a Zama pdf > > > >> (ftp://www.zamanetworks.com/pub/knowledgebase/techdocs/Implementing%20an%20I > > > >> Pv6%20and%20IPv4%20IPF%20firewall%20on%20FreeBSD%204.2.pdf), tried to > > > >> compile. Now, I know that the Zama pdf instructions are for ipfilter > > > >> 3.4.16, but that version isn't available anymore. Anyway, the patch fails > > > >> when I try to apply it.... > > > >> > > > >> Has anyone tried this setup yet? I have posted this to the FreeBSD > > > >> newsgroups, but I figured that I would send it here also since this may be > > > >> too 'out there' for the newsgroups. Thanks in advance! -- Pete Toscano pete@research.netsol.com 703.948.3364 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 5 15:39:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95Md2ML016676 for ; Fri, 5 Oct 2001 15:39:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f95Md2OJ016675 for ipng-dist; Fri, 5 Oct 2001 15:39:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95Md0ML016668 for ; Fri, 5 Oct 2001 15:39:00 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f95MaJG18761 for ipng@sunroof.eng.sun.com; Fri, 5 Oct 2001 15:36:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f959lhML015318 for ; Fri, 5 Oct 2001 02:47:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29406 for ; Fri, 5 Oct 2001 02:47:45 -0700 (PDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02609 for ; Fri, 5 Oct 2001 03:48:50 -0600 (MDT) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id CAA16611; Fri, 5 Oct 2001 02:46:27 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 5 Oct 2001 09:47:43 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id CAA05857; Fri, 5 Oct 2001 02:47:41 -0700 (PDT) Received: from medoc.eng.ascend.com (medoc.eng.ascend.com [135.87.47.20]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id CAA03310; Fri, 5 Oct 2001 02:47:41 -0700 (PDT) Received: from ascend.com (guzzi.eng.ascend.com [135.87.47.51]) by medoc.eng.ascend.com (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GKQ0081X8NRRC@medoc.eng.ascend.com>; Fri, 5 Oct 2001 11:50:15 +0200 (MET DST) Date: Fri, 05 Oct 2001 11:44:39 +0200 From: Elliott Norsa Subject: Re: Question on Site-Local-Addressing To: "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" Cc: ipng@sunroof.eng.sun.com Message-id: <3BBD8107.D1239065@ascend.com> Organization: Ascend Communications MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The definition of a site triggered many questions. My understanding of it is that it's an administratively defined collection of nodes. Quite simply, 2 nodes A and B belong to the same site, if every router in this same site doesn't need to route data out of the site to reach the destination. That means that a site could be: - in a single geographical location - spread out in several locations (with VPN). This would allow for a company to have intra-site communications without firewalling, even if it has locations in different geographical locations. Elliott "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" wrote: > > Hi ! > > With reference to "site-local-addresses", what is > the definition of a "site"? Are two nodes in two > different sites because of the configuration of > routing on the Routers in between them OR > BGP running on a Router in between them OR > through address allocation mechanisms OR > some other mechanism? > > In particular, I would like to know how to determine > if a given "site-local-address" belongs to the same site > as mine (i.e., my node). Is it possible to tell by > looking at the addresses of "my node" and the > "given site-local-address"? > > Sorry, if this is a silly question. > Thanks in advance for your help. > > Best Regards, > Swamy > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Elliott Norsa Ascend Communication Premea Sr Software Engineer Village d'entreprise Green Side mailto: enorsa@ascend.com 400 Avenue Roumanille, BP57 tel : (33) 4 92 96 56 22 ext: 65622 06901 Sophia Antipolis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 5 15:40:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95MeuML016728 for ; Fri, 5 Oct 2001 15:40:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f95Methf016727 for ipng-dist; Fri, 5 Oct 2001 15:40:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95MeqML016719 for ; Fri, 5 Oct 2001 15:40:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29854 for ; Fri, 5 Oct 2001 15:40:53 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA06728 for ; Fri, 5 Oct 2001 16:40:41 -0600 (MDT) Received: from 157.54.9.108 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Oct 2001 15:40:48 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 5 Oct 2001 15:40:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Source address selection draft Date: Fri, 5 Oct 2001 15:40:33 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FD0F@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Source address selection draft Thread-Index: AcFMY2iH+GZxPoo2SWqdVhRRj1878wBh6fLw From: "Richard Draves" To: "Alain Durand" Cc: X-OriginalArrivalTime: 05 Oct 2001 22:40:33.0857 (UTC) FILETIME=[BE9C8B10:01C14DEE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f95MeqML016720 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I missed this part of the IPng discussion on source address > selection/ destination address ordering. > > There were two points I would have like to make: > > 1- Some of this text is clearly in the scope of standard track. > e.g. deprecated vs non deprecated > Some other parts are more questionable, are would better > fit in a Best Current Practise (BCP) document. > e.g privacy extension, 6to4, other non-native addresses.... > We have recently discovered some issues with ISATAP > that ended up in modified text in the draft. I'm sure such > other similar problems will be discovered in the future. > It will be much easier to reissue the BCP part than > to modify the complete RFC if it ever reach DS status. > > So I would have like to re-iterate my suggestion to split > the document in two: > framework, obvious rules... goes standard track > other rules, values in various tables goes BCP I think it would be rather awkward to have the specification split into two documents. Part of the problem with the current situation is that the information and rules for different kinds of addresses(deprecated vs non-deprecated, scoping, temporary addresses, native vs transition addresses, etc, etc) is spread across many documents and it is not obvious how to handle conflicting requirements. The relative priority of the different requirements is not clear when the specification is broken up into pieces. When someone invents a new kind of address a year from now, then their specification can say how it should be handled (modify Rule N as follows, or insert rule N.5 between rule N and N+1) wrt the standard framework for address selection. And at some point "Default Address Selection v2" can collect up any changes & improvements and progress as an upgrade to the original standard. The original Default Address Selection might make it to DS while the v2 version could be cycled at draft or PS. > 2. The current draft does longest prefix match on 128 bits. > In the case of a dual-rail network where each hosts has > 2 interfaces See my previous email. 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 Fri Oct 5 16:07:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95N7eML016970 for ; Fri, 5 Oct 2001 16:07:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f95N7eik016969 for ipng-dist; Fri, 5 Oct 2001 16:07:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f95N7aML016962 for ; Fri, 5 Oct 2001 16:07:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05527 for ; Fri, 5 Oct 2001 16:07:37 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA21235 for ; Fri, 5 Oct 2001 17:07:26 -0600 (MDT) Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Oct 2001 16:07:14 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 5 Oct 2001 16:06:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request to Advance "Default Address Selection for IPv6" Date: Fri, 5 Oct 2001 16:07:13 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FD11@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to Advance "Default Address Selection for IPv6" Thread-Index: AcFLqRTWI1djEJtpRUOF00gB2Acv/wCSRrcQ From: "Richard Draves" To: "Hesham Soliman (EPA)" Cc: X-OriginalArrivalTime: 05 Oct 2001 23:06:57.0301 (UTC) FILETIME=[6E6AEC50:01C14DF2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f95N7aML016963 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oops, I missed your comment when doing 06. I'm not sure I understand it correctly. Are you suggesting another paragraph in section 3? Thanks, Rich -----Original Message----- From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au] Sent: Tuesday, October 02, 2001 6:16 PM To: ipng@sunroof.eng.sun.com Cc: Richard Draves Subject: RE: Request to Advance "Default Address Selection for IPv6" Hi, I'm resending this mail, I think it's still applicable to the latest version. This was sent after the Seattle meeting. Hesham -----Original Message----- From: Erik Nordmark [SMTP:Erik.Nordmark@eng.sun.com] Sent: Tuesday, 5 June 2001 12:23 To: Hesham Soliman (ERA) Cc: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" > Rich, > > Based on our private discussion in Seattle, think it would > be useful to add a sending rule for mapped addresses > as follows: > > - If the destination address is an IPv4-mapped IPv6 address, and > - If the host is an IPv6-only host > the source address MUST be an IPv6-translated address. I think this makes sense as long as we preface it very clearly with Nodes that implement SIIT (does not apply to other nodes) ... Without that preface adding these rules will do nothing but adding confusion. Erik -----Original Message----- From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] Sent: Tuesday, 5 June 2001 8:40 To: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Rich, Based on our private discussion in Seattle, think it would be useful to add a sending rule for mapped addresses as follows: - If the destination address is an IPv4-mapped IPv6 address, and - If the host is an IPv6-only host the source address MUST be an IPv6-translated address. Comments ? Hesham -----Original Message----- From: Bob Hinden [SMTP:hinden@iprg.nokia.com] Sent: Tuesday, 2 October 2001 9:46 To: Erik.Nordmark@eng.sun.com; narten@raleigh.ibm.com Cc: scoya@ietf.org; ipng@sunroof.eng.sun.com Subject: Request to Advance "Default Address Selection for IPv6" Erik, 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 : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-06.txt Pages : 22 Date : 28-Sep-01 A working group last call for this document was completed on June 7, 2001. The "-06" draft was produced in response to comments made during the w.g. last call and subsequent discussion. The document was discussed at the London IETF and the w.g. agreed advancing it to Proposed Standard once the new draft was published. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 7 19:36:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f982aAML019806 for ; Sun, 7 Oct 2001 19:36:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f982aAWv019805 for ipng-dist; Sun, 7 Oct 2001 19:36:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f982a6ML019798 for ; Sun, 7 Oct 2001 19:36:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20134 for ; Sun, 7 Oct 2001 19:36:07 -0700 (PDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14592 for ; Sun, 7 Oct 2001 20:35:56 -0600 (MDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA00027 for ; Mon, 8 Oct 2001 12:34:23 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA28857 for ; Mon, 8 Oct 2001 12:35:30 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 12:35:29 +1000 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED0D@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Richard Draves'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Request to Advance "Default Address Selection for IPv6" Date: Mon, 8 Oct 2001 12:35:28 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Oops, I missed your comment when doing 06. > I'm not sure I understand it correctly. > Are you suggesting another paragraph in section 3? > => I guess you could add something in section 3, but it should also be obvious in one of the rules. So to explain my comment better, the rule would specify that if the dst address is an IPv4-mapped IPv6 address, and the node is an IPv6-only node then the src address selected should be an IPv4-translated IPv6 address. As Erik mentioned in the mail I included below, we would have to add a comment specifynig that this is for nodes that implement SIIT to avoid confusion. I'm sorry if I didn't include other comments but I couldn't find any other responses. If someone else commented please restate your comment. Does that make sense ? Thanks, Hesham. > -----Original Message----- > From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au] > Sent: Tuesday, October 02, 2001 6:16 PM > To: ipng@sunroof.eng.sun.com > Cc: Richard Draves > Subject: RE: Request to Advance "Default Address Selection for IPv6" > > > Hi, > I'm resending this mail, I think it's still applicable to > the latest version. This was sent after the Seattle > meeting. > Hesham > -----Original Message----- > From: Erik Nordmark [SMTP:Erik.Nordmark@eng.sun.com] > Sent: Tuesday, 5 June 2001 12:23 > To: Hesham Soliman (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: W.G. Last Call on "Default Address Selection for > IPv6" > > Rich, > > > > Based on our private discussion in Seattle, think it would > > be useful to add a sending rule for mapped addresses > > as follows: > > > > - If the destination address is an IPv4-mapped IPv6 address, and > > - If the host is an IPv6-only host > > the source address MUST be an IPv6-translated address. > I think this makes sense as long as we preface it very clearly with > Nodes that implement SIIT (does not apply to other nodes) ... > Without that preface adding these rules will do nothing but adding > confusion. > Erik > -----Original Message----- > From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] > Sent: Tuesday, 5 June 2001 8:40 > To: ipng@sunroof.eng.sun.com > Subject: RE: W.G. Last Call on "Default Address Selection for > IPv6" > Rich, > Based on our private discussion in Seattle, think it would > be useful to add a sending rule for mapped addresses > as follows: > - If the destination address is an IPv4-mapped IPv6 address, and > - If the host is an IPv6-only host > the source address MUST be an IPv6-translated address. > Comments ? > Hesham > > > -----Original Message----- > From: Bob Hinden [SMTP:hinden@iprg.nokia.com] > Sent: Tuesday, 2 October 2001 9:46 > To: Erik.Nordmark@eng.sun.com; narten@raleigh.ibm.com > Cc: scoya@ietf.org; ipng@sunroof.eng.sun.com > Subject: Request to Advance "Default Address Selection for IPv6" > Erik, 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 : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-06.txt > Pages : 22 > Date : 28-Sep-01 > A working group last call for this document was completed on June 7, > 2001. The "-06" draft was produced in response to comments made during > the > w.g. last call and subsequent discussion. The document was discussed at > > the London IETF and the w.g. agreed advancing it to Proposed Standard > once > the new draft was published. > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 02:11:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f989BQML020480 for ; Mon, 8 Oct 2001 02:11:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f989BQAv020479 for ipng-dist; Mon, 8 Oct 2001 02:11:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f989BNML020472 for ; Mon, 8 Oct 2001 02:11:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29755; Mon, 8 Oct 2001 02:11:24 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16541; Mon, 8 Oct 2001 03:12:26 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f9899n701914; Mon, 8 Oct 2001 16:09:49 +0700 (ICT) From: Robert Elz To: "Richard Draves" cc: "Alain Durand" , ipng@sunroof.eng.sun.com, "Bob Hinden" , Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com, deering@cisco.com Subject: Re: Request to Advance "Default Address Selection for IPv6" In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FD10@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FD10@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Oct 2001 16:09:49 +0700 Message-ID: <1912.1002532189@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 5 Oct 2001 15:27:41 -0700 From: "Richard Draves" Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FD10@red-msg-06.redmond.corp.microsoft.com> | I'm a bit reluctant to build in the constant 64. Admittedly it's already | a magic number for IPv6, but I'm not excited about embedding knowledge | of it in yet another place. I completely agree with that. If using /128 for the match would actually break something, then yes, change it - but it won't, all it does is change what would be an undefined match where things agree in /64 to a defined (if in a way that makes little or no rational sense when observed without understanding the rule) match. No built in prefix lengths anywhere please, except where they're actually required for interoperability - and here it isn't. 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 Oct 8 11:59:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98IxbML022286 for ; Mon, 8 Oct 2001 11:59:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98Ixbtu022285 for ipng-dist; Mon, 8 Oct 2001 11:59:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98IxVML022278 for ; Mon, 8 Oct 2001 11:59:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23972 for ; Mon, 8 Oct 2001 11:59:32 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00611 for ; Mon, 8 Oct 2001 11:59:32 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98IwvS06395 for ; Mon, 8 Oct 2001 14:58:57 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Mon, 8 Oct 2001 14:59:18 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4D643SXR; Mon, 8 Oct 2001 14:59:03 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T54YP4V4; Mon, 8 Oct 2001 14:59:02 -0400 Message-ID: <3BC1F78B.EF406F8D@americasm06.nt.com> Date: Mon, 08 Oct 2001 14:59:23 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipng@sunroof.eng.sun.com Subject: Re: draft-haberman-ipngwg-auto-prefix-01.txt References: <20010926044214.E28287BA@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Sorry for the delay in this response. Answers below... Jun-ichiro itojun Hagino wrote: > 1. response type against renew request > consider the following transaction. what will be the message type for the > reply against renew request? > > reqestor -> delegator (multicast): > icmp6 type = prefix request, icmp6 code = delegator query (0) > delegator -> requestor: > icmp6 type = prefix reply, icmp6 code = prefix delegator (0) > requestor -> delegator: > icmp6 type = prefix request, icmp6 code = initial request (1) > delegator -> requestor: > icmp6 type = prefix reply, icmp6 code = prefix delegated (4) > (lifetime passes) > requestor -> delegator: > icmp6 type = prefix request, icmp6 code = renewal request (2) > delegator -> requestor: > icmp6 type = prefix reply, icmp6 code = ???? Unless we can find a good reason for a new code, the response will be "prefix delegated (4)" same as the initial reply. > > 2. authorization faiulure > how does authorization fail when the protocol does not provide any > authentication mechansisms? does it assume any ipsec assumptions, like > "ipsec AH failure is visible to delegator daemon, and delegator can > request AH"? I have not had a chance to look into the authorization mechanisms yet. I do not envision creating a new authorization mechanism here. Most likely IPSec will be the recommended approach. > > 3. state machine > apparently state machine has to be maintained by the implementation of the > protocol. if there is a diagram of state machine (to understand what are the > expected messages and what are not) it would help us understand the protocol > much. maybe it is too much to ask. I have not created one, but we will take it under advisement. :) Thanks, 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 Oct 8 14:33:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98LXmML022847 for ; Mon, 8 Oct 2001 14:33:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f98LXmIM022846 for ipng-dist; Mon, 8 Oct 2001 14:33:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98LXiML022839 for ; Mon, 8 Oct 2001 14:33:44 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24568 for ; Mon, 8 Oct 2001 14:33:42 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24579 for ; Mon, 8 Oct 2001 14:33:43 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA24838; Mon, 8 Oct 2001 14:33:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f98LXgT15727; Mon, 8 Oct 2001 14:33:42 -0700 X-mProtect: Mon, 8 Oct 2001 14:33:42 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdwlQlKK; Mon, 08 Oct 2001 14:33:40 PDT Message-Id: <4.3.2.7.2.20011008115356.025d5cc8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Oct 2001 14:33:30 -0700 To: From: Bob Hinden Subject: RE: Source address selection draft Cc: hinden@iprg.nokia.com In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FD0F@red-msg-06.redmon d.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to add that at the London IETF meeting the majority of the discussion on this draft was on this issue (i.e., whether to split the source address selection document into two documents). At the end of the discussion, there was a general consensus to not split the document as doing so would harm interoperability. This was captured in the minutes for the meeting. Bob > > > > So I would have like to re-iterate my suggestion to split > > the document in two: > > framework, obvious rules... goes standard track > > other rules, values in various tables goes BCP > >I think it would be rather awkward to have the specification split into >two documents. Part of the problem with the current situation is that >the information and rules for different kinds of addresses(deprecated vs >non-deprecated, scoping, temporary addresses, native vs transition >addresses, etc, etc) is spread across many documents and it is not >obvious how to handle conflicting requirements. The relative priority of >the different requirements is not clear when the specification is broken >up into pieces. > >When someone invents a new kind of address a year from now, then their >specification can say how it should be handled (modify Rule N as >follows, or insert rule N.5 between rule N and N+1) wrt the standard >framework for address selection. And at some point "Default Address >Selection v2" can collect up any changes & improvements and progress as >an upgrade to the original standard. The original Default Address >Selection might make it to DS while the v2 version could be cycled at >draft or PS. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 8 17:19:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f990JdML023082 for ; Mon, 8 Oct 2001 17:19:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f990JdAk023081 for ipng-dist; Mon, 8 Oct 2001 17:19:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f990JXML023074 for ; Mon, 8 Oct 2001 17:19:35 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28307 for ; Mon, 8 Oct 2001 17:19:37 -0700 (PDT) Received: from cnhon1imr4.i.wcom.com.hk (mailhost3.wcom.com.hk [202.130.178.68]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00502 for ; Mon, 8 Oct 2001 17:19:35 -0700 (PDT) X-Internal-ID: 3BA9ED2F000634D9 Received: from cnhon1imr4.i.wcom.com.hk (166.45.172.22) by cnhon1imr4.i.wcom.com.hk (NPlex 3.0.036); Tue, 9 Oct 2001 01:18:28 +0100 Received: from cnhon1gw0.i.wcom.com.hk (cnhon1gw0.i.wcom.com.hk [166.45.172.46]) by cnhon1imr4.i.wcom.com.hk with SMTP (MailShield v2.04 - WIN32 Jul 17 2001 17:12:42); Tue, 09 Oct 2001 01:18:27 +0100 Received: by cnhon1gw0.i.wcom.com.hk with Internet Mail Service (5.5.2653.19) id <4PXHHZR3>; Tue, 9 Oct 2001 08:19:28 +0800 Message-ID: From: "Smith, Mark" To: "'Aron Silverton'" , vrrp@drcoffsite.com, "'ipng@sunroof.eng.sun.com.'" Subject: RE: VRRPv6? Date: Tue, 9 Oct 2001 08:19:20 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cnhon1gw0.i.wcom.com.hk X-SMTP-MAIL-FROM: smith.r.mark@wcom.com.au X-SMTP-PEER-INFO: cnhon1gw0.i.wcom.com.hk [166.45.172.46] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, there is a IPv6 draft which allows preference to be assigned between multiple default routers : http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-selection-00.tx t If IPv6 Node Unreachable Discovery is as prompt as VRRP failover (ie around < 3 seconds to discover a dead router), NUD with the above default router preference would provide similar functionality to IPv4 VRRP, with the difference being the mechanism is implemented in the hosts rather than the routers. I'm sure somebody on the ipng list could provide further clarification. Regards, Mark. > -----Original Message----- > From: Aron Silverton [mailto:ajs@labs.mot.com] > Sent: Saturday, 6 October 2001 4:28 > To: vrrp@drcoffsite.com > Subject: VRRPv6? > > > Hello, > > I've looked through some of the archives, and haven't found mention of > IPv6 VRRP. Can somebody update me on the status of that effort? > > Thank you, > > Aron > -- > Aron J. Silverton > Senior Research Engineer > Motorola Labs, Networks and Infrastructure Research > Motorola, Inc. > > Telephone: (847) 576-8747 > Fax: (847) 576-3420 > Pager: (800) 759-8888 PIN 1147344 > Email: ajs@labs.mot.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 Oct 8 20:35:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f993ZtML024112 for ; Mon, 8 Oct 2001 20:35:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f993ZtK3024111 for ipng-dist; Mon, 8 Oct 2001 20:35:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f993ZpML024104 for ; Mon, 8 Oct 2001 20:35:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23131 for ; Mon, 8 Oct 2001 20:35:55 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13574 for ; Mon, 8 Oct 2001 21:35:43 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Oct 2001 20:35:53 -0700 Received: from 157.54.1.52 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 20:35:54 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Oct 2001 20:35:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: Request to Advance "Default Address Selection for IPv6" Date: Mon, 8 Oct 2001 20:35:52 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FD1F@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to Advance "Default Address Selection for IPv6" Thread-Index: AcFPoepCedK50RluTZWglI05FM+3+QA0JIiQ From: "Richard Draves" To: "Hesham Soliman (EPA)" , "Erik Nordmark (Erik Nordmark)" Cc: X-OriginalArrivalTime: 09 Oct 2001 03:35:53.0538 (UTC) FILETIME=[7F9A8A20:01C15073] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15073.7F2342C0" ------_=_NextPart_001_01C15073.7F2342C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just took another look at RFC 2765. I believe that for SIIT to work, when an IPv6-only node sends to an IPv4-mapped address (so it is sending an IPv6 packet with an IPv4-mapped source address, as opposed to using the IPv4-mapped address in the API and sending an IPv4 packet), then it must use an IPv4-translatable source address. Anything else will just not work when the packet gets to the SIIT box. =20 So to my mind, this feels more like a section 3 requirement. It's not a matter of the IPv6-only node *preferring* to use an IPv4-translatable source address. Instead, if there is no IPv4-translatable source address available, then the IPv6-only node should *fail* to send to the IPv4-mapped destination address. =20 But I don't understand Erik's comment that this only applies to nodes that implement SIIT. Why does it not apply to all IPv6-only nodes sitting behind a SIIT box? =20 Thanks, Rich -----Original Message----- From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]=20 Sent: Sunday, October 07, 2001 7:35 PM To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: RE: Request to Advance "Default Address Selection for IPv6" =09 =09 Oops, I missed your comment when doing 06.=20 I'm not sure I understand it correctly.=20 Are you suggesting another paragraph in section 3?=20 =3D> I guess you could add something in section 3,=20 but it should also be obvious in one of the rules.=20 So to explain my comment better, the rule would=20 specify that if the dst address is an IPv4-mapped=20 IPv6 address, and the node is an IPv6-only node=20 then the src address selected should be an IPv4-translated=20 IPv6 address.=20 As Erik mentioned in the mail I included below, we would have=20 to add a comment specifynig that this is for nodes=20 that implement SIIT to avoid confusion.=20 I'm sorry if I didn't include other comments but I couldn't find=20 any other responses. If someone else commented please=20 restate your comment.=20 Does that make sense ?=20 Thanks,=20 Hesham.=20 -----Original Message-----=20 From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]=20 Sent: Tuesday, October 02, 2001 6:16 PM=20 To: ipng@sunroof.eng.sun.com=20 Cc: Richard Draves=20 Subject: RE: Request to Advance "Default Address Selection for IPv6"=20 Hi,=20 I'm resending this mail, I think it's still applicable to=20 the latest version. This was sent after the Seattle=20 meeting.=20 Hesham=20 -----Original Message-----=20 From: Erik Nordmark [SMTP:Erik.Nordmark@eng.sun.com]=20 Sent: Tuesday, 5 June 2001 12:23=20 To: Hesham Soliman (ERA)=20 Cc: ipng@sunroof.eng.sun.com=20 Subject: RE: W.G. Last Call on "Default Address Selection for=20 IPv6"=20 > Rich,=20 >=20 > Based on our private discussion in Seattle, think it would=20 > be useful to add a sending rule for mapped addresses=20 > as follows:=20 >=20 > - If the destination address is an IPv4-mapped IPv6 address, and=20 > - If the host is an IPv6-only host=20 > the source address MUST be an IPv6-translated address. I think this makes sense as long as we preface it very clearly with=20 Nodes that implement SIIT (does not apply to other nodes) ...=20 Without that preface adding these rules will do nothing but adding=20 confusion.=20 Erik=20 -----Original Message-----=20 From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se]=20 Sent: Tuesday, 5 June 2001 8:40=20 To: ipng@sunroof.eng.sun.com=20 Subject: RE: W.G. Last Call on "Default Address Selection for=20 IPv6"=20 Rich,=20 Based on our private discussion in Seattle, think it would=20 be useful to add a sending rule for mapped addresses=20 as follows:=20 - If the destination address is an IPv4-mapped IPv6 address, and=20 - If the host is an IPv6-only host=20 the source address MUST be an IPv6-translated address.=20 Comments ?=20 Hesham=20 -----Original Message-----=20 From: Bob Hinden [SMTP:hinden@iprg.nokia.com]=20 Sent: Tuesday, 2 October 2001 9:46=20 To: Erik.Nordmark@eng.sun.com; narten@raleigh.ibm.com=20 Cc: scoya@ietf.org; ipng@sunroof.eng.sun.com=20 Subject: Request to Advance "Default Address Selection for IPv6"=20 Erik, Thomas,=20 The chairs of the IP Next Generation working group, on behalf of the=20 working group, request that the following document be published as a=20 Proposed Standard:=20 Title : Default Address Selection for IPv6=20 Author(s) : R. Draves=20 Filename : draft-ietf-ipngwg-default-addr-select-06.txt=20 Pages : 22=20 Date : 28-Sep-01=20 A working group last call for this document was completed on June 7,=20 2001. The "-06" draft was produced in response to comments made during=20 the=20 w.g. last call and subsequent discussion. The document was discussed at=20 the London IETF and the w.g. agreed advancing it to Proposed Standard=20 once=20 the new draft was published.=20 Bob Hinden / Steve Deering=20 IPng Working Group Co-Chairs=20 =09 --------------------------------------------------------------------=20 IETF IPng Working Group Mailing List=20 IPng Home Page: http://playground.sun.com/ipng=20 FTP archive: ftp://playground.sun.com/pub/ipng=20 Direct all administrative requests to majordomo@sunroof.eng.sun.com=20 =09 --------------------------------------------------------------------=20 ------_=_NextPart_001_01C15073.7F2342C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I just=20 took another look at RFC 2765. I believe that for SIIT to work, when an=20 IPv6-only node sends to an IPv4-mapped address (so it is sending an IPv6 = packet=20 with an IPv4-mapped source address, as opposed to using the IPv4-mapped = address=20 in the API and sending an IPv4 packet), then it must use an = IPv4-translatable=20 source address. Anything else will just not work when the packet gets to = the=20 SIIT box.
 
So to=20 my mind, this feels more like a section 3 requirement. It's not a matter = of the=20 IPv6-only node *preferring* to use an IPv4-translatable source address. = Instead,=20 if there is no IPv4-translatable source address available, then the = IPv6-only=20 node should *fail* to send to the IPv4-mapped destination=20 address.
 
But I=20 don't understand Erik's comment that this only applies to nodes that = implement=20 SIIT. Why does it not apply to all IPv6-only nodes sitting behind a SIIT = box?
 
Thanks,
Rich
-----Original Message-----
From: = Hesham Soliman=20 (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: Sunday, = October=20 07, 2001 7:35 PM
To: Richard Draves
Cc:=20 ipng@sunroof.eng.sun.com
Subject: RE: Request to Advance = "Default=20 Address Selection for IPv6"


    Oops, I missed your comment when = doing 06.=20
    I'm not sure I understand it = correctly.=20
    Are you suggesting another paragraph = in section=20 3?

    =3D> I guess you = could add=20 something in section 3,
    but=20 it should also be obvious in one of the rules.
    So to explain my comment better, the rule = would=20
    specify that = if the dst=20 address is an IPv4-mapped
    IPv6 address, and the node is an IPv6-only node =
    then the src address selected = should be an=20 IPv4-translated
    IPv6=20 address.

    As Erik mentioned in = the mail I=20 included below, we would have
    to add a comment specifynig that this is for nodes =
    that implement SIIT to avoid = confusion.=20
    I'm sorry if = I didn't=20 include other comments but I couldn't find
    any other responses. If someone else = commented please=20
    restate your=20 comment.

    Does that make sense = ?

    Thanks, =
    Hesham.

    -----Original Message----- =
    From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@eric= sson.com.au]
    Sent: = Tuesday,=20 October 02, 2001 6:16 PM
    To:=20 ipng@sunroof.eng.sun.com
    Cc: = Richard=20 Draves
    Subject: RE: Request = to Advance=20 "Default Address Selection for IPv6"


    Hi,
    I'm=20 resending this mail, I think it's still applicable to =
    the latest version. This was sent after the = Seattle=20
    meeting.
    Hesham
    -----Original = Message-----=20
    From:   Erik = Nordmark=20 [SMTP:Erik.Nordmark@eng.sun.com]
    Sent:   Tuesday, 5 June 2001 12:23 =
    To:     Hesham = Soliman  (ERA)=20
    Cc:    =20 ipng@sunroof.eng.sun.com
    Subject:        RE: W.G. = Last Call=20 on "Default Address Selection for
    IPv6"=20
    > Rich,
    >
    > Based on = our private=20 discussion in Seattle,  think it would
    > be useful to add a sending rule for mapped addresses=20
    > as follows: =
    >
    > - If the=20 destination address is an IPv4-mapped IPv6 address, and =
    > - If the host is an IPv6-only host =
    > the source address MUST be an = IPv6-translated=20 address.
    I think this makes = sense as long=20 as we preface it very clearly with
            Nodes that = implement SIIT=20 (does not apply to other nodes) ...
    Without that preface adding these rules will do nothing but = adding
    confusion. =
      Erik
    -----Original Message-----
    From:   Hesham Soliman  (ERA)=20 [SMTP:Hesham.Soliman@era.ericsson.se]
    Sent:   Tuesday, 5 June 2001 8:40 =
    To:     = ipng@sunroof.eng.sun.com=20
    Subject:        RE: W.G. = Last Call=20 on "Default Address Selection for
    IPv6"=20
    Rich,
    Based on our private discussion in Seattle,  think it = would=20
    be useful to add a sending = rule for=20 mapped addresses
    as follows:=20
    - If the destination address = is an=20 IPv4-mapped IPv6 address, and
    - If the=20 host is an IPv6-only host
    the = source=20 address MUST be an IPv6-translated address.
    Comments ?
    Hesham =


    -----Original Message----- =
    From:   Bob Hinden = [SMTP:hinden@iprg.nokia.com]=20
    Sent:   Tuesday, 2 = October 2001=20 9:46
    To:    =20 Erik.Nordmark@eng.sun.com; narten@raleigh.ibm.com
    Cc:     scoya@ietf.org;=20 ipng@sunroof.eng.sun.com
    Subject:        Request = to Advance=20 "Default Address Selection for IPv6"
    Erik, Thomas,
    The = chairs of the IP=20 Next Generation working group, on behalf of the
    working group, request that the following document be = published as a=20
    Proposed Standard: =
           =20 Title           : = Default=20 Address Selection for IPv6
           =20 Author(s)       : R. Draves =
           =20 Filename        :=20 draft-ietf-ipngwg-default-addr-select-06.txt
           =20 Pages           : = 22=20
           =20 = Date            : = 28-Sep-01
    A working group = last call for=20 this document was completed on June 7,
    2001.  The "-06" draft was produced in response to = comments made=20 during
    the
    w.g. last call and subsequent discussion.  The = document was=20 discussed at

    the London IETF and the w.g. agreed = advancing it=20 to Proposed Standard
    once=20
    the new draft was published.=20
    Bob Hinden / Steve Deering=20
    IPng Working Group Co-Chairs=20
    ----------------------------------------------------------------= ----=20
    IETF IPng Working Group = Mailing List=20
    IPng Home=20 = Page:           &n= bsp;         =20 http://playground.sun.com/ipng
    FTP=20 = archive:           = ;          =20     ftp://playground.sun.com/pub/i= png
    Direct = all=20 administrative requests to majordomo@sunroof.eng.sun.com =
    ----------------------------------------------------------------= ----=20

=00 ------_=_NextPart_001_01C15073.7F2342C0-- --------------InterScan_NT_MIME_Boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 8 20:47:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f993l9ML024140 for ; Mon, 8 Oct 2001 20:47:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f993l9f4024139 for ipng-dist; Mon, 8 Oct 2001 20:47:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f993l5ML024132 for ; Mon, 8 Oct 2001 20:47:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13431 for ; Mon, 8 Oct 2001 20:47:09 -0700 (PDT) Received: from newish7.ericsson.com.au ([203.61.155.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA16764 for ; Mon, 8 Oct 2001 21:48:17 -0600 (MDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA27228 for ; Tue, 9 Oct 2001 13:45:25 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA05400 for ; Tue, 9 Oct 2001 13:46:31 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 13:46:29 +1000 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED1D@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Richard Draves'" , "Hesham Soliman (EPA)" , "Erik Nordmark (Erik Nordmark)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Request to Advance "Default Address Selection for IPv6" Date: Tue, 9 Oct 2001 13:46:25 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I just took another look at RFC 2765. I believe that for SIIT to work, > when an IPv6-only node sends to an IPv4-mapped address (so it is sending > an IPv6 packet with an IPv4-mapped source address, as opposed to using the > IPv4-mapped address in the API and sending an IPv4 packet), then it must > use an IPv4-translatable source address. Anything else will just not work > when the packet gets to the SIIT box. > > So to my mind, this feels more like a section 3 requirement. It's not a > matter of the IPv6-only node *preferring* to use an IPv4-translatable > source address. Instead, if there is no IPv4-translatable source address > available, then the IPv6-only node should *fail* to send to the > IPv4-mapped destination address. > => I see, so section 3 is ok then. But just for my understanding are you saying that in this case you would basically bypass the src address selection rules ? > > But I don't understand Erik's comment that this only applies to nodes that > implement SIIT. Why does it not apply to all IPv6-only nodes sitting > behind a SIIT box? > => I thought that if an IPv6-only node gets an IPv4-mapped address for the dst node then it must use an IPv4-translatable IPv6 src address. If the network does not support SIIT then it must not return an IPv4-mapped address to the IPv6 node (in the DNS reply ....etc). This seems to be inline with what you say above. But I don't know if this requirement on IPv4-mapped addresses is mentioned anywhere, for example is there anything in NAT-PT that disallows the use of a mapped address for the NAT-PT box ? I think that should be disallowed to avoid confusion in the end hosts. I hope this helps. Thanks, Hesham > -----Original Message----- > From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au] > Sent: Sunday, October 07, 2001 7:35 PM > To: Richard Draves > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Request to Advance "Default Address Selection for IPv6" > > > > > Oops, I missed your comment when doing 06. > I'm not sure I understand it correctly. > Are you suggesting another paragraph in section 3? > > => I guess you could add something in section 3, > but it should also be obvious in one of the rules. > So to explain my comment better, the rule would > specify that if the dst address is an IPv4-mapped > IPv6 address, and the node is an IPv6-only node > then the src address selected should be an IPv4-translated > IPv6 address. > > As Erik mentioned in the mail I included below, we would > have > to add a comment specifynig that this is for nodes > that implement SIIT to avoid confusion. > I'm sorry if I didn't include other comments but I couldn't find > any other responses. If someone else commented please > restate your comment. > > Does that make sense ? > > Thanks, > Hesham. > > -----Original Message----- > From: Hesham Soliman (EPA) [ > ] > Sent: Tuesday, October 02, 2001 6:16 PM > To: ipng@sunroof.eng.sun.com > Cc: Richard Draves > Subject: RE: Request to Advance "Default Address Selection for IPv6" > > > > Hi, > I'm resending this mail, I think it's still applicable to > the latest version. This was sent after the Seattle > meeting. > Hesham > -----Original Message----- > From: Erik Nordmark [SMTP:Erik.Nordmark@eng.sun.com] > Sent: Tuesday, 5 June 2001 12:23 > To: Hesham Soliman (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: W.G. Last Call on "Default Address Selection for > > IPv6" > > Rich, > > > > Based on our private discussion in Seattle, think it would > > be useful to add a sending rule for mapped addresses > > as follows: > > > > - If the destination address is an IPv4-mapped IPv6 address, and > > - If the host is an IPv6-only host > > the source address MUST be an IPv6-translated address. > I think this makes sense as long as we preface it very clearly with > Nodes that implement SIIT (does not apply to other nodes) > ... > Without that preface adding these rules will do nothing but adding > confusion. > Erik > -----Original Message----- > From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] > Sent: Tuesday, 5 June 2001 8:40 > To: ipng@sunroof.eng.sun.com > Subject: RE: W.G. Last Call on "Default Address Selection for > > IPv6" > Rich, > Based on our private discussion in Seattle, think it would > be useful to add a sending rule for mapped addresses > as follows: > - If the destination address is an IPv4-mapped IPv6 address, and > - If the host is an IPv6-only host > the source address MUST be an IPv6-translated address. > Comments ? > Hesham > > > -----Original Message----- > From: Bob Hinden [SMTP:hinden@iprg.nokia.com] > Sent: Tuesday, 2 October 2001 9:46 > To: Erik.Nordmark@eng.sun.com; narten@raleigh.ibm.com > Cc: scoya@ietf.org; ipng@sunroof.eng.sun.com > Subject: Request to Advance "Default Address Selection for > IPv6" > Erik, 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 : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : > draft-ietf-ipngwg-default-addr-select-06.txt > Pages : 22 > Date : 28-Sep-01 > A working group last call for this document was completed on June 7, > > 2001. The "-06" draft was produced in response to comments made > during > the > w.g. last call and subsequent discussion. The document was > discussed at > > the London IETF and the w.g. agreed advancing it to Proposed > Standard > once > the new draft was published. > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > IPng Home Page: > > FTP archive: > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 9 00:02:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9972lML024481 for ; Tue, 9 Oct 2001 00:02:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9972krp024480 for ipng-dist; Tue, 9 Oct 2001 00:02:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9972hML024473 for ; Tue, 9 Oct 2001 00:02:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17415 for ; Tue, 9 Oct 2001 00:02:46 -0700 (PDT) Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA25517 for ; Tue, 9 Oct 2001 00:02:44 -0700 (PDT) Received: (qmail 26933 invoked from network); 9 Oct 2001 06:56:13 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 9 Oct 2001 06:56:13 -0000 Received: from ispgate (ispgate [194.67.37.200]) by gate.ispras.ru (8.11.2/8.11.1) with ESMTP id f9972Zs14449 for ; Tue, 9 Oct 2001 11:02:37 +0400 (MSK) Date: Tue, 9 Oct 2001 11:02:35 +0400 (MSK) From: Grigory Kljuchnikov To: Subject: How to handle some errors in IPv6 packets? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have several questions about handling exceptional situations in IPv6 packets: 1. How to process packets that have incorrect version number? Should we discard it or send an ICMPv6 error message? Ethernet header has an identifier of the included ip-level protocol packet. Suppose that it identifies the IPv6 packet but the Version fields of the IPv6 header is not 6. What to do in this case? Send an error, discard the packet or something else? 2. How to process packets that have incorrect payload length field? Should we discard it or send an ICMPv6 error message? IP receives from LAN an array of octets as well as it's length. If payload length field contains correct value then that length is equal to the payload length plus 40 (the length of the header). What to do if the payload length does not match the length of the octets array received from the LAN level? Should we send an ICMP error message or silently discard the message? 3. What to do when the total size of options does not match the size of the header (Hop-by-hop and Destination options headers)? Each TLV options contains it's data size. What implementations are supposed to do if the total length of options (calculated from their Option Data length fields) does not match the length of the header? 4. Jumbo Payload options errors. What to do if Jumbo Payload option length is not equal to 4? What to do if there are several Jumbo Payload options in hop-by-options header? 5. What to do with malformed fragments sequences? There several possible exceptional situations not covered by RFC 2460 Section 4.5 such as: 5.1 Fragments overlap. 5.2 Suppose we have received a fragment with M flag set to 0 ("rightmost" fragment). Then an exception is a fragment with M flag set to 1 offset greater than the offset of the "rightmost" fragment. How implementations are supposed to handle these cases? Grigory Klyuchnikov, System Engineer, Institute for System Programming Russian Academy of Sciences -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 9 00:33:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f997XHML024513 for ; Tue, 9 Oct 2001 00:33:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f997XG6R024512 for ipng-dist; Tue, 9 Oct 2001 00:33:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f997XDML024505 for ; Tue, 9 Oct 2001 00:33:13 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19159 for ; Tue, 9 Oct 2001 00:33:15 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04800 for ; Tue, 9 Oct 2001 00:33:13 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id KAA12845; Tue, 9 Oct 2001 10:32:49 +0300 Date: Tue, 9 Oct 2001 10:32:49 +0300 Message-Id: <200110090732.KAA12845@burp.tkv.asdf.org> From: Markku Savela To: grn@ispras.ru CC: ipng@sunroof.eng.sun.com In-reply-to: (message from Grigory Kljuchnikov on Tue, 9 Oct 2001 11:02:35 +0400 (MSK)) Subject: Re: How to handle some errors in IPv6 packets? References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just one implementors choices on these... > From: Grigory Kljuchnikov > 1. How to process packets that have incorrect version number? > Should we discard it or send an ICMPv6 error message? I don't care what the original Ethernet framing was. I only check the version field from IP header, and process the packet accordingly. If it was not 4 or 6, packet is silently dropped. > 2. How to process packets that have incorrect payload length field? If the packet is shorter than the length indicated by the length field of the IP header, the packet is silently dropped. If actual length is longer, the extra octets are silently ignored and packet is processed normally. > 3. What to do when the total size of options does not match the size > of the header (Hop-by-hop and Destination options headers)? > Each TLV options contains it's data size. What implementations are > supposed to do if the total length of options (calculated from their > Option Data length fields) does not match the length of the header? Packet is silently dropped (while processing options, when it bumps against the end of the option header). > 4. Jumbo Payload options errors. I don't do jumbo. > 5. What to do with malformed fragments sequences? > There several possible exceptional situations not covered by > RFC 2460 Section 4.5 such as: > 5.1 Fragments overlap. Hmm. currently just last received overlapped octets will end up the final content of the packet. No error generated. > 5.2 Suppose we have received a fragment with M flag set to 0 > ("rightmost" fragment). Then an exception is a fragment with M flag > set to 1 offset greater than the offset of the "rightmost" fragment. > How implementations are supposed to handle these cases? Another hmm.. I would need to check my source :-). But, depends on when the fragment with M=0 arrives. - If by that time, all the preceding fragments are available, the packet is declared as complete. The later arriving M=1 will start a new assembly (which will probably time out, if nothing else arrives). - If at point of M=1, I still have the assembly and M=0 has been received. Need to check this, probably drop the new fragment. -- Markku Savela -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 9 05:07:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99C7vML024843 for ; Tue, 9 Oct 2001 05:07:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99C7vlB024842 for ipng-dist; Tue, 9 Oct 2001 05:07:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99C7pML024835 for ; Tue, 9 Oct 2001 05:07:52 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f99C7kq06884; Tue, 9 Oct 2001 14:07:47 +0200 (MET DST) Date: Tue, 9 Oct 2001 14:02:46 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Request to Advance "Default Address Selection for IPv6" To: Richard Draves Cc: "Hesham Soliman (EPA)" , "Erik Nordmark (Erik Nordmark)" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA80355FD1F@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I just took another look at RFC 2765. I believe that for SIIT to work, > when an IPv6-only node sends to an IPv4-mapped address (so it is sending > an IPv6 packet with an IPv4-mapped source address, as opposed to using the > IPv4-mapped address in the API and sending an IPv4 packet), then it must > use an IPv4-translatable source address. Anything else will just not work > when the packet gets to the SIIT box. Correct. > So to my mind, this feels more like a section 3 requirement. It's not a > matter of the IPv6-only node *preferring* to use an IPv4-translatable > source address. Instead, if there is no IPv4-translatable source address > available, then the IPv6-only node should *fail* to send to the > IPv4-mapped destination address. I agree that it should fail. > > But I don't understand Erik's comment that this only applies to nodes that > implement SIIT. Why does it not apply to all IPv6-only nodes sitting > behind a SIIT box? Perhaps there is some terminology confusion. When I said something like "nodes that implement SIIT" I meant nodes that have mechanisms to acquire the IPv4-translatable addresses (which isn't specified in the SIIT spec). This is quite different than the nodes that run the SIIT translation rules. So "all IPv6 nodes capable of sitting behind a SIIT translator" catches what I tried to say. 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 Oct 9 05:46:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99CkrML024965 for ; Tue, 9 Oct 2001 05:46:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99Ckr0A024964 for ipng-dist; Tue, 9 Oct 2001 05:46:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99CklML024957 for ; Tue, 9 Oct 2001 05:46:48 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f99Ckkq10837; Tue, 9 Oct 2001 14:46:46 +0200 (MET DST) Date: Tue, 9 Oct 2001 14:41:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: VRRPv6? To: "Smith, Mark" Cc: "'Aron Silverton'" , vrrp@drcoffsite.com, "'ipng@sunroof.eng.sun.com.'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If IPv6 Node Unreachable Discovery is as prompt as VRRP failover (ie around > < 3 seconds to discover a dead router), NUD with the above default router > preference would provide similar functionality to IPv4 VRRP, with the > difference being the mechanism is implemented in the hosts rather than the > routers. The default timers in NUD result in a failure detection in about 40 seconds as I recall. There is the capability for the routers to advertise diffferent ReachableTime and RetransTime (with the unit of milliseconds) so that in theory the NUD failure detection could be as low as 5 seconds or so (ReachableTime + DELAY_FIRST_PROBE_TIME + (MAX_UNICAST_SOLICIT+1)*RetransTime) However, there is an engineering tradeoff between using NUD vs. VRRP to detect router failures. In order for NUD to detect failures on the order of N seconds every node that is actively sending packets need to probe their neighbor more often than every N seconds (this includes host to router probes, router to host, and host to host). Thus with R routers and H hosts this traffic has elements that depend on R*H as well as H*H (but if there is little host-to-host traffic the latter part might not be that significant). Worst case is clearly a probe traffic order H-squared. Contrast with VRRP which, but virtue of only looking at router failures and not host failures, can limit the probe traffic to be order R (or perhaps even constant independent of the number of routers). So NUD does a fine job of recovering from hosts changing their link-layer address and sooner or later detecting that a router is dead. But if the goal is to quickly fail over between a set of routers then VRRP make more sense. 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 Oct 9 06:38:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99DcoML025003 for ; Tue, 9 Oct 2001 06:38:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99Dcn3Z025002 for ipng-dist; Tue, 9 Oct 2001 06:38:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99DcjML024995 for ; Tue, 9 Oct 2001 06:38:45 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14088 for ; Tue, 9 Oct 2001 06:38:47 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13432 for ; Tue, 9 Oct 2001 06:38:46 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f99DcCS02098 for ; Tue, 9 Oct 2001 09:38:12 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 9 Oct 2001 09:38:41 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4CJK4W06; Tue, 9 Oct 2001 09:38:25 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4R47YAB1; Tue, 9 Oct 2001 09:38:23 -0400 Message-ID: <3BC2FDE4.F0A794AD@americasm06.nt.com> Date: Tue, 09 Oct 2001 09:38:44 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: "Smith, Mark" , "'Aron Silverton'" , vrrp@drcoffsite.com, "'ipng@sunroof.eng.sun.com.'" Subject: Re: VRRPv6? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > So NUD does a fine job of recovering from hosts changing their link-layer > address and sooner or later detecting that a router is dead. But if the goal > is to quickly fail over between a set of routers then VRRP make more sense. I agree with your assessment. Having VRRP functionality accomplishes more than simply depending on NUD. However, the current VRRP spec has no support whatsoever for IPv6. In addition, there may be issues that need to be addressed where VRRP, as defined for IPv4, causes operational problems in IPv6 (DAD for instance). Anyone in VRRP looking at VRRPv6??? 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 Oct 9 07:23:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99ENrML025065 for ; Tue, 9 Oct 2001 07:23:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99ENruG025064 for ipng-dist; Tue, 9 Oct 2001 07:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99ENnML025057 for ; Tue, 9 Oct 2001 07:23:50 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04147 for ; Tue, 9 Oct 2001 07:23:50 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23683 for ; Tue, 9 Oct 2001 07:23:49 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id D206CA5D9; Tue, 9 Oct 2001 10:23:48 -0400 (EDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6CCD69710; Tue, 9 Oct 2001 10:23:48 -0400 (EDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id CEBD4759; Tue, 9 Oct 2001 09:23:45 -0500 (CDT) Received: from oflume.zk3.dec.com (oflume.zk3.dec.com [16.140.112.3]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 75E67617; Tue, 9 Oct 2001 09:23:45 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id KAA0000011228; Tue, 9 Oct 2001 10:23:44 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id KAA0000110730; Tue, 9 Oct 2001 10:23:43 -0400 (EDT) Message-ID: <3BC3086F.18583532@zk3.dec.com> Date: Tue, 09 Oct 2001 10:23:43 -0400 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Grigory Kljuchnikov Cc: ipng@sunroof.eng.sun.com Subject: Re: How to handle some errors in IPv6 packets? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grigory Grigory Kljuchnikov wrote: > > Hello, > > I have several questions about handling exceptional situations > in IPv6 packets: > > 1. How to process packets that have incorrect version number? > Should we discard it or send an ICMPv6 error message? > Ethernet header has an identifier of the included ip-level protocol > packet. Suppose that it identifies the IPv6 packet but the Version > fields of the IPv6 header is not 6. What to do in this case? > Send an error, discard the packet or something else? What do you do for IPv4? Do the same for consisency. Most implementations increment an error counter and drop the packet. > > 2. How to process packets that have incorrect payload length field? > Should we discard it or send an ICMPv6 error message? > IP receives from LAN an array of octets as well as it's length. > If payload length field contains correct value then that length is > equal to the payload length plus 40 (the length of the header). > What to do if the payload length does not match the length of > the octets array received from the LAN level? Should we send > an ICMP error message or silently discard the message? If the payload is bigger then the actual packet, we updated error counters and drop. Otherwise, you have all the necessary data, so you can process the packet. > > 3. What to do when the total size of options does not match the size > of the header (Hop-by-hop and Destination options headers)? > Each TLV options contains it's data size. What implementations are > supposed to do if the total length of options (calculated from their > Option Data length fields) does not match the length of the header? Our implementation sends a ICMPv6 Parameter Problem code 0 message (ICMP6_PARAMPROB_HEADER) for non-multicast packets. > > 4. Jumbo Payload options errors. > What to do if Jumbo Payload option length is not equal to 4? We send ICMPV6 Parementer Problem code 0 message for non-multicast. > What to do if there are several Jumbo Payload options in > hop-by-options header? > Good question. I would guess it's an error...? > 5. What to do with malformed fragments sequences? > There several possible exceptional situations not covered by > RFC 2460 Section 4.5 such as: > 5.1 Fragments overlap. If you don't handle overlaping fragments, the easiest thing to do is just drop it. We provide an admin knob for handling overlaping fragments. > 5.2 Suppose we have received a fragment with M flag set to 0 > ("rightmost" fragment). Then an exception is a fragment with M flag > set to 1 offset greater than the offset of the "rightmost" fragment. > How implementations are supposed to handle these cases? I am assuming in your example that you recived fragment with M=0 before the fragment with M=1. If the fragment with M=0 completed your fragment chain, you'll end up delivering the packet. The fragment with M=1 will start a new chain. If the fragment with M=0 did not complete your chain (i.e. you have holes), then you can just drop the fragment with M=1 and wait for the chain to complete. -vlad > > Grigory Klyuchnikov, System Engineer, > Institute for System Programming > Russian Academy of Sciences > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 9 10:24:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HOaML025724 for ; Tue, 9 Oct 2001 10:24:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99HOaKK025723 for ipng-dist; Tue, 9 Oct 2001 10:24:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99HOYML025716 for ; Tue, 9 Oct 2001 10:24:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f99HLpv24403 for ipng@sunroof.eng.sun.com; Tue, 9 Oct 2001 10:21:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f98Jm7ML022507 for ; Mon, 8 Oct 2001 12:48:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04175; Mon, 8 Oct 2001 12:48:08 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27218; Mon, 8 Oct 2001 13:47:57 -0600 (MDT) Received: from scoya.cnri.reston.va.us (scoya.cnri.reston.va.us [10.27.5.106]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29835; Mon, 8 Oct 2001 15:48:02 -0400 (EDT) Date: Mon, 8 Oct 2001 15:41:40 -0400 (Eastern Daylight Time) From: Steve Coya To: Bob Hinden cc: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Request to Advance "Default Address Selection for IPv6" In-Reply-To: <4.3.2.7.2.20011001164134.022d3ca8@mailhost.iprg.nokia.com> Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm writing to acknowledge receipt of your request. It will appear on the Requests web page after being updated tonight. Note that this does not imply any action on the IESG's part; just that your request has been received and will be posted. Steve On Mon, 1 Oct 2001, Bob Hinden wrote: >>Erik, 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 : Default Address Selection for IPv6 >> Author(s) : R. Draves >> Filename : draft-ietf-ipngwg-default-addr-select-06.txt >> Pages : 22 >> Date : 28-Sep-01 >> >>A working group last call for this document was completed on June 7, >>2001. The "-06" draft was produced in response to comments made during the >>w.g. last call and subsequent discussion. The document was discussed at >>the London IETF and the w.g. agreed advancing it to Proposed Standard once >>the new draft was published. >> >>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 Oct 9 16:12:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99NCGML027008 for ; Tue, 9 Oct 2001 16:12:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f99NCFP5027007 for ipng-dist; Tue, 9 Oct 2001 16:12:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f99NCCML027000 for ; Tue, 9 Oct 2001 16:12:12 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11449 for ; Tue, 9 Oct 2001 16:12:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09541 for ; Tue, 9 Oct 2001 16:12:13 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA17389; Tue, 9 Oct 2001 16:12:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f99NCCa18120; Tue, 9 Oct 2001 16:12:12 -0700 X-mProtect: Tue, 9 Oct 2001 16:12:12 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdVZhAbg; Tue, 09 Oct 2001 16:12:09 PDT Message-Id: <4.3.2.7.2.20011009160536.022b66a8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Oct 2001 16:11:56 -0700 To: "Brian Haberman" From: Bob Hinden Subject: Re: VRRPv6? Cc: vrrp@drcoffsite.com, ipng@sunroof.eng.sun.com In-Reply-To: <3BC2FDE4.F0A794AD@americasm06.nt.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >I agree with your assessment. Having VRRP functionality accomplishes >more than simply depending on NUD. However, the current VRRP spec >has no support whatsoever for IPv6. In addition, there may be issues >that need to be addressed where VRRP, as defined for IPv4, causes >operational problems in IPv6 (DAD for instance). > >Anyone in VRRP looking at VRRPv6??? Other than some discussion, there hasn't been any work done on an IPv6 version of VRRP. It is within the scope of the VRRP w.g., so if there was sufficient interest (i.e., someone wanted to write a draft), it could be done there. Also, there is still time to request a meeting slot for VRRP to meet in Salt Lake City. Are you interested in working on this? I have the nroff for the current version of VRRP. I don't think it would be too hard to adapt it to IPv6. 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 Oct 11 02:04:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B94hML005679 for ; Thu, 11 Oct 2001 02:04:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9B94hWe005678 for ipng-dist; Thu, 11 Oct 2001 02:04:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9B94ZML005663; Thu, 11 Oct 2001 02:04:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06398; Thu, 11 Oct 2001 02:04:37 -0700 (PDT) Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01455; Thu, 11 Oct 2001 03:04:25 -0600 (MDT) Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA06983; Thu, 11 Oct 2001 19:03:28 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA00829; Thu, 11 Oct 2001 19:04:34 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Oct 2001 19:04:33 +1000 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'mobile-ip@sunroof.eng.sun.com'" , ipng@sunroof.eng.sun.com Subject: Date: Thu, 11 Oct 2001 19:04:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, [I'm ccing IPng for the interpretation of RFC 2460 ] > If one reads the last paragraph of page 6 one can read it two ways: > > Either: "With one exception, extension headers are not examined or > processed > by any node along a packet's delivery path.." meaning hop-by-hop options > header. Then, "If, as a result of processing a header, a node is required > to proceed to the next header, but the Next Header value in the current > header is unrecognized..", could mean: possible existence of hop-by-hop > options header "must be examined" resulting in that after IPv6 header > the "required to proceed" condition is met, but the Next Header is > unknown, > this would result in the discarding rule. There is, luckily, even in this > case, the possibility to ignore this. > > Or: That there is not h-b-h next header invalidates the "must be examined" > rule and one could skip an unknown number (just forwarding the packet > irrespective what garbage there is at its end). I hope this could be > the correct interpretation since the h-b-h must immediately follow the > IPv6 header. Unless someone challenges this order rule with a new header, > or someone comes with a new h-b-h option requiring proceeding to something > else, this could hopefully be the "right interpretation". > => I believe so, but you could also check that on IPng. Anyhow, the new header value we've been discussing is a new DST-opt header which will only be processed by the end nodes. If a router is forwarding a packet and the first header below the IPv6 header is not h-b-h then I see no reason for it to recognise/process this header. > If someone observes the former, it would risk that there are boxes that > drop packets with new unknown next headers. In the latter there would not > be. Our boxes do the right thing, but can it be guaranteed so do others? > => It sounds like the others are faulty if they're doing the opposite. Faulty boxes do exist I suppose, we can't design protocols around them. Having said that, I haven't seen anyone saying they implemented their boxes in this way. > This could have been clearer in the text saying that routers must ignore > next headers other than h-b-h. But, this would not be the first RFC in > routing where "well-known" implementation guidelines help interpret the > actual text. > > Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 11 05:39:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BCdGML006311 for ; Thu, 11 Oct 2001 05:39:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BCdGAC006310 for ipng-dist; Thu, 11 Oct 2001 05:39:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BCd8ML006295; Thu, 11 Oct 2001 05:39:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07411; Thu, 11 Oct 2001 05:39:10 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00729; Thu, 11 Oct 2001 06:38:57 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f9BCelA02666; Thu, 11 Oct 2001 19:40:48 +0700 (ICT) From: Robert Elz To: "Hesham Soliman (EPA)" cc: "'mobile-ip@sunroof.eng.sun.com'" , ipng@sunroof.eng.sun.com Subject: Re: In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se> References: <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Oct 2001 19:40:47 +0700 Message-ID: <2664.1002804047@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 11 Oct 2001 19:04:26 +1000 From: "Hesham Soliman (EPA)" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A51308ED45@eaubrnt018.epa.ericsson.se> | > If one reads the last paragraph of page 6 one can read it two ways: I think way too much is being read into that. Routers are only required to look at the IPv6 header, and the HbH options header if one exists. Only if there is some problem with one of those will a router drop a packet (for IPv6 reasons, as distinct from congestion, no route, etc). The If, as a result of processing a header, a node is required to proceed to the next header, ... means "where a node has to look at the next header", then if its type is unknown, the packet has to be dropped. A router never looks at the next header, unless its type is "HbH" - in which case (one hopes) it isn't an unknown type. Note: it doesn't say that if you process a header and it contains an unknown next header field you drop the packet - only if you have to process the next header, and its type (which comes from the current header) is unknown. Routers never have to process the next header... ie: your reply is right, the question is assuming things the text doesn't say. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 11 08:07:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BF7TML006613 for ; Thu, 11 Oct 2001 08:07:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BF7TOv006612 for ipng-dist; Thu, 11 Oct 2001 08:07:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BF7PML006603 for ; Thu, 11 Oct 2001 08:07:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08971; Thu, 11 Oct 2001 08:07:27 -0700 (PDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29228; Thu, 11 Oct 2001 08:07:25 -0700 (PDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA15348; Thu, 11 Oct 2001 17:07:23 +0200 Received: from dhcp23-95.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59544 from ; Thu, 11 Oct 2001 17:07:21 +0200 Message-Id: <3BC5B437.E5D329E3@hursley.ibm.com> Date: Thu, 11 Oct 2001 17:01:11 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: Request to Advance "Default Address Selection for IPv6" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: ... > So "all IPv6 nodes capable of sitting behind a SIIT translator" catches > what I tried to say. That "behind" is not quite self-defining. I think you need to spell out which side of the translator is "behind". Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 11 14:02:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BL2uML009515 for ; Thu, 11 Oct 2001 14:02:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9BL2um7009514 for ipng-dist; Thu, 11 Oct 2001 14:02:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9BL2qML009507 for ; Thu, 11 Oct 2001 14:02:52 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12376 for ; Thu, 11 Oct 2001 14:02:55 -0700 (PDT) Received: from hotmail.com (f173.law14.hotmail.com [64.4.21.173]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04210 for ; Thu, 11 Oct 2001 14:02:55 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Oct 2001 14:02:55 -0700 Received: from 200.194.240.101 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 11 Oct 2001 21:02:53 GMT X-Originating-IP: [200.194.240.101] From: "marcelo tostes" To: ipng@sunroof.eng.sun.com Subject: Differentiated Services Date: Thu, 11 Oct 2001 21:02:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2001 21:02:55.0047 (UTC) FILETIME=[18F79570:01C15298] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I wish to know what the best definition to Differentiated Services and how work IPv6 with this? Marcelo Vaz Tostes Network Analyst _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 12 03:03:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CA3lML011554 for ; Fri, 12 Oct 2001 03:03:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CA3lQ9011553 for ipng-dist; Fri, 12 Oct 2001 03:03:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CA3dML011538; Fri, 12 Oct 2001 03:03:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29426; Fri, 12 Oct 2001 03:03:40 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04747; Fri, 12 Oct 2001 04:03:22 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9CA3Ti05863; Fri, 12 Oct 2001 13:03:29 +0300 Date: Fri, 12 Oct 2001 13:03:29 +0300 (EEST) From: Pekka Savola To: cc: Subject: IPv6 Routing Header, Home Address security draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, (I think mobile-ip@ is probably the best place for possible follow-ups) I've submitted the following "Informational-nature" draft to internet-drafts: "Security of IPv6 Routing Header and Home Address Options" http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-ha-security-00.txt This raises the concern, among others, on MIPv6-imposed requirements and recommendations for _all_ IPv6 nodes. Binding Updates is a different problem, being discussed separately, and only RH and HA are covered. It should be noted, of course, that there are very valid uses for routing header outside of mobile ip too. But MIPv6 imposes some requirements for RH use, so it might be better to restrict its use in some way or another. The abstract: All IPv6 nodes must be able to process Routing Header [IPV6] and Home Address [MIPV6] Options. With these, packet filter access lists can be tricked (among other things) as the destination and source addresses, respectively, are being rewritten as the packet traverses the network. Some of the security considerations of these features are analyzed, and a few possible solutions presented. It will be shown that with the current architecture, the network-based security does not seem to scale to the requirements of Mobile IPv6; it seems possible that unless security is taken seriously when implementing the nodes, the new Mobile IPv6 requirements might not be allowed to be used at all in some circumstances. Comments welcome, of course. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 12 03:06:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CA6WML011609 for ; Fri, 12 Oct 2001 03:06:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9CA6WML011608 for ipng-dist; Fri, 12 Oct 2001 03:06:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9CA6SML011598 for ; Fri, 12 Oct 2001 03:06:28 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29791 for ; Fri, 12 Oct 2001 03:06:29 -0700 (PDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16159 for ; Fri, 12 Oct 2001 03:06:27 -0700 (PDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id MAA10216; Fri, 12 Oct 2001 12:06:26 +0200 Received: from dhcp23-95.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25974 from ; Fri, 12 Oct 2001 12:06:23 +0200 Message-Id: <3BC6C016.72570B38@hursley.ibm.com> Date: Fri, 12 Oct 2001 12:04:06 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: marcelo tostes Cc: ipng@sunroof.eng.sun.com Subject: Re: Differentiated Services References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Read RFC 2474 and 2475. They apply 100% to IPv6. Brian marcelo tostes wrote: > > Hello, > > I wish to know what the best definition to Differentiated Services and how > work IPv6 with this? > > Marcelo Vaz Tostes > Network Analyst -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 15 04:00:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FB0kML018504 for ; Mon, 15 Oct 2001 04:00:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9FB0khA018503 for ipng-dist; Mon, 15 Oct 2001 04:00:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9FB0fML018496 for ; Mon, 15 Oct 2001 04:00:41 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00863 for ; Mon, 15 Oct 2001 04:00:37 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29993 for ; Mon, 15 Oct 2001 04:00:40 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23057; Mon, 15 Oct 2001 07:00:39 -0400 (EDT) Message-Id: <200110151100.HAA23057@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-03.txt Date: Mon, 15 Oct 2001 07:00:38 -0400 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 : Unicast-Prefix-based IPv6 Multicast Addresses Author(s) : B. Haberman, D. Thaler Filename : draft-ietf-ipngwg-uni-based-mcast-03.txt Pages : 6 Date : 12-Oct-01 This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-uni-based-mcast-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-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: <20011012150927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-uni-based-mcast-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011012150927.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 Oct 16 07:57:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEvVOI002617 for ; Tue, 16 Oct 2001 07:57:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GEvUu0002616 for ipng-dist; Tue, 16 Oct 2001 07:57:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GEvROI002609 for ; Tue, 16 Oct 2001 07:57:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07478 for ; Tue, 16 Oct 2001 07:57:29 -0700 (PDT) Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA29732 for ; Tue, 16 Oct 2001 09:11:13 -0600 (MDT) Received: (qmail 60912 invoked from network); 16 Oct 2001 14:49:59 -0000 Received: from unknown (HELO gate.ispras.ru) (194.67.37.200) by pluton.ispras.ru with SMTP; 16 Oct 2001 14:49:59 -0000 Received: from ispgate (ispgate [194.67.37.200]) by gate.ispras.ru (8.11.2/8.11.1) with ESMTP id f9GEups22513 for ; Tue, 16 Oct 2001 18:56:59 +0400 (MSK) Date: Tue, 16 Oct 2001 18:56:51 +0400 (MSK) From: Grigory Kljuchnikov To: Subject: Receiving multicast messages in UDP sockets question. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, RFC 2553 says: Note that to receive multicast datagrams a process must join the multicast group and bind the UDP port to which datagrams will be sent. Some processes also bind the multicast group address to the socket, in addition to the port, to prevent other datagrams destined to that same port from being delivered to the socket. Please, clarify the quotation. How does socket address affect messages receiving? There are four possible cases. 1. Socket is bound to a port (address left unspecified) and joined several multicast groups. 2. Socket is bound to a unicast address and a port and joined several multicast groups. 3. Socket is bound to a multicast address and a port and joined several multicast groups, one group has the address that the socket is bound to. 4. Socket is bound to a multicast address and a port and joined several multicast groups, and none of the groups has the address that the socket is bound to. In the first case socket receives all multicast messages, that are sent to addresses of it's groups (and received on corresponding interfaces) and the socket's port. Right? In the second case socket receives unicast packets sent to the socket's address+port AND all multicast messages sent to addresses of it's groups (and received on corresponding interfaces) and the socket's port. Right? QUESTION: What messages should the socket receive in the third and fourth cases? Grigory Klyuchnikov, System Engineer, Institute for System Programming Russian Academy of Sciences -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 16 12:23:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJNZOI004740 for ; Tue, 16 Oct 2001 12:23:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9GJNZAB004739 for ipng-dist; Tue, 16 Oct 2001 12:23:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9GJNVOI004732 for ; Tue, 16 Oct 2001 12:23:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18881 for ; Tue, 16 Oct 2001 12:23:28 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17476 for ; Tue, 16 Oct 2001 12:23:33 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9GJNVa10975 for ; Tue, 16 Oct 2001 22:23:31 +0300 Date: Tue, 16 Oct 2001 22:23:31 +0300 (EEST) From: Pekka Savola To: Subject: Extension Header Capability Discovery needed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, RFC2460 specifies that if an unknown extension header is encountered, the packet must be dropped. (note: in IPv4, options MUST be ignored if not recognized; the chaining makes this different, though). In practise this seems to suggest that the sending node must always be sure beforehand which extension headers the recipient supports (think e.g. some MIPv6 feature or new ISPEC feature or whatever). In practise this seems to mean either: 1) never define new extension headers (except in _very_ controlled scenarios, like new payload protocols) 2) implement some form of 'extension header capability discovery'. A workaround is to stuff everything you'd want in an extension header into destination options instead where you can define its discard/ignore behaviour. Was this side-effect of header chaining considered when specifying IPv6? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 01:26:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H8QGOI006979 for ; Wed, 17 Oct 2001 01:26:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9H8QGCU006978 for ipng-dist; Wed, 17 Oct 2001 01:26:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9H8QCOI006971 for ; Wed, 17 Oct 2001 01:26:12 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01059 for ; Wed, 17 Oct 2001 01:26:16 -0700 (PDT) Received: from web9203.mail.yahoo.com (web9203.mail.yahoo.com [216.136.129.26]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA29100 for ; Wed, 17 Oct 2001 01:26:16 -0700 (PDT) Message-ID: <20011017082615.14899.qmail@web9203.mail.yahoo.com> Received: from [161.139.68.13] by web9203.mail.yahoo.com via HTTP; Wed, 17 Oct 2001 01:26:15 PDT Date: Wed, 17 Oct 2001 01:26:15 -0700 (PDT) From: pat nanthan Subject: ipsec solving ARP poisoning To: 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 I need some information on opportunistic IPsec and IPv6 that could solve active sniffing of ARP poisoning in a ethernet LAN. thanks. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.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 Oct 17 03:26:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HAQhOI007484 for ; Wed, 17 Oct 2001 03:26:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9HAQgXW007483 for ipng-dist; Wed, 17 Oct 2001 03:26:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9HAQdOI007476 for ; Wed, 17 Oct 2001 03:26:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13292 for ; Wed, 17 Oct 2001 03:26:40 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14121 for ; Wed, 17 Oct 2001 03:26:39 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f9HATOv02088; Wed, 17 Oct 2001 17:29:25 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Extension Header Capability Discovery needed? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Oct 2001 17:29:24 +0700 Message-ID: <2086.1003314564@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 16 Oct 2001 22:23:31 +0300 (EEST) From: Pekka Savola Message-ID: When I saw your message (its Subject anyway) I thought you might have going to propose a method for... | 2) implement some form of 'extension header capability discovery'. which might be a useful thing to have. But all you really did was ask... | Was this side-effect of header chaining considered when specifying IPv6? to which the answer is yes, and ... | 1) never define new extension headers (except in _very_ controlled | scenarios, like new payload protocols) was essentially the response - there are just 256 header codes, no-one wanted defining a new one to be something easy. | A workaround is to stuff everything you'd want in an extension header into | destination options Where what is needed fits as an option, that works just fine. The real problem of course is that there's no fixed header layout format, and given that TCP, UDP (and encapsulated IP of various flavours) are some of the headers, there never was a chance for there to have been one. That means that we can't predict the length of the header, nor where in it to find the next header field. What we could do, which I don't recall being explored, is to define a couple of prototype header layouts, perhaps one for cases where an 8 bit length (counting 64 bit units) will do, and one for a 16 bit length (counting bytes probably), and set aside a range of header numbers that we define will only include headers of a defined format (and headers that can be safely ignored, or perhaps the defined format also gets an ignore/drop bit as well). That is, perhaps headers numbers 192-255 could be ones with a defined format with a 16 bit length field, and 128-191 could be ones with a defined format and an 8 bit length field. Headers with id numbers < 128 would be of any random format (as now), and the "must drop if unknown" semantics would continue. Then, if there was a need to define a new header, and the use of the header makes it rational for the recipient to simply ignore the header and continue processing the rest of the packet, then the header could be designed to fit one of the known format layouts, so it could be safely ignored. Whether this would go too far towards making it too easy to define new headers though I'm not sure - possibly. 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 Oct 17 19:06:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I26gOI011279 for ; Wed, 17 Oct 2001 19:06:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I26gxB011278 for ipng-dist; Wed, 17 Oct 2001 19:06:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I26bOI011271 for ; Wed, 17 Oct 2001 19:06:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27911 for ; Wed, 17 Oct 2001 19:06:32 -0700 (PDT) Received: from newexchange.domain.com ([202.106.106.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02747 for ; Wed, 17 Oct 2001 20:06:08 -0600 (MDT) Received: from liangxg ([202.106.106.126]) by newexchange.domain.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Oct 2001 09:57:45 +0800 Message-ID: <001101c15779$7ff7f360$7dce12ac@MCSD.local> From: "Xingang Liang" To: Subject: ATM,IP, and the Future! Date: Thu, 18 Oct 2001 10:06:27 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C157BC.8D3A9760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 18 Oct 2001 01:57:45.0593 (UTC) FILETIME=[47D52E90:01C15778] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C157BC.8D3A9760 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksbXkgZnJpZW5kcyENCk15IHF1ZXN0aW9ucyBhcmUgYXMgZm9sbG93Og0KICAgICAgICAgICBX aHkgZG9lcyB0aGUgSVAgdGVjaG5vbG9neSBiZWNvbWUgdGhlIG5ldyBjb3NzZXQgb2YgR29kIGlu c3RlYWQgb2YgQVRNP0Zyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHBhY2tldC1zd2l0Y2hpbmcgdGVj aG5vbG9neSxJUCBhbmQgQVRNIGJlbG9uZyB0byB0aGUgc2FtZSBjYXRlZ29yeSx0aGF0IGlzICx0 aGV5IGFsbCB1c2UgdGhlIHBhY2tldCAoZGF0YWdyYW0gaW4gSVAgYW5kIGNlbGwgaW4gQVRNKSB0 byB0cmFuc21pdCB0cmFmZmljLkJlc2lkZXMsSVAgY2FuIG5vdCBwcm92aWRlIHRoZSBzYW1lIFFv UyBzZXJ2aWNlIGFzIEFUTSx3aGljaCB1c2UgdGhlIFZDcyB0byBwcm92aWRlIHBlcmZlY3QgcGVy Zm9ybWFuY2UgYW5kIGNhbiByZWFjaCB2ZXJ5IGhpZ2ggc3BlZWQuTWFueSBidXNpbmVzcyBvcGVy YXRvcnMgaGF2ZSBvd25lZCBhIGdyZWF0IGRlYWwgb2YgQVRNIGRldmljZXMuSWYgd2UgY2hvb3Nl IHRoZSBJUCxob3cgc2hvdWxkIHdlIGRlYWwgd2l0aCB0aGUgcmVtYWluaW5nIEFUTSBzd2l0Y2gg YW5kIHJvdXRlcnM/SG93IHNob3VsZCB3ZSByZXBsYWNlIHRoZSBiYWNrYm9uZSBvZiBJbnRlcm5l dCx3aGljaCBpcyBlcXVpcHBlZCB3aXRoIEFUTSB0ZWNobm9sb2d5Pw0KICAgICAgICAgICBJIGtu b3cgSVAgd2lsbCBiZSB0aGUgbXVzdCB0cmVuZCBvZiBuZXR3b3JrIGRldmVsb3BtZW50LGluY2x1 ZGluZyBJbnRlcm5ldCBhbmQgTW9iaWxlIG5ldHdvcmsoM0cpLGFuZCBJIGtub3cgSVAgY2FuIGJy aW5nIGEgbG90IG9mIGJlbmVmaXRzIHRvIG91ciBsaXZlcy5CdXQganVzdCBhcyB3ZSBldmVyIGNs YWltZWQgdGhhdCBBVE0gd291bGQgZG9taW5hdGUgdGhlIHdob2xlIG5ldCB3b3JsZCx0aGUgc2Ft ZSBxdWVzdGlvbiBjb25mcm9udHMgdXMgdGhhdCB3aWxsIElQIGFsc28gYmUgdGhlIGJlc3QgYW5k IGRvbWluYXRlIHRoZSB3aG9sZSB3b3JsZD8gDQogICAgICAgICAgIFBlcmhhcHMgd2Ugc2hvdWxk IHRha2UgYSBjYXJlZnVsIHRoaW5raW5nIGFib3V0IHRoZSBuZWNlc3NhY2l0eSBvZiBJUCByZXBs YWNpbmcgQVRNLldlIHNob3VsZCBwYXkgbW9yZSBhdHRlbnRpb24gdG8gdGhlIHF1ZXN0aW9uICJX aGF0IHRlY2hub2xvZ3kgd2lsbCBkb21pbmF0ZSB0aGUgbmV0d29yayBhZnRlciBJUCBhbmQgaG93 IHNob3VsZCB3ZSBkZWFsIHdpdGggaXQ/Ig0KICAgICAgICAgICBJIGhvcGUgeW91LG15IGZyaWVu ZHMsY2FuIGdpdmUgc29tZSBjb21wYXJpc2lvbiBvZiBJUCB2cyBBVE0tLS1zbyB0aGF0IHdlIGNh biBmaW5kIHRoZSBtdXN0LGFuZCBzb21lIHByZWRpY3RzIG9mIHRoZSBmdXR1cmUtLXNvIHRoYXQg d2UgY2FuIGZpbmQgdGhlIGJlc3QhDQogICAgICAgICAgV2VsY29tZSBhbnkgY29tbWVudHMgYW5k IHNheSBzb3JyeSB0byB3aG9tIEkgYm90aGVyZWQgd2l0aCBteSBxdWVzdGlvbnMhDQogICAgICAg ICAgVGhhbmsgeW91IQ0KDQpCUg0KDQpYaW5nYW5nIExpYW5nDQpTdGFuZGFyZGl6YXRpb24gRGVw YXJ0bWVudA0KTW9iaWxlIENvbW11bmljYXRpb24gUiZEIENlbnRlcg0KQ2hpbmEgQWNhZGVteSBv ZiBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2d5KENBVFQpDQpOby40MCxYdWV5dWFuIFJvYWQN CkJlaWppbmcsQ2hpbmENCjEwMDA4Mw0KVGVsOis4NjEwIDYyMzA0NDIyRVhUMjI1DQpGYXg6Kzg2 MTAgNjIzMDMxMjcNCk1haWx0bzpsaWFuZ3hnQGNhdHQuYWMuY24NCg0K ------=_NextPart_000_000E_01C157BC.8D3A9760 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4zMzE1LjI4NzAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkhpLG15 IGZyaWVuZHMhPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5NeSBx dWVzdGlvbnMmbmJzcDthcmUgYXMgZm9sbG93OjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtXaHkmbmJzcDtkb2VzIA0KdGhlIElQIHRlY2hub2xv Z3kgYmVjb21lIHRoZSBuZXcgY29zc2V0IG9mIEdvZCBpbnN0ZWFkIG9mIEFUTT9Gcm9tIHRoZSAN CnBlcnNwZWN0aXZlIG9mIHBhY2tldC1zd2l0Y2hpbmcgdGVjaG5vbG9neSxJUCBhbmQgQVRNIGJl bG9uZyB0byB0aGUgc2FtZSANCmNhdGVnb3J5LHRoYXQgaXMgLHRoZXkgYWxsIHVzZSB0aGUgcGFj a2V0IChkYXRhZ3JhbSBpbiBJUCBhbmQgY2VsbCBpbiBBVE0pIHRvIA0KdHJhbnNtaXQgdHJhZmZp Yy5CZXNpZGVzLElQIGNhbiBub3QgcHJvdmlkZSB0aGUgc2FtZSBRb1Mgc2VydmljZSBhcyBBVE0s d2hpY2ggDQp1c2UgdGhlIFZDcyB0byBwcm92aWRlIHBlcmZlY3QgcGVyZm9ybWFuY2UgYW5kIGNh biZuYnNwO3JlYWNoIHZlcnkgaGlnaCANCnNwZWVkLk1hbnkgYnVzaW5lc3Mgb3BlcmF0b3JzIGhh dmUgb3duZWQgYSBncmVhdCBkZWFsIG9mIEFUTSBkZXZpY2VzLklmIHdlIA0KY2hvb3NlIHRoZSBJ UCxob3cgc2hvdWxkIHdlIGRlYWwgd2l0aCB0aGUgcmVtYWluaW5nIEFUTSBzd2l0Y2ggYW5kIHJv dXRlcnM/SG93IA0Kc2hvdWxkIHdlIHJlcGxhY2UgdGhlIGJhY2tib25lIG9mIEludGVybmV0LHdo aWNoIGlzIGVxdWlwcGVkIHdpdGggQVRNIA0KdGVjaG5vbG9neT88L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBrbm93IA0KSVAgd2lsbCBiZSB0 aGUmbmJzcDttdXN0IHRyZW5kIG9mIG5ldHdvcmsgZGV2ZWxvcG1lbnQsaW5jbHVkaW5nIEludGVy bmV0IGFuZCANCk1vYmlsZSBuZXR3b3JrKDNHKSxhbmQgSSBrbm93IElQIGNhbiBicmluZyBhIGxv dCBvZiBiZW5lZml0cyB0byBvdXIgbGl2ZXMuQnV0IA0KanVzdCBhcyB3ZSBldmVyIGNsYWltZWQg dGhhdCBBVE0gd291bGQgZG9taW5hdGUgdGhlIHdob2xlIG5ldCB3b3JsZCx0aGUgc2FtZSANCnF1 ZXN0aW9uIGNvbmZyb250cyB1cyZuYnNwO3RoYXQmbmJzcDt3aWxsIElQIGFsc28gYmUgdGhlIGJl c3QgYW5kJm5ic3A7ZG9taW5hdGUgDQp0aGUgd2hvbGUgd29ybGQ/IDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGVyaGFwcyB3ZSANCnNob3VsZCB0YWtl IGEgY2FyZWZ1bCB0aGlua2luZyZuYnNwO2Fib3V0IHRoZSBuZWNlc3NhY2l0eSBvZiBJUCByZXBs YWNpbmcgQVRNLldlIA0Kc2hvdWxkIHBheSBtb3JlIGF0dGVudGlvbiB0byB0aGUgcXVlc3Rpb24g IldoYXQgdGVjaG5vbG9neSB3aWxsIA0KZG9taW5hdGUmbmJzcDt0aGUgbmV0d29yayBhZnRlciBJ UCBhbmQgaG93IHNob3VsZCB3ZSBkZWFsIHdpdGggaXQ/IjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBob3BlIA0KeW91LG15IGZyaWVuZHMsY2FuIGdp dmUgc29tZSBjb21wYXJpc2lvbiBvZiBJUCB2cyBBVE0tLS1zbyB0aGF0IHdlIGNhbiBmaW5kIHRo ZSANCm11c3QsYW5kIHNvbWUgcHJlZGljdHMgb2YgdGhlIGZ1dHVyZS0tc28gdGhhdCB3ZSBjYW4g ZmluZCB0aGUgYmVzdCE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgDQpzaXpl PTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7V2VsY29tZSBhbnkgDQpjb21tZW50cyBhbmQgc2F5IHNvcnJ5IHRvIHdob20gSSBib3Ro ZXJlZCB3aXRoIG15IHF1ZXN0aW9ucyE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRoYW5rIA0KeW91ITwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkJSPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+WGluZ2FuZyBMaWFuZzxCUj5TdGFu ZGFyZGl6YXRpb24gDQpEZXBhcnRtZW50PEJSPk1vYmlsZSBDb21tdW5pY2F0aW9uIFImYW1wO0Qg Q2VudGVyPEJSPkNoaW5hIEFjYWRlbXkgb2YgDQpUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2d5 KENBVFQpPEJSPk5vLjQwLFh1ZXl1YW4gDQpSb2FkPEJSPkJlaWppbmcsQ2hpbmE8QlI+MTAwMDgz PEJSPlRlbDorODYxMCA2MjMwNDQyMkVYVDIyNTxCUj5GYXg6Kzg2MTAgDQo2MjMwMzEyNzxCUj48 QSANCmhyZWY9Im1haWx0bzpsaWFuZ3hnQGNhdHQuYWMuY24iPk1haWx0bzpsaWFuZ3hnQGNhdHQu YWMuY248L0E+PEJSPjwvRElWPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000E_01C157BC.8D3A9760-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 19:36:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I2aOOI011443 for ; Wed, 17 Oct 2001 19:36:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I2aN4E011442 for ipng-dist; Wed, 17 Oct 2001 19:36:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I2aKOI011435 for ; Wed, 17 Oct 2001 19:36:20 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21197 for ; Wed, 17 Oct 2001 19:36:22 -0700 (PDT) Received: from newexchange.domain.com ([202.106.106.102]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23959 for ; Wed, 17 Oct 2001 19:36:21 -0700 (PDT) Received: from liangxg ([202.106.106.126]) by newexchange.domain.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Oct 2001 10:27:44 +0800 Message-ID: <003c01c1577d$b078a670$7dce12ac@MCSD.local> From: "Xingang Liang" To: Subject: ATM,IP, and the Future!------send again with plain text! Date: Thu, 18 Oct 2001 10:36:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 18 Oct 2001 02:27:44.0940 (UTC) FILETIME=[7853BEC0:01C1577C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9I2aKOI011436 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Permit me to send again with plain text,Sorry! Hi,my friends! My questions are as follow: Why does the IP technology become the new cosset of God instead of ATM?From the perspective of packet-switching technology,IP and ATM belong to the same category,that is ,they all use the packet (datagram in IP and cell in ATM) to transmit traffic.Besides,IP can not provide the same QoS service as ATM,which use the VCs to provide perfect performance and can reach very high speed.Many business operators have owned a great deal of ATM devices.If we choose the IP,how should we deal with the remaining ATM switch and routers?How should we replace the backbone of Internet,which is equipped with ATM technology? I know IP will be the must trend of network development,including Internet and Mobile network(3G),and I know IP can bring a lot of benefits to our lives.But just as we ever claimed that ATM would dominate the whole net world,the same question confronts us that will IP also be the best and dominate the whole world? Perhaps we should take a careful thinking about the necessacity of IP replacing ATM.We should pay more attention to the question "What technology will dominate the network after IP and how should we deal with it?" I hope you,my friends,can give some comparision of IP vs ATM---so that we can find the must,and some predicts of the future--so that we can find the best! Welcome any comments and say sorry to whom I bothered with my questions! Thank you! BR Xingang Liang Standardization Department Mobile Communication R&D Center China Academy of Telecommunication Technology(CATT) No.40,Xueyuan Road Beijing,China 100083 Tel:+8610 62304422EXT225 Fax:+8610 62303127 Mailto:liangxg@catt.ac.cn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 22:29:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5TQOI012438 for ; Wed, 17 Oct 2001 22:29:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I5TQDK012437 for ipng-dist; Wed, 17 Oct 2001 22:29:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5TNOI012430 for ; Wed, 17 Oct 2001 22:29:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11795 for ; Wed, 17 Oct 2001 22:29:24 -0700 (PDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03051 for ; Wed, 17 Oct 2001 22:29:22 -0700 (PDT) Received: from localhost (eleskg@localhost) by leonis.nus.edu.sg (8.10.0/8.10.0) with SMTP id f9I5Sm300675; Thu, 18 Oct 2001 13:28:50 +0800 (SST) Date: Thu, 18 Oct 2001 13:28:48 +0800 From: "SEAH, Khoon Guan Winston" Reply-To: Winston Seah To: Xingang Liang cc: ipng@sunroof.eng.sun.com Subject: Re: ATM,IP, and the Future! In-Reply-To: <001101c15779$7ff7f360$7dce12ac@MCSD.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's relatively sImPler! Though, I don't know how long this will be the case... -- SEAH, Khoon Guan Winston (Dr.Eng.) Programme Director, Internet Technologies Centre for Wireless Communications 20 Science Park Road, #02-34/37 TeleTech Park Singapore Science Park II, Singapore 117674. Contact: +65 870 9163(Tel)/779 5441(Fax) Email: winston@cwc.nus.edu.sg On Thu, 18 Oct 2001, Xingang Liang wrote: > Hi,my friends! > My questions are as follow: > Why does the IP technology become the new cosset of God instead of ATM?From the perspective of packet-switching technology,IP and ATM belong to the same category,that is ,they all use the packet (datagram in IP and cell in ATM) to transmit traffic.Besides,IP can not provide the same QoS service as ATM,which use the VCs to provide perfect performance and can reach very high speed.Many business operators have owned a great deal of ATM devices.If we choose the IP,how should we deal with the remaining ATM switch and routers?How should we replace the backbone of Internet,which is equipped with ATM technology? > I know IP will be the must trend of network development,including Internet and Mobile network(3G),and I know IP can bring a lot of benefits to our lives.But just as we ever claimed that ATM would dominate the whole net world,the same question confronts us that will IP also be the best and dominate the whole world? > Perhaps we should take a careful thinking about the necessacity of IP replacing ATM.We should pay more attention to the question "What technology will dominate the network after IP and how should we deal with it?" > I hope you,my friends,can give some comparision of IP vs ATM---so that we can find the must,and some predicts of the future--so that we can find the best! > Welcome any comments and say sorry to whom I bothered with my questions! > Thank you! > > BR > > Xingang Liang > Standardization Department > Mobile Communication R&D Center > China Academy of Telecommunication Technology(CATT) > No.40,Xueyuan Road > Beijing,China > 100083 > Tel:+8610 62304422EXT225 > Fax:+8610 62303127 > Mailto:liangxg@catt.ac.cn > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 17 22:40:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5efOI012592 for ; Wed, 17 Oct 2001 22:40:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I5efjI012591 for ipng-dist; Wed, 17 Oct 2001 22:40:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I5ebOI012584 for ; Wed, 17 Oct 2001 22:40:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10859 for ; Wed, 17 Oct 2001 22:40:39 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01199 for ; Wed, 17 Oct 2001 23:40:18 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f9I5hWH01957; Thu, 18 Oct 2001 12:43:34 +0700 (ICT) From: Robert Elz To: "Xingang Liang" cc: ipng@sunroof.eng.sun.com Subject: Re: ATM,IP, and the Future!------send again with plain text! In-Reply-To: <003c01c1577d$b078a670$7dce12ac@MCSD.local> References: <003c01c1577d$b078a670$7dce12ac@MCSD.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Oct 2001 12:43:32 +0700 Message-ID: <1955.1003383812@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 18 Oct 2001 10:36:27 +0800 From: "Xingang Liang" Message-ID: <003c01c1577d$b078a670$7dce12ac@MCSD.local> | From the perspective of packet-switching technology,IP and ATM belong | to the same category,that is ,they all use the packet This is the mistake in your reasoning. ATM is more like ethernet, which both do packets, ... (or even SONET, or HDLC, or ...). IP also uses packets (as does UDP, CLNP, ...) they do end to end transmission, using whatever underlying layer happens to be available (including ATM). If you wanted to, you could ask why ATM didn't take over the world, and drive out all the ethernet, and everything else - if it had, then perhaps (and just perhaps) people could run applications directly over ATM. But as long as there are other technologies being used, a protocol that can run over all of them is required, so those who are connected to ATM can communicate with those connected to ethernets, and other link layers. Comparing IP to ATM just makes no sense. 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 Oct 17 23:43:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6hwOI012833 for ; Wed, 17 Oct 2001 23:43:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I6hwHs012832 for ipng-dist; Wed, 17 Oct 2001 23:43:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6hsOI012825 for ; Wed, 17 Oct 2001 23:43:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18438 for ; Wed, 17 Oct 2001 23:43:54 -0700 (PDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26422 for ; Wed, 17 Oct 2001 23:43:52 -0700 (PDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id IAA07694; Thu, 18 Oct 2001 08:43:50 +0200 Received: from dhcp23-95.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA24526 from ; Thu, 18 Oct 2001 08:43:42 +0200 Message-Id: <3BCE7AEC.2BFB730C@hursley.ibm.com> Date: Thu, 18 Oct 2001 08:47:08 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Robert Elz Cc: Xingang Liang , ipng@sunroof.eng.sun.com Subject: Re: ATM,IP, and the Future!------send again with plain text! References: <003c01c1577d$b078a670$7dce12ac@MCSD.local> <1955.1003383812@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We can say it another way - ATM is a point-to-point technology tied to specific types of hardware. IP is an end-to-end technology that is independent of types of hardware. These are simply different roles. ATM will continue to be used, for example, between IP routers inside carrier networks. But it is IP that carries data from computer to computer, running across Ethernet, ATM, modems, and many other hardware layers on the way. That is why IP (especially IPv6) is the future. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org Robert Elz wrote: > > Date: Thu, 18 Oct 2001 10:36:27 +0800 > From: "Xingang Liang" > Message-ID: <003c01c1577d$b078a670$7dce12ac@MCSD.local> > > | From the perspective of packet-switching technology,IP and ATM belong > | to the same category,that is ,they all use the packet > > This is the mistake in your reasoning. ATM is more like ethernet, which > both do packets, ... (or even SONET, or HDLC, or ...). > > IP also uses packets (as does UDP, CLNP, ...) they do end to end transmission, > using whatever underlying layer happens to be available (including ATM). > > If you wanted to, you could ask why ATM didn't take over the world, and > drive out all the ethernet, and everything else - if it had, then perhaps > (and just perhaps) people could run applications directly over ATM. But > as long as there are other technologies being used, a protocol that can > run over all of them is required, so those who are connected to ATM can > communicate with those connected to ethernets, and other link layers. > > Comparing IP to ATM just makes no sense. > > 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 Wed Oct 17 23:59:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6xYOI013099 for ; Wed, 17 Oct 2001 23:59:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I6xYtY013098 for ipng-dist; Wed, 17 Oct 2001 23:59:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6xUOI013091 for ; Wed, 17 Oct 2001 23:59:30 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18069 for ; Wed, 17 Oct 2001 23:59:29 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21954 for ; Wed, 17 Oct 2001 23:59:28 -0700 (PDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.cc.monash.edu.au (PMDF V6.0-24 #39306) with ESMTP id <01K9NJNF1O4EAAV1T6@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 18 Oct 2001 16:59:20 +1000 Received: from localhost (localhost [127.0.0.1]) by thwack.its.monash.edu.au (Postfix) with ESMTP id ABE0D12C00A; Thu, 18 Oct 2001 16:59:19 +1000 (EST) Received: from eng.monash.edu.au (PC00004790.eng.monash.edu.au [130.194.137.189]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 06CDF12C008; Thu, 18 Oct 2001 16:59:19 +1000 (EST) Date: Thu, 18 Oct 2001 17:05:01 +1000 From: Greg Daley Subject: Re: ATM,IP, and the Future!------send again with plain text! To: Brian E Carpenter Cc: Xingang Liang , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3BCE7F1D.2EB3154@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-Virus-Scanned: by AMaViS perl-11 References: <003c01c1577d$b078a670$7dce12ac@MCSD.local> <1955.1003383812@brandenburg.cs.mu.OZ.AU> <3BCE7AEC.2BFB730C@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > We can say it another way - ATM is a point-to-point technology tied to > specific types of hardware. IP is an end-to-end technology that is > independent of types of hardware. These are simply different roles. > ATM will continue to be used, for example, between IP routers inside > carrier networks. But it is IP that carries data from computer to computer, > running across Ethernet, ATM, modems, and many other hardware layers > on the way. That is why IP (especially IPv6) is the future. > I think it is important to remember that ATM is a network too, like IP, and is not just a link technology. Functionally, though, I think that the issue is more one of "connection oriented" to "connectionless". The flexibility of the connectionless packet switched network has allowed existing media to be used at the link layer. In many cases, this has allowed IP's uptake where ATM has not been able to be deployed. Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 00:34:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7YUOI013410 for ; Thu, 18 Oct 2001 00:34:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I7YUUD013409 for ipng-dist; Thu, 18 Oct 2001 00:34:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I7YQOI013402 for ; Thu, 18 Oct 2001 00:34:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24795 for ; Thu, 18 Oct 2001 00:34:30 -0700 (PDT) Received: from newexchange.domain.com ([202.106.106.102]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05500 for ; Thu, 18 Oct 2001 00:34:28 -0700 (PDT) Received: from liangxg ([202.106.106.126]) by newexchange.domain.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Oct 2001 15:25:53 +0800 Message-ID: <00dc01c157a7$56b3e670$7dce12ac@MCSD.local> From: "Xingang Liang" To: Cc: References: <003c01c1577d$b078a670$7dce12ac@MCSD.local> <1955.1003383812@brandenburg.cs.mu.OZ.AU> <3BCE7AEC.2BFB730C@hursley.ibm.com> <3BCE7F1D.2EB3154@eng.monash.edu.au> Subject: Re: ATM,IP, and the Future!------send again with plain text! Date: Thu, 18 Oct 2001 15:34:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 18 Oct 2001 07:25:53.0123 (UTC) FILETIME=[1E83DB30:01C157A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f9I7YROI013403 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ok,Let's look at the problem in another way! Just as Greg said,the connectionlessness of IP takes a lot of advantages than ATM,which is connection-oriented,I agree with this point! But when you compare the flexibility,you should remember whatever network you use,the service that they provide is the most important! Even though ATM is not as flexible as IP, it can provide a guaranteed QoS,while can IP provide the same QoS? Perhaps someone will say there are many solutions to strengthen the IP QoS,such as RSVP,Diffserv,and so on. But implementing these solutions in IP network may be a more complexible thing! When we send a packet outward,we don't know the path it takes.We don't know whether there are routers that don't support RSVP or Diffserv, we don't know whether there are ATM switches on the path,we don't know whether there are other types of networks on the way!How should we provide the QoS using IP?One way is that we strengthen the network to guarantee every node supports for specific QoS solutions!How about guaranteeing ? Just like RSVP:before we send the data packet,we first use the RSVP packet to find the right path!The other way is that since we can't guarantee the middle path,we can do something in end applications to guarantee the QoS,for example,we can configure the packet-sending procedure to be finished until we receive reply from the other end node.But whichever way you take,won't you find them more complexible??? Network is stupid,it just provides transportation like service that is simple!we can't demand too much from it! I don't mean that we should use ATM,not IP.I just want to find out when we design or choose a protocol as a widespread acceptance,what features we should pay attention to and what criterion we should take.ATM,IP and what is the future after IP? Welcome any comments and say sorry to those whom I bothered with my question! Xingang BR ----- Original Message ----- From: "Greg Daley" To: "Brian E Carpenter" Cc: "Xingang Liang" ; Sent: Thursday, October 18, 2001 3:05 PM Subject: Re: ATM,IP, and the Future!------send again with plain text! > Brian E Carpenter wrote: > > > > We can say it another way - ATM is a point-to-point technology tied to > > specific types of hardware. IP is an end-to-end technology that is > > independent of types of hardware. These are simply different roles. > > ATM will continue to be used, for example, between IP routers inside > > carrier networks. But it is IP that carries data from computer to computer, > > running across Ethernet, ATM, modems, and many other hardware layers > > on the way. That is why IP (especially IPv6) is the future. > > > > I think it is important to remember that ATM is a network too, > like IP, and is not just a link technology. > > Functionally, though, I think that the issue is more one of > "connection oriented" to "connectionless". The flexibility of > the connectionless packet switched network has allowed existing > media to be used at the link layer. > > In many cases, this has allowed IP's uptake where ATM has not > been able to be deployed. > > Greg Daley > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 02:34:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I9YQOI014240 for ; Thu, 18 Oct 2001 02:34:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9I9YQfI014239 for ipng-dist; Thu, 18 Oct 2001 02:34:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I9YMOI014232 for ; Thu, 18 Oct 2001 02:34:22 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13021 for ; Thu, 18 Oct 2001 02:34:23 -0700 (PDT) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22308 for ; Thu, 18 Oct 2001 02:34:22 -0700 (PDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA05196; Thu, 18 Oct 2001 11:34:15 +0200 Received: from dhcp23-95.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48296 from ; Thu, 18 Oct 2001 11:34:11 +0200 Message-Id: <3BCEA1F2.217FE5FF@hursley.ibm.com> Date: Thu, 18 Oct 2001 11:33:38 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Xingang Liang , ipng@sunroof.eng.sun.com Subject: Re: ATM,IP, and the Future!------send again with plain text! References: <003c01c1577d$b078a670$7dce12ac@MCSD.local> <1955.1003383812@brandenburg.cs.mu.OZ.AU> <3BCE7AEC.2BFB730C@hursley.ibm.com> <3BCE7F1D.2EB3154@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg, in theory I agree that ATM is a network, but in my experience it is actually used as a point to point technology. The reason for that is the one you give: connectionless just works better. Brian Greg Daley wrote: > > Brian E Carpenter wrote: > > > > We can say it another way - ATM is a point-to-point technology tied to > > specific types of hardware. IP is an end-to-end technology that is > > independent of types of hardware. These are simply different roles. > > ATM will continue to be used, for example, between IP routers inside > > carrier networks. But it is IP that carries data from computer to computer, > > running across Ethernet, ATM, modems, and many other hardware layers > > on the way. That is why IP (especially IPv6) is the future. > > > > I think it is important to remember that ATM is a network too, > like IP, and is not just a link technology. > > Functionally, though, I think that the issue is more one of > "connection oriented" to "connectionless". The flexibility of > the connectionless packet switched network has allowed existing > media to be used at the link layer. > > In many cases, this has allowed IP's uptake where ATM has not > been able to be deployed. > > Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 09:45:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGjkOI017343 for ; Thu, 18 Oct 2001 09:45:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IGjk7g017342 for ipng-dist; Thu, 18 Oct 2001 09:45:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IGjeOI017335 for ; Thu, 18 Oct 2001 09:45:41 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9IGjVq12775; Thu, 18 Oct 2001 18:45:37 +0200 (MET DST) Date: Thu, 18 Oct 2001 18:40:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Extension Header Capability Discovery needed? To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In practise this seems to suggest that the sending node must always be > sure beforehand which extension headers the recipient supports (think e.g. > some MIPv6 feature or new ISPEC feature or whatever). > > In practise this seems to mean either: > 1) never define new extension headers (except in _very_ controlled > scenarios, like new payload protocols) > 2) implement some form of 'extension header capability discovery'. My personal opinions - and see philosophical question at end. In some cases new extensions headers can be viewed the same way as new transport protocols - how does an application know whether the peer implements SCTP or whether it must fall back to TCP? In some cases this is handed by out of band communication. In other cases the desire might be to use extension headers might be more like destination options. The suggestion in mobile-ip is to carry optional information as an extension header since IPsec selectors can operate on the next header but isn't as specified capable of looking at individual options. There is a mechanism which *can* be used to determine if the peer is supporting a new extension header. If it isn't supported is ICMP parameter problem with code = unrecognized Next Header type encountered will be returned. The philosophical question is whether ICMP parameter problem is intended for this purpose, or whether it is a debugging tool i.e. protocols shouldn't respond to this ICMP error by altering their behavior. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 18 11:21:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IILIOI018309 for ; Thu, 18 Oct 2001 11:21:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IILIxG018308 for ipng-dist; Thu, 18 Oct 2001 11:21:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IILGOI018301 for ; Thu, 18 Oct 2001 11:21:17 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f9IIIPB06541 for ipng@sunroof.eng.sun.com; Thu, 18 Oct 2001 11:18:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9I6TLOI012768 for ; Wed, 17 Oct 2001 23:29:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15287 for ; Wed, 17 Oct 2001 23:29:23 -0700 (PDT) Received: from joshua.lnet.lut.fi (joshua.lnet.lut.fi [157.24.114.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27089 for ; Thu, 18 Oct 2001 00:51:58 -0600 (MDT) Received: from joshua.lnet.lut.fi([157.24.114.152]) (2270 bytes) by joshua.lnet.lut.fi via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 18 Oct 2001 09:29:04 +0300 (EET DST) (Smail-3.2.0.114 2001-Aug-6 #3 built DST-Aug-8) Date: Thu, 18 Oct 2001 09:29:01 +0300 (EET DST) From: Ville Nummela X-Sender: vige@joshua.lnet.lut.fi To: Grigory Kljuchnikov cc: ipng@sunroof.eng.sun.com Subject: Re: Receiving multicast messages in UDP sockets question. 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 Tue, 16 Oct 2001, Grigory Kljuchnikov wrote: (sorry for the long quote) > There are four possible cases. > 1. Socket is bound to a port (address left unspecified) and joined > several multicast groups. > 2. Socket is bound to a unicast address and a port and joined several > multicast groups. > 3. Socket is bound to a multicast address and a port and joined several > multicast groups, one group has the address that the socket is bound to. > 4. Socket is bound to a multicast address and a port and joined several > multicast groups, and none of the groups has the address that the socket > is bound to. > > In the first case socket receives all multicast messages, that are sent to > addresses of it's groups (and received on corresponding interfaces) and > the socket's port. Right? I believe the socket receives all packets destined to that port, since the address hasn't been specified. That means the multicast messages AND the unicast messages. > In the second case socket receives unicast packets sent to the socket's > address+port AND all multicast messages sent to addresses of it's groups > (and received on corresponding interfaces) and the socket's port. Right? I believe here we would only receive the messages for the unicast address, as that is the one we have bound. > QUESTION: What messages should the socket receive in the third and > fourth cases? Case 3: The messages for that multicast group we've bound. Case 4: Nothing. I just woke up, so forgive me my mistakes :-) -- | vige@hameenlinna.cx home: +358-50-3265194 | IRC naturae alienum est! Periculosum est! Delendum est! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 11:22:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIM6OI018345 for ; Thu, 18 Oct 2001 11:22:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IIM6jo018344 for ipng-dist; Thu, 18 Oct 2001 11:22:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIM4OI018337 for ; Thu, 18 Oct 2001 11:22:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f9IIJCo06571 for ipng@sunroof.eng.sun.com; Thu, 18 Oct 2001 11:19:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IDuNOI015570 for ; Thu, 18 Oct 2001 06:56:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10651 for ; Thu, 18 Oct 2001 06:56:23 -0700 (PDT) Received: from mailsrv.s3group.com (dns.s3group.com [193.120.90.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13569 for ; Thu, 18 Oct 2001 07:56:03 -0600 (MDT) Received: from headyin.s3group.com (headyin.s3group.com [193.120.89.200]) by mailsrv.s3group.com with ESMTP id f9IDsS729776 for ; Thu, 18 Oct 2001 14:54:29 +0100 (IST) Received: from s3group.com ([193.120.88.200]) by headyin.s3group.com (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GLE00B9QMQNQ0@headyin.s3group.com> for ipng@sunroof.eng.sun.com; Thu, 18 Oct 2001 14:56:47 +0100 (BST) Date: Thu, 18 Oct 2001 14:54:53 +0100 From: Artur Fraczak Subject: Is IPv6 used in commercial networks? To: ipng@sunroof.eng.sun.com Message-id: <3BCEDF2D.C5C10156@s3group.com> MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Sory for a such basic question. I know that IPv6 is implemented in many routers and operating systems. I have heard about experimental networks and 6bone. I know about demand in Asia. But I have not found information about commercial networks. Could you tell me if IPv6 is deployed and used in commercial networks now. Where can I find such information? Artur Fraczak Artur.Fraczak@s3group.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 18 11:53:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIrvOI018678 for ; Thu, 18 Oct 2001 11:53:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9IIrvnv018677 for ipng-dist; Thu, 18 Oct 2001 11:53:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9IIrpOI018667 for ; Thu, 18 Oct 2001 11:53:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12416 for ; Thu, 18 Oct 2001 11:53:52 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11440 for ; Thu, 18 Oct 2001 13:19:08 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Oct 2001 20:53:52 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECABEC@mail.kebne.se> From: Thomas Eklund To: "'Artur Fraczak'" , ipng@sunroof.eng.sun.com Subject: RE: Is IPv6 used in commercial networks? Date: Thu, 18 Oct 2001 20:53:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, Try Scanova in Europe and NTT in Japan. - thomas >-----Original Message----- >From: Artur Fraczak [mailto:artur.fraczak@s3group.com] >Sent: den 18 oktober 2001 15:55 >To: ipng@sunroof.eng.sun.com >Subject: Is IPv6 used in commercial networks? > > >Hi, > >Sory for a such basic question. > >I know that IPv6 is implemented in many routers and operating systems. >I have heard about experimental networks and 6bone. I know about demand >in Asia. >But I have not found information about commercial networks. > >Could you tell me if IPv6 is deployed and used in commercial networks >now. >Where can I find such information? > >Artur Fraczak >Artur.Fraczak@s3group.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 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 16:48:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9INmbOI020765 for ; Thu, 18 Oct 2001 16:48:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9INmbjf020764 for ipng-dist; Thu, 18 Oct 2001 16:48:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9INmYOI020757 for ; Thu, 18 Oct 2001 16:48:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21022 for ; Thu, 18 Oct 2001 16:48:36 -0700 (PDT) Received: from petasus.png.intel.com ([210.187.61.73]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07366 for ; Thu, 18 Oct 2001 16:48:35 -0700 (PDT) Received: from pgsmsxvs01.PNG.INTEL.COM (pgsmsxvs01.png.intel.com [172.30.233.18]) by petasus.png.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id JAA28127 for ; Thu, 18 Oct 2001 09:47:08 -0700 (PDT) Received: from pgsmsx17.PNG.INTEL.COM ([172.30.233.17]) by pgsmsxvs01.PNG.INTEL.COM (NAVGW 2.5.1.6) with SMTP id M2001101907482929181 for ; Fri, 19 Oct 2001 07:48:29 +0800 Received: by pgsmsx17.png.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 07:48:29 +0800 Message-ID: From: "Karuppiah, Ettikan Kandasamy" To: ipng@sunroof.eng.sun.com Subject: routing table exchange/update Date: Fri, 19 Oct 2001 07:48:26 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello, Which rfc refers on route table exchange/update frequency guidelines? Does the frequency is the standard for all routing protocols? Thank you for the information/pointer. -ettikan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 17:00:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9INxxOI020872 for ; Thu, 18 Oct 2001 16:59:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9INxxQQ020871 for ipng-dist; Thu, 18 Oct 2001 16:59:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9INxtOI020864 for ; Thu, 18 Oct 2001 16:59:55 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03385 for ; Thu, 18 Oct 2001 16:59:50 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14731 for ; Thu, 18 Oct 2001 16:59:56 -0700 (PDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #29714) with ESMTP id <01K9OJAK9ZIO8YGW5Y@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 19 Oct 2001 09:59:53 +1000 Received: from localhost (localhost [127.0.0.1]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 63F5D12C008; Fri, 19 Oct 2001 09:59:45 +1000 (EST) Received: from eng.monash.edu.au (PC00004790.eng.monash.edu.au [130.194.137.189]) by blammo.its.monash.edu.au (Postfix) with ESMTP id B611E12C007; Fri, 19 Oct 2001 09:59:44 +1000 (EST) Date: Fri, 19 Oct 2001 10:05:24 +1000 From: Greg Daley Subject: Re: ATM,IP, and the Future!------send again with plain text! To: Brian E Carpenter Cc: Xingang Liang , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3BCF6E44.7CE4DE9D@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-Virus-Scanned: by AMaViS perl-11 References: <003c01c1577d$b078a670$7dce12ac@MCSD.local> <1955.1003383812@brandenburg.cs.mu.OZ.AU> <3BCE7AEC.2BFB730C@hursley.ibm.com> <3BCE7F1D.2EB3154@eng.monash.edu.au> <3BCEA1F2.217FE5FF@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > Greg, in theory I agree that ATM is a network, but in my experience > it is actually used as a point to point technology. The reason for > that is the one you give: connectionless just works better. Indeed, this illustrates the flexibility of IP. ATM will continue to be used by IP as a point to point medium but alternative link layer strategies may in future (now??) marginalise this role. Greg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 18 17:32:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J0WfOI020951 for ; Thu, 18 Oct 2001 17:32:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J0We3E020950 for ipng-dist; Thu, 18 Oct 2001 17:32:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J0WbOI020943 for ; Thu, 18 Oct 2001 17:32:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05115 for ; Thu, 18 Oct 2001 17:32:37 -0700 (PDT) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25799 for ; Thu, 18 Oct 2001 18:58:32 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.0-24 #39306) with ESMTP id <01K9OKFAXT3QA9PQ1D@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 19 Oct 2001 10:31:51 +1000 Received: from localhost (localhost [127.0.0.1]) by splat.its.monash.edu.au (Postfix) with ESMTP id 3FEE412C006; Fri, 19 Oct 2001 10:31:49 +1000 (EST) Received: from eng.monash.edu.au (PC00004790.eng.monash.edu.au [130.194.137.189]) by splat.its.monash.edu.au (Postfix) with ESMTP id 8329E12C007; Fri, 19 Oct 2001 10:31:48 +1000 (EST) Date: Fri, 19 Oct 2001 10:37:28 +1000 From: Greg Daley Subject: Re: ATM,IP, and the Future!------send again with plain text! To: Xingang Liang Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3BCF75C8.8B4D2119@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-Virus-Scanned: by AMaViS perl-11 References: <003c01c1577d$b078a670$7dce12ac@MCSD.local> <1955.1003383812@brandenburg.cs.mu.OZ.AU> <3BCE7AEC.2BFB730C@hursley.ibm.com> <3BCE7F1D.2EB3154@eng.monash.edu.au> <00dc01c157a7$56b3e670$7dce12ac@MCSD.local> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Xingang, I'm not really in a position to comment on IP QoS strategies. All I can state is that my belief is that QoS relies on 2 things: * End to end support of QoS within the network. * Interoperable standards between vendor equipment. You may know that in the past ATM networks suffered because of a lack in either of these areas. I believe though that this was symptomatic of early development of the technology. Similarly, providing IP QoS is something which is still evolving. This does not prevent subsets of the Internet from developing forwarding gurarantees and policies in anticipation of these developments, but I believe the IETF's traffic engineering, diffserv and mpls working groups are working on such issues now. Greg Xingang Liang wrote: > > Ok,Let's look at the problem in another way! > Just as Greg said,the connectionlessness of IP takes a lot of advantages than ATM,which is connection-oriented,I agree with this point! > But when you compare the flexibility,you should remember whatever network you use,the service that they provide is the most important! > Even though ATM is not as flexible as IP, it can provide a guaranteed QoS,while can IP provide the same QoS? > Perhaps someone will say there are many solutions to strengthen the IP QoS,such as RSVP,Diffserv,and so on. > But implementing these solutions in IP network may be a more complexible thing! > When we send a packet outward,we don't know the path it takes.We don't know whether there are routers that don't support RSVP or Diffserv, > we don't know whether there are ATM switches on the path,we don't know whether there are other types of networks on the way!How should we > provide the QoS using IP?One way is that we strengthen the network to guarantee every node supports for specific QoS solutions!How about guaranteeing ? > Just like RSVP:before we send the data packet,we first use the RSVP packet to find the right path!The other way is that since we can't guarantee the middle path,we can do something in end applications to guarantee the QoS,for example,we can configure the packet-sending procedure to be finished until we receive reply from the other end node.But whichever way you take,won't you find them more complexible??? > Network is stupid,it just provides transportation like service that is simple!we can't demand too much from it! > I don't mean that we should use ATM,not IP.I just want to find out when we design or choose a protocol as a widespread acceptance,what features we should pay attention to and what criterion we should take.ATM,IP and what is the future after IP? > Welcome any comments and say sorry to those whom I bothered with my question! > > Xingang > BR > > ----- Original Message ----- > From: "Greg Daley" > To: "Brian E Carpenter" > Cc: "Xingang Liang" ; > Sent: Thursday, October 18, 2001 3:05 PM > Subject: Re: ATM,IP, and the Future!------send again with plain text! > > > Brian E Carpenter wrote: > > > > > > We can say it another way - ATM is a point-to-point technology tied to > > > specific types of hardware. IP is an end-to-end technology that is > > > independent of types of hardware. These are simply different roles. > > > ATM will continue to be used, for example, between IP routers inside > > > carrier networks. But it is IP that carries data from computer to computer, > > > running across Ethernet, ATM, modems, and many other hardware layers > > > on the way. That is why IP (especially IPv6) is the future. > > > > > > > I think it is important to remember that ATM is a network too, > > like IP, and is not just a link technology. > > > > Functionally, though, I think that the issue is more one of > > "connection oriented" to "connectionless". The flexibility of > > the connectionless packet switched network has allowed existing > > media to be used at the link layer. > > > > In many cases, this has allowed IP's uptake where ATM has not > > been able to be deployed. > > > > Greg Daley > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 18 21:44:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J4iOOI022023 for ; Thu, 18 Oct 2001 21:44:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J4iOIl022022 for ipng-dist; Thu, 18 Oct 2001 21:44:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J4iKOI022015 for ; Thu, 18 Oct 2001 21:44:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA29278 for ; Thu, 18 Oct 2001 21:44:23 -0700 (PDT) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA22371 for ; Thu, 18 Oct 2001 23:10:07 -0600 (MDT) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Oct 2001 22:45:00 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 18 Oct 2001 22:44:40 -0600 From: "Bhuvaneshwar hn" To: , Subject: Re: routing table exchange/update Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_EFB516DC.0C6C176E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_EFB516DC.0C6C176E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Which rfc refers on route table exchange/update frequency guidelines? Does the frequency is the standard for all routing protocols? =20 It depends on which protocol you are talking about. No, the frequency of = updates is different for different protocols. Like RIP update frequency is 30sec but it is implementation dependent also = like Cisco routers send RIP updates which varies from 25.5 to 30sec. And = in OSPF the Hello intevals varies from 10 to 60sec and which is implemenat= ion dependent and can be nade configurable. =20 Ref RFC's for RIP and OSPF =20 Reg Bhuvaneshwar >>> "Karuppiah, Ettikan Kandasamy" = 10/19/01 05:18AM >>> hello, Which rfc refers on route table exchange/update frequency guidelines? Does the frequency is the standard for all routing protocols? Thank you for the information/pointer. -ettikan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng=20 FTP archive: ftp://playground.sun.com/pub/ipng=20 Direct all administrative requests to majordomo@sunroof.eng.sun.com=20 -------------------------------------------------------------------- --=_EFB516DC.0C6C176E Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Which rfc refers on route table exchange/update=20 frequency
guidelines? Does the frequency is the standard for all = routing=20 protocols?
 
It depends on which protocol you are talking about. No, the frequency = of=20 updates is different for different protocols.
Like RIP update frequency is 30sec but it is implementation dependent = also=20 like Cisco routers send RIP updates which varies from 25.5 to 30sec. = And=20 in  OSPF the Hello intevals varies from 10 to 60sec and which is=20 implemenation dependent and can be nade configurable.
 
Ref RFC's for RIP and OSPF
 
Reg
Bhuvaneshwar

>>> "Karuppiah, Ettikan Kandasamy" = <ettikan.kandasamy.kar= uppiah@intel.com>=20 10/19/01 05:18AM >>>
hello,

    Which = rfc=20 refers on route table exchange/update frequency
guidelines? Does the=20 frequency is the standard for all routing protocols?

Thank you for = the=20 information/pointer.
-ettikan
---------------------------------------= -----------------------------
IETF=20 IPng Working Group Mailing List
IPng Home=20 Page:           &nbs= p;         =20 http://playground.sun.com/ipng<= BR>FTP=20 archive:           &= nbsp;         =20 ftp://playground.sun.com/pub/ipn= g
Direct=20 all administrative requests to=20 majordomo@sunroof.eng.sun.com
------------------------------------------= --------------------------
--=_EFB516DC.0C6C176E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 00:17:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J7HhOI022427 for ; Fri, 19 Oct 2001 00:17:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9J7HhoK022425 for ipng-dist; Fri, 19 Oct 2001 00:17:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9J7HcOI022411 for ; Fri, 19 Oct 2001 00:17:38 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26367 for ; Fri, 19 Oct 2001 00:17:34 -0700 (PDT) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25491 for ; Fri, 19 Oct 2001 00:17:39 -0700 (PDT) Received: from bahamas.64translator.com (itgw [10.21.254.82]) by mail.64translator.com (8.11.6/8.11.6) with ESMTP id f9J7HbM52906 for ; Fri, 19 Oct 2001 16:17:37 +0900 (JST) Received: from odin.64translator.com (dhcp240.64translator.com [10.21.32.240]) by bahamas.64translator.com (8.11.4/8.11.4) with SMTP id f9J7HbS10664 for ; Fri, 19 Oct 2001 16:17:37 +0900 (JST) Date: Fri, 19 Oct 2001 16:17:37 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: TAHI IPv6 Conformance Test Packages Message-Id: <20011019161737.35338028.yukiyo_akisada@yokogawa.co.jp> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.6.3 (GTK+ 1.2.8; i686-pc-linux-gnu) 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 there, TAHI Project has released the IPv6 Conformance Test Packages at the following web site: http://www.tahi.org/ Changes from the previous release of the IPv6 Conformance Test Packages: The Test Tool (Release-1.3): * Bug fix: * Fix calculate checksum for MIP6 (ID-13) pakcet with HA option * Fix calculate ICV value of AH for MIP6 (ID-13) pakcet with HA option * New targets: * Add AIX remote files * contributed by TIPSTER6 project * Add HPUX remote files * contributed by Anthony Galan * Update telebit-tbc2k remote files * contributed from Ericsson Telebit * Change terminal program from tip to cu The Test Program (Release-1.3): * New tests: * MIP6 tests (ID-13) * SIIT/NAT-PT tests * contributed by Ericsson Telebit * IPsec UDP tests for IPv4 * robustness tests for IPv6 Specification Thanks, --- Yukiyo Akisada @ TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 19 16:59:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JNxxOI001182 for ; Fri, 19 Oct 2001 16:59:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9JNxxXw001181 for ipng-dist; Fri, 19 Oct 2001 16:59:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9JNxtOI001174 for ; Fri, 19 Oct 2001 16:59:55 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26762 for ; Fri, 19 Oct 2001 16:59:51 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04403 for ; Fri, 19 Oct 2001 16:59:57 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JNxtH26276; Fri, 19 Oct 2001 16:59:55 -0700 (PDT) Message-Id: <200110192359.f9JNxtH26276@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3178 on IPv6 Multihoming Support at Site Exit Routers Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 19 Oct 2001 16:59:55 -0700 From: RFC Editor Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3178 Title: IPv6 Multihoming Support at Site Exit Routers Author(s): J. Hagino, H. Snyder Status: Informational Date: October 2001 Mailbox: itojun@iijlab.net, hal@vailsys.com Pages: 12 Characters: 24453 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipngwg-ipv6-2260-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3178.txt The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently-practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates. 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 Sandy Ginoza 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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011019165829.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3178 --OtherAccess Content-Type: Message/External-body; name="rfc3178.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011019165829.RFC@RFC-EDITOR.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 Sun Oct 21 19:05:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M25lOI005364 for ; Sun, 21 Oct 2001 19:05:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M25lMc005363 for ipng-dist; Sun, 21 Oct 2001 19:05:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M25hOI005356 for ; Sun, 21 Oct 2001 19:05:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20574 for ; Sun, 21 Oct 2001 19:05:45 -0700 (PDT) Received: from web9205.mail.yahoo.com (web9205.mail.yahoo.com [216.136.129.38]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA09472 for ; Sun, 21 Oct 2001 20:46:00 -0600 (MDT) Message-ID: <20011022020543.41051.qmail@web9205.mail.yahoo.com> Received: from [161.139.68.13] by web9205.mail.yahoo.com via HTTP; Sun, 21 Oct 2001 19:05:43 PDT Date: Sun, 21 Oct 2001 19:05:43 -0700 (PDT) From: pat nanthan Subject: ipsec To: 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 I am doing research on ARP protocol. is there any way that i could solve ARP poisoning in ethernet switched network using IPSEC? i need help on this.... __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.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 Oct 21 23:04:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M64dOI005853 for ; Sun, 21 Oct 2001 23:04:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9M64cde005852 for ipng-dist; Sun, 21 Oct 2001 23:04:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9M64UOI005835; Sun, 21 Oct 2001 23:04:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25845; Sun, 21 Oct 2001 23:04:23 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16545; Sun, 21 Oct 2001 23:04:27 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Sun, 21 Oct 2001 23:04:18 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4BD429DFB60348E28F2AD537BA896FAE for plus 6 more; Sun, 21 Oct 2001 23:04:17 -0700 From: "Tony Hain" To: Cc: , , , , , Subject: Update to Provider Independent addressing format drafts Date: Sun, 21 Oct 2001 23:04:00 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SLUIDL: EE2F0709-FFDC4238-9E8CAA2A-31D3EF30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The updates to the provider independent address format & usage drafts are available at: http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-fmt-01.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt The usage document has been significantly reworked to address both direct comments, as well as distillation of key issues from various mail threads on nanog & multi6 lists. At this point comments should be directed to the multi6 list. 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 Oct 22 20:18:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N3IjOI009785 for ; Mon, 22 Oct 2001 20:18:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9N3Ij4W009784 for ipng-dist; Mon, 22 Oct 2001 20:18:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9N3IZOI009769; Mon, 22 Oct 2001 20:18:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00538; Mon, 22 Oct 2001 20:18:38 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07352; Mon, 22 Oct 2001 20:18:37 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id f9N3K3P00698; Mon, 22 Oct 2001 23:20:08 -0400 (EDT) Message-Id: <200110230320.f9N3K3P00698@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Tony Hain" , multi6@ops.ietf.org, nanog@merit.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, tech@ipv6forum.com, ipv6-directorate@sunroof.eng.sun.com Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts In-reply-to: Your message of "Mon, 22 Oct 2001 16:58:40 PDT." <2B81403386729140A3A899A8B39B046403AEA5@server2000.arneill-py.sacramento.ca.us> Date: Mon, 22 Oct 2001 23:20:03 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Large corporations that have (with or without a valid > reason) a tendency to geographically relocate would have to re-number. if you're doing a massive relocation in physical space, the renumbering of your IP network doesn't seem like a huge additional burden. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 23 05:02:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NC2POI010958 for ; Tue, 23 Oct 2001 05:02:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NC2PVb010957 for ipng-dist; Tue, 23 Oct 2001 05:02:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NC2FOI010942; Tue, 23 Oct 2001 05:02:15 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9NC2Dq27137; Tue, 23 Oct 2001 14:02:13 +0200 (MET DST) Date: Tue, 23 Oct 2001 13:56:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts To: Keith Moore Cc: Michel Py , Tony Hain , multi6@ops.ietf.org, nanog@merit.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, tech@ipv6forum.com, ipv6-directorate@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200110230320.f9N3K3P00698@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Large corporations that have (with or without a valid > > reason) a tendency to geographically relocate would have to re-number. > > if you're doing a massive relocation in physical space, the renumbering > of your IP network doesn't seem like a huge additional burden. The physical relocation might me relatively minor. For instance, large corporations might choose to define one place (e.g. one building on one of many campuses) as the coordinates as the single place that defines the IP address prefix for the whole company yet that building might house much less than 1% of the company's IP devices and people. This means that giving up the lease on that single building will cause all IP devices to renumber yet the costs due to the physical relocation are small. 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 Oct 23 05:31:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NCVCOI011085 for ; Tue, 23 Oct 2001 05:31:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NCVBhf011084 for ipng-dist; Tue, 23 Oct 2001 05:31:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NCV3OI011069; Tue, 23 Oct 2001 05:31:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25780; Tue, 23 Oct 2001 05:31:04 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22513; Tue, 23 Oct 2001 06:34:11 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id f9NCX3P18810; Tue, 23 Oct 2001 08:33:03 -0400 (EDT) Message-Id: <200110231233.f9NCX3P18810@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Michel Py , Tony Hain , multi6@ops.ietf.org, nanog@merit.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, tech@ipv6forum.com, ipv6-directorate@sunroof.eng.sun.com Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts In-reply-to: Your message of "Tue, 23 Oct 2001 13:56:39 +0200." Date: Tue, 23 Oct 2001 08:33:03 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The physical relocation might me relatively minor. > For instance, large corporations might choose to define one place > (e.g. one building on one of many campuses) as the coordinates as the > single place that defines the IP address prefix for the whole company > yet that building might house much less than 1% of the company's IP devices > and people. > > This means that giving up the lease on that single building will cause all > IP devices to renumber yet the costs due to the physical relocation are > small. seems like a stretch. as long as the company retained some network presence in that area it should be able to keep that prefix. though if the company decided to completely shut down its operations at that area (not an entirely unusual occurance) it could indeed require the entire company to reunumber. having your entire company under a single prefix might turn out to be bad planning in an IPv6 world. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 23 07:31:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NEVOOI011435 for ; Tue, 23 Oct 2001 07:31:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NEVNSv011434 for ipng-dist; Tue, 23 Oct 2001 07:31:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NEVGOI011427; Tue, 23 Oct 2001 07:31:16 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09730; Tue, 23 Oct 2001 07:31:17 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02782; Tue, 23 Oct 2001 07:31:16 -0700 (PDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GLN0064CXO3LN@smtp.fnal.gov>; Tue, 23 Oct 2001 09:31:15 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f9NEVEs06712; Tue, 23 Oct 2001 09:31:14 -0500 (CDT) Date: Tue, 23 Oct 2001 09:31:13 -0500 From: Matt Crawford Subject: Re: (ngtrans) Update to Provider Independent addressing format drafts In-reply-to: "23 Oct 2001 08:33:03 EDT." <200110231233.f9NCX3P18810@astro.cs.utk.edu> To: Keith Moore Cc: multi6@ops.ietf.org, nanog@merit.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, tech@ipv6forum.com, ipv6-directorate@sunroof.eng.sun.com Message-id: <200110231431.f9NEVEs06712@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Do so many lists really need to be cc'd?) > > This means that giving up the lease on that single building will cause all > > IP devices to renumber yet the costs due to the physical relocation are > > small. > > seems like a stretch. as long as the company retained some network presence > in that area it should be able to keep that prefix. It seems to me that a Wall Street prefix would not be announced by (or accepted by peers of) an upstream provider in Chicago, or perhaps even Connecticut. So traffic using the Wall Street PI prefix might actually have to be routed through some location in New York. This might be impractical. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 23 10:34:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NHY2OI012342 for ; Tue, 23 Oct 2001 10:34:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NHY2VG012341 for ipng-dist; Tue, 23 Oct 2001 10:34:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NHXxOI012334 for ; Tue, 23 Oct 2001 10:33:59 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28034 for ; Tue, 23 Oct 2001 10:34:02 -0700 (PDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03824 for ; Tue, 23 Oct 2001 10:34:02 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail3.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9NHSQs21871 for ; Tue, 23 Oct 2001 10:28:26 -0700 (PDT) Received: from oracle.com (iesu106.ie.oracle.com [143.47.72.149]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9NHXxU06321 for ; Tue, 23 Oct 2001 11:34:00 -0600 (MDT) Message-ID: <3BD5AAF9.914A465A@oracle.com> Date: Tue, 23 Oct 2001 18:38:01 +0100 From: "Enda O'Connor" Organization: Oracle X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: Connect IPv4 to IPv6 Content-Type: multipart/mixed; boundary="------------2DEA67410E18A9081ED42DD5" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------2DEA67410E18A9081ED42DD5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit this is probably a foolish question but I'm looking for info. I'm doing a project on connecting an ipv4 network to ipv6 network, and am curious as to whats involved. -- Enda O'Connor Oracle Corporation Global Product Engineering ext 33318 --------------2DEA67410E18A9081ED42DD5 Content-Type: text/x-vcard; charset=us-ascii; name="enda.oconnor.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Enda O'Connor Content-Disposition: attachment; filename="enda.oconnor.vcf" begin:vcard n:;Enda O'Connor x-mozilla-html:FALSE org:Oracle EDTC ;GPE adr:;;;;;; version:2.1 email;internet:enda.oconnor@oracle.com title:Software engineer x-mozilla-cpt:;-24280 fn:EndaO'Connor end:vcard --------------2DEA67410E18A9081ED42DD5-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 23 12:55:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NJtSOI012697 for ; Tue, 23 Oct 2001 12:55:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NJtSWo012696 for ipng-dist; Tue, 23 Oct 2001 12:55:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NJtPOI012689 for ; Tue, 23 Oct 2001 12:55:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05097 for ; Tue, 23 Oct 2001 12:55:28 -0700 (PDT) Received: from padcommail.padcom (padcom-nt.padcomusa.com [209.173.5.145] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27935 for ; Tue, 23 Oct 2001 12:55:27 -0700 (PDT) Received: by PADCOMMAIL with Internet Mail Service (5.5.2653.19) id <4SB6WW4Z>; Tue, 23 Oct 2001 15:47:33 -0400 Message-ID: From: Rich Cosner To: "Sun. Com (E-mail)" Subject: Things Date: Tue, 23 Oct 2001 15:47:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15BFB.8D799940" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15BFB.8D799940 Content-Type: text/plain; charset="iso-8859-1" How are things going there tonight? Are you having a good day? Richard A. Cosner Help Desk/Network Administration A+, Network+ Padcom, Inc. 610-882-9940 ext. 3045 ------_=_NextPart_001_01C15BFB.8D799940 Content-Type: text/html; charset="iso-8859-1" Things

How are things going there tonight? Are you having a good day?

Richard A. Cosner
Help Desk/Network Administration
A+, Network+
Padcom, Inc.
610-882-9940 ext. 3045



------_=_NextPart_001_01C15BFB.8D799940-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 23 13:02:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NK24OI012747 for ; Tue, 23 Oct 2001 13:02:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NK2405012746 for ipng-dist; Tue, 23 Oct 2001 13:02:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NK21OI012739 for ; Tue, 23 Oct 2001 13:02:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06511 for ; Tue, 23 Oct 2001 13:02:04 -0700 (PDT) Received: from padcommail.padcom (padcom-nt.padcomusa.com [209.173.5.145] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28463 for ; Tue, 23 Oct 2001 14:02:22 -0600 (MDT) Received: by PADCOMMAIL with Internet Mail Service (5.5.2653.19) id <4SB6WWVA>; Tue, 23 Oct 2001 15:54:03 -0400 Message-ID: From: Rich Cosner To: "Sun. Com (E-mail)" Subject: RE: Things Date: Tue, 23 Oct 2001 15:53:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15BFC.72FB1BB0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15BFC.72FB1BB0 Content-Type: text/plain; charset="iso-8859-1" Sorry about that, disregard please... -----Original Message----- From: Rich Cosner [mailto:rcosner@padcomusa.com] Sent: Tuesday, October 23, 2001 3:48 PM To: Sun. Com (E-mail) Subject: Things How are things going there tonight? Are you having a good day? Richard A. Cosner Help Desk/Network Administration A+, Network+ Padcom, Inc. 610-882-9940 ext. 3045 ------_=_NextPart_001_01C15BFC.72FB1BB0 Content-Type: text/html; charset="iso-8859-1" Things
Sorry about that, disregard please...
-----Original Message-----
From: Rich Cosner [mailto:rcosner@padcomusa.com]
Sent: Tuesday, October 23, 2001 3:48 PM
To: Sun. Com (E-mail)
Subject: Things

How are things going there tonight? Are you having a good day?

Richard A. Cosner
Help Desk/Network Administration
A+, Network+
Padcom, Inc.
610-882-9940 ext. 3045



------_=_NextPart_001_01C15BFC.72FB1BB0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 23 13:23:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NKNdOI012887 for ; Tue, 23 Oct 2001 13:23:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NKNdqO012886 for ipng-dist; Tue, 23 Oct 2001 13:23:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NKNaOI012879 for ; Tue, 23 Oct 2001 13:23:36 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11523 for ; Tue, 23 Oct 2001 13:23:39 -0700 (PDT) Received: from hetnet.nl (net014s.hetnet.nl [194.151.104.154]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19106 for ; Tue, 23 Oct 2001 13:23:38 -0700 (PDT) Received: from E.V.A ([213.73.155.66]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 23 Oct 2001 22:21:43 +0200 Date: Tue, 23 Oct 2001 22:35:47 +0200 From: Hard_Slam X-Mailer: The Bat! (v1.53d) Reply-To: Hard_Slam X-Priority: 3 (Normal) Message-ID: <73206433909.20011023223547@hetnet.nl> To: ipng@sunroof.eng.sun.com Subject: Security Features against DDoS attacks. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I was wondering how IPng is dealing with malicious attacks like DDoS, also i would like to know about other security enhangements in IPng. -- Best regards, Hard_Slam mailto:Hard_Slam@hetnet.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 Tue Oct 23 15:51:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NMpCOI013324 for ; Tue, 23 Oct 2001 15:51:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9NMpCg6013323 for ipng-dist; Tue, 23 Oct 2001 15:51:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NMp8OI013316 for ; Tue, 23 Oct 2001 15:51:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16903 for ; Tue, 23 Oct 2001 15:51:11 -0700 (PDT) Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07750 for ; Tue, 23 Oct 2001 15:51:10 -0700 (PDT) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id C36C43216; Wed, 24 Oct 2001 00:51:06 +0200 (CEST) From: "Jeroen Massar" To: "'Enda O'Connor'" Cc: Subject: RE: Connect IPv4 to IPv6 Date: Fri, 24 Aug 2001 00:50:43 +0200 Organization: Unfix Message-ID: <002101c12c26$0a690a40$420d640a@HELL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <3BD5AAF9.914A465A@oracle.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Enda O'Connor wrote: > this is probably a foolish question but I'm looking for info. > I'm doing a project on connecting an ipv4 network to ipv6 > network, and am curious as to whats involved. http://hs247.com and read up on all the docs you can find linked there... You will most probably be interrested in 'nat-pt' 'asyproxy/asybo' '6tunnel' 'relay6' Hope that gets you going :) Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 13:13:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OKDS6C017844 for ; Wed, 24 Oct 2001 13:13:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OKDSme017843 for ipng-dist; Wed, 24 Oct 2001 13:13:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OKDN6C017836 for ; Wed, 24 Oct 2001 13:13:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12174 for ; Wed, 24 Oct 2001 13:13:21 -0700 (PDT) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29045 for ; Wed, 24 Oct 2001 14:13:20 -0600 (MDT) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.10.2/8.10.2) with ESMTP id f9OKDJR27013 for ; Wed, 24 Oct 2001 10:13:19 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <4DA1K431>; Wed, 24 Oct 2001 10:18:50 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540501E54C4F@apollo.adtech-inc.com> From: "Doi, Sheryl" To: "'ipng@sunroof.eng.sun.com.'" Subject: Date: Wed, 24 Oct 2001 10:18:42 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, Im new to ipv6 and have a couple of questions: 1> What is a psuedo header (format and where is it used) 2> Is there a TCL implementation of ipv6 that is open source? thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 24 14:02:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OL2j6C018002 for ; Wed, 24 Oct 2001 14:02:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9OL2if3018001 for ipng-dist; Wed, 24 Oct 2001 14:02:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9OL2h6C017994 for ; Wed, 24 Oct 2001 14:02:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f9OKxll18479 for ipng@sunroof.eng.sun.com; Wed, 24 Oct 2001 13:59:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9NNtIOI013600 for ; Tue, 23 Oct 2001 16:55:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02097 for ; Tue, 23 Oct 2001 16:55:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06370 for ; Tue, 23 Oct 2001 16:55:21 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA18087; Tue, 23 Oct 2001 16:55:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9NNtKu10499; Tue, 23 Oct 2001 16:55:20 -0700 X-mProtect: Tue, 23 Oct 2001 16:55:20 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (192.103.16.65, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdZGmz9b; Tue, 23 Oct 2001 16:55:18 PDT Message-Id: <4.3.2.7.2.20011023165248.01e4a550@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Oct 2001 16:54:06 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: VRRP for IPv6 Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, I have written a VRRP for IPv6 draft based on RFC2338 (VRRP for IPv4) and have requested a session for the VRRP w.g. at the Salt Lake City IETF to discuss it. Online discussion should occur on the VRRP mailing list: vrrp@drcoffsite.com To subscribe to the VRRP list, send an email to: listserv@drcoffsite.com with subscribe vrrp in the body of the message. More info on the VRRP for IPv6 draft is below. Bob >Date: Tue, 23 Oct 2001 16:31:19 -0700 >To: vrrp@drcoffsite.com From: Bob Hinden >Subject: VRRP for IPv6 draft and VRRP Session at IETF 52 in Salt Lake > City > >Based on some discussion on the VRRP and IPng mailing lists, I have >written a VRRP for IPv6 draft. The protocol operates in the same manner >as VRRP (for IPv4) as defined in RFC2338. The same virtual router >master/backup(s) model, state machine works the same way, etc. The >changes to the specification include: > > o Increment VRRP version to 3. > o Change packet format to support an 128-bit IPv6 address. > o Change to only support one router address (instead of multiple > addresses). This included removing address count field from > header. > o Rewrote text to specify IPv6 Neighbor Discovery mechanisms > instead of ARP. > o Changed state machine actions to use Neighbor Discovery > mechanisms. This includes sending unsolicited Neighbor > Advertisements, Receiving Neighbor Solicitations, joining the > appropriate solicited node multicast group, sending Router > Advertisements, and receiving Router Solicitations. > >Plus a general rewrite of the introduction and some of the other overview >sections. > >I took the liberty of making it a VRRP w.g. draft as there was some >discussion on the vrrp list and it is a work item in the w.g. charter. > >Until the new Internet Draft is out, the draft can be found at: > > http://playground.sun.com/pub/hinden/vrrp/draft-ietf-vrrp-ipv6-spec-00.txt > >I will request a one hour slot at the Salt Lake City IETF meeting in >December for the VRRP working group to meet. The main agenda topic will >be to discuss this draft. Please let me know if you have any other topics >you would like discussed. > >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 Oct 25 17:09:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q09L6C023123 for ; Thu, 25 Oct 2001 17:09:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9Q09LX6023122 for ipng-dist; Thu, 25 Oct 2001 17:09:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9Q09H6C023115 for ; Thu, 25 Oct 2001 17:09:17 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21552 for ; Thu, 25 Oct 2001 17:09:20 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29738 for ; Thu, 25 Oct 2001 17:09:19 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9Q09HH16854; Thu, 25 Oct 2001 17:09:17 -0700 (PDT) Message-Id: <200110260009.f9Q09HH16854@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3146 on IPv6 Packets over IEEE 1394 Networks Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 25 Oct 2001 17:09:17 -0700 From: RFC Editor Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3146 Title: Transmission of IPv6 Packets over IEEE 1394 Networks Author(s): K. Fujisawa, A. Onoe Status: Standards Track Date: October 2001 Mailbox: fujisawa@sm.sony.co.jp, onoe@sm.sony.co.jp Pages: 8 Characters: 16513 SeeAlso/Updates/Obsoletes: None I-D Tag: draft-ietf-ipngwg-1394-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3146.txt This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. This document is the 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 Sandy Ginoza 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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011025170750.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3146 --OtherAccess Content-Type: Message/External-body; name="rfc3146.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011025170750.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 26 07:38:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QEcw6C024780 for ; Fri, 26 Oct 2001 07:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QEcwGK024779 for ipng-dist; Fri, 26 Oct 2001 07:38:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QEcr6C024772 for ; Fri, 26 Oct 2001 07:38:53 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03294 for ; Fri, 26 Oct 2001 07:38:55 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19014 for ; Fri, 26 Oct 2001 07:38:55 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA01538 for ; Fri, 26 Oct 2001 07:38:54 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9QEcsm00508 for ; Fri, 26 Oct 2001 07:38:54 -0700 X-mProtect: Fri, 26 Oct 2001 07:38:54 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.44.21, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdWBRbzh; Fri, 26 Oct 2001 07:38:51 PDT Message-Id: <4.3.2.7.2.20011026073733.024fbd08@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Oct 2001 07:38:17 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: I-D ACTION:draft-ietf-vrrp-ipv6-spec-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol for IPv6 Author(s) : B. Hinden Filename : draft-ietf-vrrp-ipv6-spec-00.txt Pages : 31 Date : 24-Oct-01 This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv6. It is version three (3) of the protocol. It is based on the original version of VRRP (version 2) for IPv4 that is defined in RFC2338. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-vrrp-ipv6-spec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vrrp-ipv6-spec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20011024104225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vrrp-ipv6-spec-00.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 Fri Oct 26 07:55:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QEt86C024837 for ; Fri, 26 Oct 2001 07:55:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QEt7vJ024836 for ipng-dist; Fri, 26 Oct 2001 07:55:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QEt46C024829 for ; Fri, 26 Oct 2001 07:55:04 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13932 for ; Fri, 26 Oct 2001 07:54:55 -0700 (PDT) From: Martin.Stiemerling@ccrle.nec.de Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25687 for ; Fri, 26 Oct 2001 07:55:04 -0700 (PDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f9QEupf91887; Fri, 26 Oct 2001 16:56:51 +0200 (CEST) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id A1F14C259; Fri, 26 Oct 2001 16:54:51 +0200 (CEST) To: hinden@iprg.nokia.com Subject: Re: I-D ACTION:draft-ietf-vrrp-ipv6-spec-00.txt Message-ID: <1004108091.3bd9793b9340a@citadel.mobility.ccrle.nec.de> Date: Fri, 26 Oct 2001 16:54:51 +0200 (CEST) Cc: ipng@sunroof.eng.sun.com References: <4.3.2.7.2.20011026073733.024fbd08@mailhost.iprg.nokia.com> In-Reply-To: <4.3.2.7.2.20011026073733.024fbd08@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.180 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I just have taken a short look into this draft, and in the section 13 "IANA Cosinderations" there is the proposed VRRP link-local address. The proposed ff02::1:2 is already occupied by DHCPv6 "All-dhcp-agents"-address! (see: http://www.iana.org/assignments/ipv6-multicast-addresses ) Best Regards Martin #Zitiere "by way of Bob Hinden " : > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Virtual Router Redundancy > > Protocol Working Group of the IETF. > > Title : Virtual Router Redundancy Protocol for IPv6 > Author(s) : B. Hinden > Filename : draft-ietf-vrrp-ipv6-spec-00.txt > Pages : 31 > Date : 24-Oct-01 > > This memo defines the Virtual Router Redundancy Protocol (VRRP) for > IPv6. It is version three (3) of the protocol. It is based on the > original version of VRRP (version 2) for IPv4 that is defined in > RFC2338. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > 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-vrrp-ipv6-spec-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-vrrp-ipv6-spec-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <20011024104225.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-vrrp-ipv6-spec-00.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 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 26 09:43:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGh56C025483 for ; Fri, 26 Oct 2001 09:43:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QGh5Z2025482 for ipng-dist; Fri, 26 Oct 2001 09:43:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGh16C025475 for ; Fri, 26 Oct 2001 09:43:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23377 for ; Fri, 26 Oct 2001 09:43:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24461 for ; Fri, 26 Oct 2001 10:56:43 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA09166; Fri, 26 Oct 2001 09:43:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9QGgxr18562; Fri, 26 Oct 2001 09:42:59 -0700 X-mProtect: Fri, 26 Oct 2001 09:42:59 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (192.103.16.65, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdXQYm4Z; Fri, 26 Oct 2001 09:42:56 PDT Message-Id: <4.3.2.7.2.20011026094013.024e9070@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Oct 2001 09:42:22 -0700 To: Martin.Stiemerling@ccrle.nec.de From: Bob Hinden Subject: Re: I-D ACTION:draft-ietf-vrrp-ipv6-spec-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <1004108091.3bd9793b9340a@citadel.mobility.ccrle.nec.de> References: <4.3.2.7.2.20011026073733.024fbd08@mailhost.iprg.nokia.com> <4.3.2.7.2.20011026073733.024fbd08@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Martin, My mistake. It should have been: ff02::12 I will fix in next version of the draft. Thanks, Bob At 07:54 AM 10/26/2001, Martin.Stiemerling@ccrle.nec.de wrote: >Hello, > >I just have taken a short look into this draft, and in the section 13 "IANA >Cosinderations" there is the proposed VRRP link-local address. >The proposed ff02::1:2 is already occupied by DHCPv6 >"All-dhcp-agents"-address! >(see: http://www.iana.org/assignments/ipv6-multicast-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 Fri Oct 26 09:49:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGnQ6C025598 for ; Fri, 26 Oct 2001 09:49:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9QGnPAD025597 for ipng-dist; Fri, 26 Oct 2001 09:49:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QGnM6C025590 for ; Fri, 26 Oct 2001 09:49:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29882 for ; Fri, 26 Oct 2001 09:49:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28208 for ; Fri, 26 Oct 2001 11:03:16 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9QGnJe01344; Fri, 26 Oct 2001 19:49:19 +0300 Date: Fri, 26 Oct 2001 19:49:19 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: , Subject: Re: I-D ACTION:draft-ietf-vrrp-ipv6-spec-00.txt In-Reply-To: <4.3.2.7.2.20011026073733.024fbd08@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hopefully vrrp@ does not require subscription.. On Fri, 26 Oct 2001, by way of Bob Hinden wrote: > Title : Virtual Router Redundancy Protocol for IPv6 > Author(s) : B. Hinden > Filename : draft-ietf-vrrp-ipv6-spec-00.txt > Pages : 31 > Date : 24-Oct-01 > > This memo defines the Virtual Router Redundancy Protocol (VRRP) for > IPv6. It is version three (3) of the protocol. It is based on the > original version of VRRP (version 2) for IPv4 that is defined in > RFC2338. The draft specifies VRRP version 3. VRRP version 3 no longer supports IPv4. If VRRPv2 is to revised for IPv4, what would be their version number? IMO, VRRPv3 should perhaps support both IPv4 and IPv6; e.g. a one-bit flag from the reserved field (1 for IPv6, 0 for IPv4), to select the header format and used address family. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 26 18:04:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R14P6C026774 for ; Fri, 26 Oct 2001 18:04:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9R14P5R026773 for ipng-dist; Fri, 26 Oct 2001 18:04:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9R14N6C026766 for ; Fri, 26 Oct 2001 18:04:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f9R11RW24012 for ipng@sunroof.eng.sun.com; Fri, 26 Oct 2001 18:01:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9QHbW6C025861 for ; Fri, 26 Oct 2001 10:37:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19791 for ; Fri, 26 Oct 2001 10:37:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26628 for ; Fri, 26 Oct 2001 10:37:35 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA13925; Fri, 26 Oct 2001 10:37:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9QHbWa13473; Fri, 26 Oct 2001 10:37:32 -0700 X-mProtect: Fri, 26 Oct 2001 10:37:32 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (192.103.16.65, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdoEdyld; Fri, 26 Oct 2001 10:37:29 PDT Message-Id: <4.3.2.7.2.20011026100818.024e9070@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Oct 2001 10:36:07 -0700 To: Pekka Savola From: Bob Hinden Subject: Re: I-D ACTION:draft-ietf-vrrp-ipv6-spec-00.txt Cc: , In-Reply-To: References: <4.3.2.7.2.20011026073733.024fbd08@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, >Hopefully vrrp@ does not require subscription.. Yes, it does. There was too much spam..... Please subscribe and continue the discussion there. >On Fri, 26 Oct 2001, by way of Bob Hinden wrote: > > Title : Virtual Router Redundancy Protocol for IPv6 > > Author(s) : B. Hinden > > Filename : draft-ietf-vrrp-ipv6-spec-00.txt > > Pages : 31 > > Date : 24-Oct-01 > > > > This memo defines the Virtual Router Redundancy Protocol (VRRP) for > > IPv6. It is version three (3) of the protocol. It is based on the > > original version of VRRP (version 2) for IPv4 that is defined in > > RFC2338. > >The draft specifies VRRP version 3. > >VRRP version 3 no longer supports IPv4. > >If VRRPv2 is to revised for IPv4, what would be their version number? > >IMO, VRRPv3 should perhaps support both IPv4 and IPv6; e.g. a one-bit flag >from the reserved field (1 for IPv6, 0 for IPv4), to select the header >format and used address family. This was discussed in the VRRP w.g. some time ago and there was a decision made to not have a dual protocol version of VRRP. Also, after rewriting it to use IPv6, I think having one document that describes both the IPv4 and IPv6 address resolution mechanism (i.e., ARP and ND) everywhere in the document would make the document very complicated and hard to understand. I think it is much simpler to keep the two separate. If VRRPv2 (for IPv4) needs to be revised in some incomparable way either a new message type could be used, or perhaps VRRPv4. The version and message types are four bits each. Not too likely we will run out soon. Also, VRRPv2 has been stable for a long while. Again please continue the discussion on the VRRP mailing list. Subscription info follows. Bob ------- To subscribe to the VRRP list, send an email to: listserv@drcoffsite.com with subscribe vrrp in the body of the message. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 28 21:07:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T573QO001747 for ; Sun, 28 Oct 2001 21:07:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9T5721t001746 for ipng-dist; Sun, 28 Oct 2001 21:07:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9T56wQO001739 for ; Sun, 28 Oct 2001 21:06:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07465 for ; Sun, 28 Oct 2001 21:07:01 -0800 (PST) Received: from starfruit.itojun.org (kame202.kame.net [203.178.141.202]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01526 for ; Sun, 28 Oct 2001 21:07:00 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 2EC957BA for ; Mon, 29 Oct 2001 14:06:50 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: 2292bis-02: IPV6_CHECKSUM on ICMPv6 socket 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 Hagino Date: Mon, 29 Oct 2001 14:06:50 +0900 Message-Id: <20011029050650.2EC957BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk what should happen with set/getsockopt(IPV6_CHECKSUM) on ICMPv6 socket? 2292bis-02 says as follows, > An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail. therefore, setsockopt(IPV6_CHECKSUM) on ICMPv6 socket will fail, but with what error code? (EINVAL? EOPNOTSUPP?) what should happen for getsockopt(IPV6_ICMPV6) on ICMPv6 socket? - always return 2? - raise error (error code?) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 02:43:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TAhuQO002181 for ; Mon, 29 Oct 2001 02:43:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TAhuuv002180 for ipng-dist; Mon, 29 Oct 2001 02:43:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TAhqQO002173 for ; Mon, 29 Oct 2001 02:43:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23159 for ; Mon, 29 Oct 2001 02:43:42 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19294 for ; Mon, 29 Oct 2001 04:06:59 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A6DE44B22 for ; Mon, 29 Oct 2001 19:43:50 +0900 (JST) To: ipng@sunroof.eng.sun.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: 2292bis-02: zero-length setsockopt From: itojun@iijlab.net Date: Mon, 29 Oct 2001 19:43:50 +0900 Message-ID: <25802.1004352230@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk during RFC2292 to 2292bis transition, it seems that the following text has been added to multiple places: (how to reset values set by IPV6_HOPLIMIT setsockopt) > In order to clear a sticky IPV6_HOPLIMIT option the application can > specify -1 as the value. Alternatively, the application can specify <-- > an IPV6_HOPLIMIT socket option with a zero length. <-- i don't think it is a usual practice for setsockopt. they normally take a parameter with fixed length. i'm wondering where did this behavior come from, and how popular is it for UNIX setsockopt to behave like this. any hints? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 05:42:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TDguQO002441 for ; Mon, 29 Oct 2001 05:42:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9TDguTV002440 for ipng-dist; Mon, 29 Oct 2001 05:42:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9TDgpQO002433 for ; Mon, 29 Oct 2001 05:42:51 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9TDgnq29758; Mon, 29 Oct 2001 14:42:49 +0100 (MET) Date: Mon, 29 Oct 2001 14:42:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 2292bis-02: zero-length setsockopt To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <25802.1004352230@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > during RFC2292 to 2292bis transition, it seems that the following text > has been added to multiple places: > > (how to reset values set by IPV6_HOPLIMIT setsockopt) > > In order to clear a sticky IPV6_HOPLIMIT option the application can > > specify -1 as the value. Alternatively, the application can specify <-- > > an IPV6_HOPLIMIT socket option with a zero length. <-- > > i don't think it is a usual practice for setsockopt. they normally > take a parameter with fixed length. > i'm wondering where did this behavior come from, and how popular is it > for UNIX setsockopt to behave like this. any hints? I guess I stuck that text in there based on some goal of consistency with the other IPV6_ options in the spec. Clearly(?) for IPv6_DSTOPTHDR it makes sense to be able to clear the sticky option by setting it to zero length. (I think this is consistent with setting IP_OPTIONS to zero length.) So what about IPV6_HOPLIMIT that is a fixed length quantity? Is it more important to be consistent with the other IPv6 options (and allow zero length as a way to clear it) or is it more important to make the option value always have a fixed length (meaning that -1 is the only way to set if to "default"). I don't have a strong opinion either way. 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 Mon Oct 29 19:00:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U30BQO004356 for ; Mon, 29 Oct 2001 19:00:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9U30A64004355 for ipng-dist; Mon, 29 Oct 2001 19:00:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U307QO004348 for ; Mon, 29 Oct 2001 19:00:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25208 for ; Mon, 29 Oct 2001 18:59:56 -0800 (PST) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21657 for ; Mon, 29 Oct 2001 18:59:56 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA35534 for ; Mon, 29 Oct 2001 20:57:22 -0600 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.226.185]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id f9U2xt577832 for ; Mon, 29 Oct 2001 21:59:55 -0500 Importance: Normal Sensitivity: Subject: ICMPv6 rate limiting factor To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Mon, 29 Oct 2001 21:59:06 -0500 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 10/29/2001 09:59:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 2463 states that it is a MUST to limit the rate of ICMPv6 error messages that are sent. Traceroute is a utility that relies on ICMP error messages. One of the parameters for traceroute is the number of probes that are sent for each hopcount. RFC 2463 gives an example of 1 second as a conservative default if timer based rate limiting was implemented. If this is used, traceroute won't receive a reply for each probe if multiple probes are sent for each hopcount since some will be supressed due to the rate limiting factor. What are other implementations doing in regard to ICMPv6 rate limits? Thanks Lori -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 19:06:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U362QO004388 for ; Mon, 29 Oct 2001 19:06:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9U362Gd004387 for ipng-dist; Mon, 29 Oct 2001 19:06:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U35wQO004380 for ; Mon, 29 Oct 2001 19:05:58 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25093 for ; Mon, 29 Oct 2001 19:06:00 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10247 for ; Mon, 29 Oct 2001 19:05:59 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Oct 2001 19:05:59 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 19:05:59 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Oct 2001 19:05:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ICMPv6 rate limiting factor Date: Mon, 29 Oct 2001 19:05:58 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC4094@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICMPv6 rate limiting factor Thread-Index: AcFg73PHGKxK6EOYTJWLr7M32080xwAADmGg From: "Richard Draves" To: "Lori Napoli" Cc: X-OriginalArrivalTime: 30 Oct 2001 03:05:58.0939 (UTC) FILETIME=[CC9D36B0:01C160EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9U35wQO004381 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The Microsoft implementation limits to two errors per second, just for this reason. Rich > -----Original Message----- > From: Lori Napoli [mailto:lanapoli@us.ibm.com] > Sent: Monday, October 29, 2001 6:59 PM > To: ipng@sunroof.eng.sun.com > Subject: ICMPv6 rate limiting factor > > > RFC 2463 states that it is a MUST to limit the rate of ICMPv6 > error messages that are sent. Traceroute is a utility that > relies on ICMP error messages. One of the parameters for > traceroute is the number of probes > that are sent for each hopcount. RFC 2463 gives an example > of 1 second as > a conservative default if timer based rate limiting was > implemented. If > this is used, traceroute won't receive a reply for each > probe if multiple probes are sent for each hopcount since > some will be supressed due to the rate limiting factor. What > are other implementations doing in regard to ICMPv6 rate limits? > > Thanks > Lori > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Oct 29 22:24:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U6OMQO004700 for ; Mon, 29 Oct 2001 22:24:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9U6OMpv004699 for ipng-dist; Mon, 29 Oct 2001 22:24:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U6OJQO004692 for ; Mon, 29 Oct 2001 22:24:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03708 for ; Mon, 29 Oct 2001 22:24:20 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20224 for ; Mon, 29 Oct 2001 22:24:19 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9U6OAR04527; Tue, 30 Oct 2001 08:24:10 +0200 Date: Tue, 30 Oct 2001 08:24:10 +0200 (EET) From: Pekka Savola To: Richard Draves cc: Lori Napoli , Subject: RE: ICMPv6 rate limiting factor In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC4094@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Oct 2001, Richard Draves wrote: > The Microsoft implementation limits to two errors per second, just for > this reason. That is only good enough if you assume the tracerouter is over 500ms away, because traceroute by default sends out three probes.. I've commented on the new ICMP draft that this issue should be taken into consideration, and apparently it will, as the draft didn't progress at IETF51. B.t.w. Linux uses a token bucket mechanism here and is not affected. B.t.w.2. Cisco implementation is(/was) also broken, another issue I mentioned here and on 6bone@isi.edu, they promised they'd be working on it. > > -----Original Message----- > > From: Lori Napoli [mailto:lanapoli@us.ibm.com] > > Sent: Monday, October 29, 2001 6:59 PM > > To: ipng@sunroof.eng.sun.com > > Subject: ICMPv6 rate limiting factor > > > > > > RFC 2463 states that it is a MUST to limit the rate of ICMPv6 > > error messages that are sent. Traceroute is a utility that > > relies on ICMP error messages. One of the parameters for > > traceroute is the number of probes > > that are sent for each hopcount. RFC 2463 gives an example > > of 1 second as > > a conservative default if timer based rate limiting was > > implemented. If > > this is used, traceroute won't receive a reply for each > > probe if multiple probes are sent for each hopcount since > > some will be supressed due to the rate limiting factor. What > > are other implementations doing in regard to ICMPv6 rate limits? > > > > Thanks > > Lori > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 22:42:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U6gqQO004727 for ; Mon, 29 Oct 2001 22:42:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9U6gqrk004726 for ipng-dist; Mon, 29 Oct 2001 22:42:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U6gmQO004719 for ; Mon, 29 Oct 2001 22:42:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18291 for ; Mon, 29 Oct 2001 22:42:37 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26338 for ; Mon, 29 Oct 2001 22:42:50 -0800 (PST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Oct 2001 22:42:49 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 22:42:49 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Oct 2001 22:42:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ICMPv6 rate limiting factor Date: Mon, 29 Oct 2001 22:42:48 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC4099@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICMPv6 rate limiting factor Thread-Index: AcFhC9RWywqAivE/T2OreRSTYHmsugAAhFkg From: "Richard Draves" To: "Pekka Savola" Cc: "Lori Napoli" , X-OriginalArrivalTime: 30 Oct 2001 06:42:49.0264 (UTC) FILETIME=[175F4300:01C1610E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9U6gnQO004720 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well the traceroute implementation we use around here limits how fast it sends out probes, to no more than one a second. From your comment I take it not everyone does this? Rich > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, October 29, 2001 10:24 PM > To: Richard Draves > Cc: Lori Napoli; ipng@sunroof.eng.sun.com > Subject: RE: ICMPv6 rate limiting factor > > > On Mon, 29 Oct 2001, Richard Draves wrote: > > The Microsoft implementation limits to two errors per > second, just for > > this reason. > > That is only good enough if you assume the tracerouter is > over 500ms away, > because traceroute by default sends out three probes.. > > I've commented on the new ICMP draft that this issue should > be taken into consideration, and apparently it will, as the > draft didn't progress at IETF51. > > B.t.w. Linux uses a token bucket mechanism here and is not affected. > > B.t.w.2. Cisco implementation is(/was) also broken, another > issue I mentioned here and on 6bone@isi.edu, they promised > they'd be working on it. > > > > -----Original Message----- > > > From: Lori Napoli [mailto:lanapoli@us.ibm.com] > > > Sent: Monday, October 29, 2001 6:59 PM > > > To: ipng@sunroof.eng.sun.com > > > Subject: ICMPv6 rate limiting factor > > > > > > > > > RFC 2463 states that it is a MUST to limit the rate of ICMPv6 > > > error messages that are sent. Traceroute is a utility that > > > relies on ICMP error messages. One of the parameters for > > > traceroute is the number of probes > > > that are sent for each hopcount. RFC 2463 gives an example > > > of 1 second as > > > a conservative default if timer based rate limiting was > > > implemented. If > > > this is used, traceroute won't receive a reply for each > > > probe if multiple probes are sent for each hopcount since > > > some will be supressed due to the rate limiting factor. What > > > are other implementations doing in regard to ICMPv6 rate limits? > > > > > > Thanks > > > Lori > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 > > -------------------------------------------------------------------- > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 29 22:47:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U6l9QO004764 for ; Mon, 29 Oct 2001 22:47:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9U6l9lc004763 for ipng-dist; Mon, 29 Oct 2001 22:47:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U6l6QO004756 for ; Mon, 29 Oct 2001 22:47:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA06466 for ; Mon, 29 Oct 2001 22:47:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05209 for ; Tue, 30 Oct 2001 00:14:00 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9U6kwf04666; Tue, 30 Oct 2001 08:46:58 +0200 Date: Tue, 30 Oct 2001 08:46:57 +0200 (EET) From: Pekka Savola To: Richard Draves cc: Lori Napoli , Subject: RE: ICMPv6 rate limiting factor In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC4099@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Oct 2001, Richard Draves wrote: > Well the traceroute implementation we use around here limits how fast it > sends out probes, to no more than one a second. From your comment I take > it not everyone does this? True. A quick look at Linux and BSD implementations show that they don't rate-limit the sent packets. It's nice to get a full traceroute of 10 hops <30ms each in less than a second :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 30 00:54:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U8s1QO004972 for ; Tue, 30 Oct 2001 00:54:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9U8s0qS004971 for ipng-dist; Tue, 30 Oct 2001 00:54:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9U8rtQO004964 for ; Tue, 30 Oct 2001 00:53:55 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f9U8rlq21296; Tue, 30 Oct 2001 09:53:47 +0100 (MET) Date: Tue, 30 Oct 2001 09:53:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ICMPv6 rate limiting factor To: Lori Napoli Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > RFC 2463 states that it is a MUST to limit the rate of ICMPv6 error > messages that are sent. Traceroute is a utility that relies on ICMP error > messages. One of the parameters for traceroute is the number of probes > that are sent for each hopcount. RFC 2463 gives an example of 1 second as > a conservative default if timer based rate limiting was implemented. If > this is used, traceroute won't receive a reply for each probe if multiple > probes are sent for each hopcount since some will be supressed due to the > rate limiting factor. What are other implementations doing in regard to > ICMPv6 rate limits? The Solaris implementation uses a token bucket filter to allow bursts of ICMP errors (max 10) while limiting the average rate to 10 per second. 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 Oct 30 02:01:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UA15QO005161 for ; Tue, 30 Oct 2001 02:01:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9UA15kO005160 for ipng-dist; Tue, 30 Oct 2001 02:01:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UA11QO005152 for ; Tue, 30 Oct 2001 02:01:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06506 for ; Tue, 30 Oct 2001 02:00:49 -0800 (PST) Received: from starfruit.itojun.org ([202.204.22.212]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19926 for ; Tue, 30 Oct 2001 03:28:01 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 5B66E7BB; Tue, 30 Oct 2001 18:05:45 +0900 (JST) To: Pekka Savola Cc: Richard Draves , Lori Napoli , ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Tue, 30 Oct 2001 08:46:57 +0200. 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: Re: ICMPv6 rate limiting factor From: Jun-ichiro itojun Hagino Date: Tue, 30 Oct 2001 18:05:45 +0900 Message-Id: <20011030090545.5B66E7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Well the traceroute implementation we use around here limits how fast it >> sends out probes, to no more than one a second. From your comment I take >> it not everyone does this? >True. A quick look at Linux and BSD implementations show that they don't >rate-limit the sent packets. false stetement. BSD implementations do rate-limit icmp6 messages. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 30 02:42:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UAgkQO005188 for ; Tue, 30 Oct 2001 02:42:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9UAgk6Y005187 for ipng-dist; Tue, 30 Oct 2001 02:42:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UAghQO005180 for ; Tue, 30 Oct 2001 02:42:43 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09577 for ; Tue, 30 Oct 2001 02:42:32 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09063 for ; Tue, 30 Oct 2001 02:42:43 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f9UAgHF06091; Tue, 30 Oct 2001 12:42:17 +0200 Date: Tue, 30 Oct 2001 12:42:17 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: Richard Draves , Lori Napoli , Subject: Re: ICMPv6 rate limiting factor In-Reply-To: <20011030090545.5B66E7BB@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 30 Oct 2001, Jun-ichiro itojun Hagino wrote: > >> Well the traceroute implementation we use around here limits how fast it > >> sends out probes, to no more than one a second. From your comment I take > >> it not everyone does this? > >True. A quick look at Linux and BSD implementations show that they don't > >rate-limit the sent packets. > > false stetement. BSD implementations do rate-limit icmp6 messages. I should have phrased that better, perhaps. The context was: "does traceroute6 limit the rate it sends UDP (/ICMP) packets?". For both Linux and BSD, the answer is "no." By default, the packets are sent as fast as traceroute6 gets the responses back, basically. Sending ICMP6 error messages in reaction to these is different, which are indeed rate-limited. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 30 04:35:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UCZiQO005269 for ; Tue, 30 Oct 2001 04:35:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9UCZhma005268 for ipng-dist; Tue, 30 Oct 2001 04:35:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UCZeQO005261 for ; Tue, 30 Oct 2001 04:35:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21311 for ; Tue, 30 Oct 2001 04:35:41 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18417 for ; Tue, 30 Oct 2001 06:03:00 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA22149; Tue, 30 Oct 2001 12:35:29 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Richard Draves , Lori Napoli , Subject: Re: ICMPv6 rate limiting factor References: From: Ole Troan Date: Tue, 30 Oct 2001 12:35:29 +0000 In-Reply-To: (Pekka Savola's message of "Tue, 30 Oct 2001 08:24:10 +0200 (EET)") Message-ID: <7t5r8rll2zy.fsf@mrwint.cisco.com> Lines: 19 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The Microsoft implementation limits to two errors per second, just for >> this reason. > > That is only good enough if you assume the tracerouter is over 500ms away, > because traceroute by default sends out three probes.. > > I've commented on the new ICMP draft that this issue should be taken into > consideration, and apparently it will, as the draft didn't progress at > IETF51. > > B.t.w. Linux uses a token bucket mechanism here and is not affected. > > B.t.w.2. Cisco implementation is(/was) also broken, another issue I > mentioned here and on 6bone@isi.edu, they promised they'd be working on > it. the latest releases use an adjustable token bucket algorithm. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 30 10:37:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UIbsQO005620 for ; Tue, 30 Oct 2001 10:37:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9UIbsPQ005619 for ipng-dist; Tue, 30 Oct 2001 10:37:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9UIboQO005612 for ; Tue, 30 Oct 2001 10:37:51 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04858; Tue, 30 Oct 2001 13:37:53 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9UIbqgl002539; Tue, 30 Oct 2001 13:37:53 -0500 (EST) Message-Id: <200110301837.f9UIbqgl002539@thunk.east.sun.com> From: Bill Sommerfeld To: "Richard Draves" cc: "Pekka Savola" , "Lori Napoli" , ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 rate limiting factor In-Reply-To: Your message of "Mon, 29 Oct 2001 22:42:48 PST." <7695E2F6903F7A41961F8CF888D87EA804BC4099@red-msg-06.redmond.corp.microsoft.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 30 Oct 2001 13:37:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well the traceroute implementation we use around here limits how fast it > sends out probes, to no more than one a second. From your comment I take > it not everyone does this? Most of traceroute implementations I've seen are "self clocking", sending out the next probe when they get back a response to the previous one. - 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 Tue Oct 30 17:19:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V1J4QO006271 for ; Tue, 30 Oct 2001 17:19:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9V1J4QM006270 for ipng-dist; Tue, 30 Oct 2001 17:19:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V1J1QO006263 for ; Tue, 30 Oct 2001 17:19:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28278 for ; Tue, 30 Oct 2001 17:18:50 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17632 for ; Tue, 30 Oct 2001 17:19:01 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f9V1Ixa04326 for ; Wed, 31 Oct 2001 10:19:00 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id f9V1Iww25036 for ; Wed, 31 Oct 2001 10:18:58 +0900 (JST) Received: from kaishu.jp.nec.com (kaishu.jp.nec.com [10.26.220.5]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id f9V1IqV17851 for ; Wed, 31 Oct 2001 10:18:53 +0900 (JST) Received: from [10.42.72.128] by mail.jp.nec.com; Wed, 31 Oct 2001 10:18:52 +0900 Date: Wed, 31 Oct 2001 10:18:50 +0900 From: Hiroki Ishibashi Subject: Automatic Prefix Delegation ICMPv6 types and multicast address? To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: TuruKame 1.43 (WinNT,500) Organization: NEC Corporation Message-Id: <69C161A9FF7697bashi@ipv6.nec.co.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know ICMPv6 type numbers and ALL-DELEGATORS link-local multicast address to be used (or proposed) for Automatic Prefix Delegation (draft-haberman-ipngwg-auto-prefix-01.txt)? Thanks in advance. Hiroki Ishibashi bashi@ipv6.nec.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 Tue Oct 30 19:32:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V3WrQO006498 for ; Tue, 30 Oct 2001 19:32:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9V3WqxU006497 for ipng-dist; Tue, 30 Oct 2001 19:32:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9V3WmQO006490 for ; Tue, 30 Oct 2001 19:32:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16576 for ; Tue, 30 Oct 2001 19:32:50 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA19183 for ; Tue, 30 Oct 2001 21:03:38 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:b50b:215b:ecb7:3fd7]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA26025; Wed, 31 Oct 2001 12:33:15 +0900 (JST) Date: Wed, 31 Oct 2001 12:32:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Lori Napoli" Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 rate limiting factor In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 29 Oct 2001 21:59:06 -0500, >>>>> "Lori Napoli" said: > RFC 2463 states that it is a MUST to limit the rate of ICMPv6 error > messages that are sent. Traceroute is a utility that relies on ICMP error > messages. One of the parameters for traceroute is the number of probes > that are sent for each hopcount. RFC 2463 gives an example of 1 second as > a conservative default if timer based rate limiting was implemented. If > this is used, traceroute won't receive a reply for each probe if multiple > probes are sent for each hopcount since some will be supressed due to the > rate limiting factor. What are other implementations doing in regard to > ICMPv6 rate limits? As itojun mentioned (in a different context), the KAME/BSD implementation does the rate limitation on packet-per-sec basis. By default the implementation allows 100 icmp6 errors per second. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. 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 Wed Oct 31 07:50:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VFoUQO007502 for ; Wed, 31 Oct 2001 07:50:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VFoTm8007501 for ipng-dist; Wed, 31 Oct 2001 07:50:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VFoPQO007494 for ; Wed, 31 Oct 2001 07:50:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17434 for ; Wed, 31 Oct 2001 07:50:26 -0800 (PST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27603 for ; Wed, 31 Oct 2001 08:50:11 -0700 (MST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9VFnkS04212 for ; Wed, 31 Oct 2001 10:49:46 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 31 Oct 2001 10:50:12 -0500 Received: from zbl6c004.corpeast.baynetworks.com ([132.245.205.54]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VPDBGHR2; Wed, 31 Oct 2001 10:49:36 -0500 Received: from americasm06.nt.com (abl6t0k5.us.nortel.com [47.16.4.201]) by zbl6c004.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VXMXRVXA; Wed, 31 Oct 2001 10:49:36 -0500 Message-ID: <3BE01DBC.25C09F72@americasm06.nt.com> Date: Wed, 31 Oct 2001 10:50:20 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hiroki Ishibashi CC: ipng@sunroof.eng.sun.com Subject: Re: Automatic Prefix Delegation ICMPv6 types and multicast address? References: <69C161A9FF7697bashi@ipv6.nec.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hiroki, Right now, we do not have types and codes assigned. That is due to the fact that RFC 2780 (see section 7) notes that assignments of ICMPv6 code/type values are controlled by IESG Approval or Standards Action. Since this doc has not been accepted by IPNGWG as a working group doc, the IESG is going to be hesitant to assign values. Jim and I are talking about trying to get some test space within ICMPv6 code/type fields defined for use until the document progresses (see draft-narten-iana-experimental-allocations-00.txt). However, work on this document has come to a stop, at least momentarily, due to work-related issues. Regards, Brian Hiroki Ishibashi wrote: > > Does anyone know ICMPv6 type numbers and ALL-DELEGATORS link-local > multicast address to be used (or proposed) for Automatic Prefix Delegation > (draft-haberman-ipngwg-auto-prefix-01.txt)? > > Thanks in advance. > > Hiroki Ishibashi > bashi@ipv6.nec.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 08:08:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VG8lQO007539 for ; Wed, 31 Oct 2001 08:08:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VG8ka5007538 for ipng-dist; Wed, 31 Oct 2001 08:08:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VG8hQO007531 for ; Wed, 31 Oct 2001 08:08:43 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12845 for ; Wed, 31 Oct 2001 08:08:31 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16507 for ; Wed, 31 Oct 2001 08:08:44 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15yxuf-000Nlq-00 for ipng@sunroof.eng.sun.com; Wed, 31 Oct 2001 08:08:21 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-uni-based-mcast-03.txt Message-Id: Date: Wed, 31 Oct 2001 08:08:21 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i presume folk in this wg are tracking the comments which have been received in other wgs? randy From: Pavlin Radoslavov To: Randy Bush cc: mboned wg Subject: Re: v6 documents Date: Wed, 31 Oct 2001 01:23:17 -0800 (Sorry if a duplicate, but seems like for some reason my first attempt few days ago wasn't propagated by the mailing list.) > has this wg taken a look at > draft-ietf-ipngwg-uni-based-mcast-03.txt Few comments: * It seems that under this proposal the allocated multicast addresses per unicast prefix will always be /96, regardless of the size of the "network prefix". Is the assumption that 2^32 multicast addresses will be sufficient for any network, regardless of its size? Indeed, Section 4 says that "All non-significant bits of the network prefix field SHOULD be zero." I'd like to know what is the argument against allowing those non-significant bits to be part of the group ID. E.g., the alternative could be something like: "The group ID should be 32 bits, but if a network needs more than 2^32 multicast addresses, it may use the non-significant bits from "network prefix" as well." * Section 6 "o Set P = 1." Probably this should be specific re. the T-bit as well, even though earlier you specify the relation between those two bits: E.g.: o Set P = 1 and T = 1. * Section 6 "These settings create an SSM range of FF3x::/32 ..." I believe this should be /96 Pavlin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 13:20:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VLK8QO008040 for ; Wed, 31 Oct 2001 13:20:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id f9VLK8TL008039 for ipng-dist; Wed, 31 Oct 2001 13:20:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id f9VLK4QO008032 for ; Wed, 31 Oct 2001 13:20:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00727 for ; Wed, 31 Oct 2001 13:19:56 -0800 (PST) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15992 for ; Wed, 31 Oct 2001 14:19:41 -0700 (MST) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA16386 for ; Wed, 31 Oct 2001 15:18:35 -0600 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA47068 for ; Wed, 31 Oct 2001 15:19:53 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id f9VLJrV32998 for ; Wed, 31 Oct 2001 15:19:53 -0600 Date: Wed, 31 Oct 2001 15:19:52 -0600 (CST) From: Lilian Fernandes To: Subject: TCP and Ancillary data in RFC2292bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC2292bis-02 states that applications using TCP can use ancillary data to receive IPv6 and extension header information (Section 4.1 - TCP Implications) What are other implementations doing about this? Is there a common strategy that most implementations have adopted? Also, what could be a reason for delivering data like "destination address" as ancillary data? This will always be constant as part of the TCP connection's 4-tuple. Thanks, Lilian Fernandes -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Oct 31 20:57:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA14vBQO008678 for ; Wed, 31 Oct 2001 20:57:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA14vBP4008677 for ipng-dist; Wed, 31 Oct 2001 20:57:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA14v8QO008670 for ; Wed, 31 Oct 2001 20:57:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18451 for ; Wed, 31 Oct 2001 20:57:11 -0800 (PST) From: fujisawa@sm.sony.co.jp Received: from ns4.sony.co.jp (NS4.Sony.CO.JP [146.215.0.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21899 for ; Wed, 31 Oct 2001 20:57:09 -0800 (PST) Received: from mail5.sony.co.jp (GateKeeper15.Sony.CO.JP [146.215.0.77]) by ns4.sony.co.jp (R8/Sony) with ESMTP id fA14v8Y34950 for ; Thu, 1 Nov 2001 13:57:08 +0900 (JST) Received: from mail5.sony.co.jp (localhost [127.0.0.1]) by mail5.sony.co.jp (R8/Sony) with ESMTP id fA14v8807223 for ; Thu, 1 Nov 2001 13:57:08 +0900 (JST) Received: from smail2.sm.sony.co.jp (smail2.sm.sony.co.jp [43.16.1.128]) by mail5.sony.co.jp (R8/Sony) with ESMTP id fA14v6l07200 for ; Thu, 1 Nov 2001 13:57:07 +0900 (JST) Received: from rdmail.sm.sony.co.jp (root@xserver.sm.sony.co.jp [43.16.63.219]) by smail2.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id NAA19244 for ; Thu, 1 Nov 2001 13:57:03 +0900 (JST) Received: from fujiken.sm.sony.co.jp (fujiken.sm.sony.co.jp [43.16.63.177]) by rdmail.sm.sony.co.jp (8.8.8/3.6W-09/08/98) with ESMTP id NAA13223 for ; Thu, 1 Nov 2001 13:56:43 +0900 (JST) Received: from localhost by fujiken.sm.sony.co.jp (8.8.8/6.4J.6/K) id NAA12538; Thu, 1 Nov 2001 13:57:38 +0900 (JST) Message-Id: <200111010457.NAA12538@fujiken.sm.sony.co.jp> To: Subject: MAC-48 vs EUI-48 Date: Thu, 01 Nov 2001 13:57:38 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Appendix A in draft-ietf-ipngwg-addr-arch-v3-06.txt says, : Links or Nodes with IEEE 802 48 bit MAC's : : [EUI64] defines a method to create a IEEE EUI-64 identifier from an : IEEE 48bit MAC identifier. This is to insert two octets, with : hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC : (between the company_id and vendor supplied id). But it seems that IEEE RA defined EUI-48 as different concept from MAC-48. http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html : MAC-48. A 48-bit identifier used to address hardware interfaces : within existing 802 based networking applications : EUI-48. A 48-bit identifier used to identify a design instance, : as opposed to a hardware instance. Examples include : software interface standards (such as VGA) or the model : number for a product. And they defined another mapping method for a MAC-48. The section "Encapsulated MAC-48 values" in http://standards.ieee.org/regauth/oui/tutorials/EUI64.html seems to use "FFFF" to encapsulate a MAC-48. Note that following sentence in this clause seems to be a typo. "A unique EUI-64 value is generated by concatenating the OUI, an FFFE valued label, and the extension identifier values." Should we also change the mapping method from a 802 address to the IPv6 Interface ID? Or should we continue to use FFFE? Best Regards, Kenji Fujisawa -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------